First, let's assume that we believe that our firm needs a good agile transformation to achieve important business goals. Perhaps these are: (a) faster time to market, (b) more creativity in the product, and (c) greater productivity. (In any case, not 'Agile' for agile's sake.)
One method to achieve more success from the agile transformation is to define the basics of agile for an agile team. Not every detail, but the basics.
Probably on one page. In any case, fairly short.
And we have found it useful to ask each team: Are you really agile by this definition? If not, we discuss it with them. Occasionally they can make a good case for an exception. More likely, they don't understand agile well enough. Yet. And so we learn.
Now, if you think this is a good idea, where do you start?
Well, the Scrum-Butt Test is a place to start. Here are its eight ideas:
Well, I think it is a great start. And in some circumstances very useful. But if you want to define agile for your teams, I think you should define more. More, but not 5 pages of more.
Enough for today.
Comments?
One method to achieve more success from the agile transformation is to define the basics of agile for an agile team. Not every detail, but the basics.
Probably on one page. In any case, fairly short.
And we have found it useful to ask each team: Are you really agile by this definition? If not, we discuss it with them. Occasionally they can make a good case for an exception. More likely, they don't understand agile well enough. Yet. And so we learn.
Now, if you think this is a good idea, where do you start?
Well, the Scrum-Butt Test is a place to start. Here are its eight ideas:
- Sprints must be timeboxed to 4 weeks or less
- Features are tested and working by the end the Sprint
- The Sprint starts with an Agile spec
- You know who the product owner is
- •There is a product backlog prioritized by business value
- •The product backlog has estimates created by the team
- •The team generates burndown charts and knows their velocity
- •There are no project managers (or anyone else) disrupting the work of the team
Well, I think it is a great start. And in some circumstances very useful. But if you want to define agile for your teams, I think you should define more. More, but not 5 pages of more.
Enough for today.
Comments?
No comments:
Post a Comment