Re: Research papers on extreme programming

Todd,

Do you want feedback?  If so, here or privately or how?

I already have serious issues with your working definition of a product
backlog.

On Mon, Nov 4, 2019 at 11:29 AM Todd Sedano [email protected]
[extremeprogramming] <[email protected]> wrote:

>
>
> While at Pivotal, I've been researching extreme programming and
> sustainable software development.
>
> My latest research paper was accepted at the top software engineering
> research conference (18% acceptance rate.)  The paper explores dual-track
> agile and answers the question “where does the backlog come from?” My early
> research answered the question “how do we empty a backlog?”
>
> Here it is: The Product Backlog
> <https://www.researchgate.net/publication/330823863_The_Product_Backlog> click
> "Download Full-Text PDF"
>
> In dual-track agile, part of the team, typically product designers and
> product managers, perform a series of activities to determine what to build
> and validate that proposed solutions provide business value, thus filling a
> backlog. Meanwhile another part of the team, typically engineers implement
> stories and delivering a product, thus emptying a backlog. The paper
> positions the product backlog as a boundary-spanning object between the two
> tracks.
>
> Todd
>
> If you missed my earlier papers, check them out:
>
> Software Development Waste
> <https://www.researchgate.net/publication/313360479_Software_Development_Waste> provides
> the first evidence-based waste taxonomy. Use it team reflections for
> finding hidden waste.
>
> Sustainable Software Development through Overlapping Pair Rotation
> <https://www.researchgate.net/publication/304014117_Sustainable_Software_Development_through_Overlapping_Pair_Rotation> explains
> why removing knowledge silos and caretaking the code is so important to us.
>
> Practice and Perception of Team Code Ownership
> <https://www.researchgate.net/publication/301612260_Practice_and_Perception_of_Team_Code_Ownership> introduces
> our preference of team code ownership over collective code ownership and
> explains why achieving team code ownership can be tricky.
>
> 
>