tgoop.com/agile_coach_notes/977
Last Update:
📝Оригинал 👇
Agile teams place a high value on fully implementing new ideas, features, or functionality each iteration. Rather than being partially done with a large number of things, agile teams seek to be really done with a smaller number.
But why?
First, good products are made better with fast feedback.
I was recently making sandwiches for my family. I decided to make ham and swiss on rye–a classic that never goes out of style. I could have created all 4 sandwiches, and made them all just as I like them, with spicy brown mustard, lettuce, and onions. (Yum!) Instead, though, I made mine then called out for some fast feedback from my end users. I showed them what I’d made, and said, “More of the same for each of you?”
The answer was a resounding no.
Delaney wanted no mustard and no veg, just mayo. Savannah asked for one like mine plus mayo. Laura wanted dijon in place of the spicy brown. No accounting for taste. But I made the sandwiches based on the feedback and ended up with 4 satisfied customers, including me!
Second, finished features can be sold; unfinished features cannot.
All projects represent an economic investment—time and money are invested in developing functionality.
An organization cannot begin regaining its investment by delivering partially developed features. A product with ten half-done features can be thought of as inventory sitting on a warehouse floor. That inventory cannot be sold until each feature is complete.
In contrast, a product with five finished features is sellable. It can begin earning money back against the investment.
And finally, partial progress is notoriously hard to estimate.
This year at Mountain Goat Software, we doubled down on our commitment to using OKRs. For a few of our quarterly OKRs, the tool we’re using asks us to track progress as percent done. I hate it.
My team laughs when I enter values like 73.52% done. I laugh that an otherwise good tool lets me enter such precisely false values.
I don’t like tracking partial percentages because it gives me false hope.
Every week, I see those sliders move a little closer to 100%. Eventually they move to 90% and I think Great, it’s almost done. A week later it’s still 90% done. Why? Because the size of the problem grew at the same rate as the progress someone made on the work.
In agile, we avoid this heartache by making sure that at the end of each iteration, all work is either:
Not started
Done
People are really good at knowing when we haven’t started something. We’re pretty good at knowing when we’re done with something. We’re horrible anywhere in between.
One way to help teams remember that “one done” is better than “many half-done” is to set a limit on your work in process, or WIP. A WIP limit defines how many items can be simultaneously worked on or in the same state at a time.
For example, a team may decide that no more than two product backlog items can be coded concurrently. In that case, a team would not be allowed to begin coding a third until at least one of the two has been coded.
Setting a WIP limit so you can get items to Done every iteration is a solid way to succeed with agile
BY Agile-сoach Notes
Share with your friend now:
tgoop.com/agile_coach_notes/977