Archive for June, 2009

Invest in your Product Owner

Getting the user stories on the right size, in the right format, in essence getting to the sprint in a READY-READY form (READY actually means READY, not make-believe READY…) requires a lot of cooperation from the Product Owner/Manager. He should understand the value he gets if he INVESTs in stories/features, because it DOES create work that he’s not used to. In some cases you will have a hard time getting to this level of detail from your Product Management, so you’ll need to create a Product Owner that proxies and fills in the blanks – usually a Business Analyst, Designer, Architect can help in that aspect.

 

The biggest challenge is if a Product Owner/Manager doesn’t think he can get any business value from small granular stories, and that “he needs everything – all features, and all requirements in all stories”. In that case, your biggest impediment is that the PO doesn’t believe in Agility – and you should think what to do about that. I would suggest a discussion about Agile potential ROI for the business, driven by faster time to market, better adjustment to customer real requirements, and much better predictability and trust that the versions will get out on schedule.

 

On a side note, I see the lack of understanding/belief in the value of agility on the business side as a very common and very dangerous problem. Without the business side on board, the development teams will lose a lot of the reasoning behind some of the Agile practices/principles, which might lead to regression to lesser ways.

 

E.g. ROI for faster sprints without delivery to the customer or PO coming for a demo – I believe they still have value in having a fast feedback cycle, even if internal, and even if used mainly for the team improving its performance. But its clear that the ROI will be a lot smaller than if the sprint result is actually taken by the customer or other groups in the company, both to earn money, as well as give much better feedback.

 

 

 

 

 

Advertisements

Leave a Comment

Big is bad, small is good!

While a lot of what affects an agile team is within the team’s scope of responsibility, the key antipattern I’m talking about today sort of isn’t…

A big factor on whether a team can be effective is the size of stories/features on its backlog. A lot of good things happen when stories are Small (See the S in INVEST). A lot of bad things happen if they’re too big.

Lets look at how it looks when the stories/features are too big (team takes more than a week or so to start-to-finish them)

Teams cannot achieve real flow – testers are idle waiting for a long story to be developed, then are stressed to test it, since the end of the iteration/sprint is near.

Since there is a tendency of individuals to want some ownership of at least a story (if not a module), assuming big stories, an iteration/sprint will look like a mini-waterfall, with the developers each taking a story, all major stories getting into testing about 2/3 of the way into the sprint, and we lose the ability to control the sprint scope, and left with either making it across the finish line after managing to catch all defects and fixing them for all of the stories, or we are left with a sprint which is unsuccessful. The burndown chart of such a team will look like the one below.

 

 

 

 

For some really big stories, its not even clear how to finish them in one sprint, so teams start to have sprints for “Design”, “Coding”, “Testing” leading to really a waterfall across sprints.

 

With both in-sprint and across-sprints mini-waterfalls the mains problems are visibility and ability to change priorities or adapt to new requirements.

From the moment you start working on a story/feature, it becomes WIP – work in progress. Your aim should be to minimize this. WIP is Waste, that becomes apparent in the cases your Product Owner comes and says that this feature is now not the top priority anymore and he needs something else instead, or that after seeing a demo first time at the end of the sprint, he has a lot of changes in mind that you would have liked to have known about before finishing all the work.

The visibility problem is due to the fact that the real measure of progress is Working Software. Knowing that the design task is done and we are in coding is nice, but after many years developing software we don’t trust it that much. We prefer seeing working software frequently DURING the sprints.

 

The one potential problem of really small stories, is that they become a unit of business value that doesn’t mean much for the Customer/Product Owner. The drive for “Minimum Marketable Features” adopted by Kanban is to have slightly bigger stories, something you would mention in a product blog for example. There’s a fine balance that needs to be managed here.

Leave a Comment

The cost of iterations applied to Kanban as well…

My latest blog post was about the costs and challenges of iterations, as well as what to do to overcome them.

One of the other things I’m working on is Kanban. I believe Kanban is a great fit to many teams and situations. Specifically doing Scrumban is a great way to get the benefits of Agile project management together with the Lean Flow Kanban provides. If you strive to achieve a stream/flow of value, you face the same challenges of getting to the minimal batch of work you can live with, and the challenges are quite similar to what I described above.

One difference is that if you DO have bigger features/stories from time to time, with Kanban you do them as fast as you can, but you don’t have the challenge of fitting them into iterations.

This is an advantage and a problem. The advantage is that it feels more natural.

The problem is that teams can fall into the “comfort zone” of keeping the features big, and doing mini-waterfalls on them.

Both with Agile as well as with Lean/Kanban the best solution is on the business/product owner side. If HE breaks the requirements/features into smaller stories/Minimally-marketable-Features(MMFs), the team will execute and deliver faster.

I haven’t thought this through, but my gut tells me that on the engineering practices side, Kanban requires about the same approach as Agile/Scrum in order to reach a high ROI.

What are your thoughts?

 

Leave a Comment

Iterate / Inspect and Adapt – nice in theory…

On paper, it all makes sense. You iterate in order to deliver business value as early and frequent as possible, and to learn as early as possible about mistakes or opportunities, both in what you build as well as how you build. So far so good.

Now, there are several things you hear from teams starting to work in fast iterations:

  • We cannot really accomplish any meaningful amount of work in this short time. Look at the features we’re asked to work on, no chance we can finish that so fast…
  • Wait – you mean we actually want to have this potentially shippable every iteration? That means we need to have it stable. In order to reach stability we need to do a test cycle. We need some time to do that. The term “Feature/Code Freeze” usually comes up at that point. See my earlier post about this.
  • Can we do design in one iteration, coding in another, testing in yet another?

All in all, if what you are looking for is a way to surface the heavy large batch stuff in your engineering organization, look no further than to raise the idea of fast iterations, not to mention to actually start doing them… 😉 Lucky for us, when we implement Agile/Scrum/Lean, that is exactly what we are looking for.

At this stage fast iterations trade some lost productivity for the gain of early ROI and better visibility of project progress, requirements changes. In Agilesparks, we call teams at this level “Scrum Level 1”. In some cases, at this level the cost and benefits are not that far from each other…

Its crucial at this point that the team/organization transition to a place where the lost productivity is negligible, while the early ROI grows. This requires both reducing the cost of the small batches as well as pushing the product to its customers more frequently. Without these two actions, it will be hard to justify continuing to pay the price of fast iterations, and some regression to long iterations or lower chance of shippable product will ensue.

How do you reduce the cost of small batches?

One of the keys is to introduce Continuous Integration with a fully automation regression suite reduces the price of testing.

Tomorrow I’m talking in a Test Automation Open day about this and related concepts. You are welcome to check out my slides .

I’ll continue to write about this subject in the future. I believe its key to making Agile work in real life.

Comments (1)

Agile antipattern: Code freezes during each iteration

Bob Hartman, from the Agile for All blog writes about the agile antipatterns insanity – continue doing the same things that always fail, thinking they will work better the next time without changing anything.

I agree with every word, especially with the pattern of testing late, and code freezes during each iteration

I see this on many of the teams I’m coaching.

Go read what Bob has to say…

One reason I hear from teams that Bob didn’t mention is that testing earlier would mean testing time and time again the same areas leading to Waste (assuming you acceptance test a user story, then another user story, both in the same area).

As someone who likes to think in Lean terms, when a team throws Waste at me, it usually makes me proud. In this case though, its the other way around I think:

  • First, assuming reasonable engineering skills, the amount of codebase rework between these user stories will not be high, so the need to repeat testing for regression will not be very high.
  • Second, if you DO have a need to regression test, fine, automate it and make it cheap to test as many times you want, inside your CI environment.
  • Third, on the acceptance test side, with reasonable testing design skills, the tests for each of the user stories should not have much in common, so there is no waste here as well

On the contrary, to leave a user story untested for any period of time, is WIP waste.

You should test, fix bugs, before moving to other user stories, or at least while working on the next user story but not
the next iteration.

That was my line of thinking.

What do you think?


Comments (1)

agileblog 06/04/2009

  • tags: lean, design, agile, agileblog

    • how Kanban metaphor from Lean manufacturing and the Feature Injection template play into Behaviour Driven Development, working together to help us identify the most important software, reduce unnecessary artifacts at each stage of development, and produce the minimum necessary to achieve a vision
    • The artifacts signal each role to create further artifacts until the vision is implemented and the business value is earned
    • “Generating reports,” he says, “is like lead. It’s easy to work with, and it’s cheap. It’s also heavy, worthless, and drags you down. Developers sink a lot of time into writing report software. Why? Buy it, install it, hack it so it works. Use Excel. Don’t spend money writing report software, unless you’re the kind of company that sells them to other companies.
  • tags: agileblog, kanban, limitedwipsociety

Posted from Diigo. The rest of my favorite links are here.

Leave a Comment

agileblog 06/03/2009

Posted from Diigo. The rest of my favorite links are here.

Leave a Comment

Older Posts »