I was just at the Agile Tour at Research Triangle Park in North Carolina. Very good event (kudos to Catherine Louis and the other organizers!!).
Laurie Williams, who is a great person and a great agile researcher, has done some work recently on, and I should use her words but don't have them handy, 'how do we feel about the Agile Manifesto and the Agile Principles now?'
One general reaction I had, which is also a reaction I have had recently in other situations....
When push comes to shove, what should give way: Agile principles or our local organization?
In my view, almost always the problem is 'us' and not the agile values, principles and practices.
And almost always, we make the agile stuff 'give right of way' to what we call 'reality'. But it is not 'reality' as in the law of gravity, but only reality in that these are the stupid ways our organization is doing things today.
Example: Sustainable pace.
Some people complain that the principle of sustainable pace means that managers can whip us to stay at 30 story points per sprint (after the team itself volunteered to go 30), and that it does not allow us to fix the technical debt or do the broader range work that must (at least eventually) be done.
This is my view:
* sustainable pace is very important in many ways. The main way I like to talk about it is that it is no longer about 'hard work', it is about 'creativity' and 'innovation' and 'inventive' solutions to difficult technical problems. Our brains have to be fresh to be creative as a team.
* sustainable pace (as measured via velocity) quickly becomes less valuable unless we are doing virtually everything possible never to allow technical debt to grow. Let's be professional.
* sustainable pace does not mean that the team 'must' maintain the same velocity every sprint. (Yes, Virginia, stuff does happen, for example.) AND, the team should always be challenging itself to remove impediments so that more 'work' can be accomplished in the same amount of time. In other words, in general and on average, 'velocity' should be upwardly sloping. But NOT by working harder.
* an empirical process requires transparency (or a high level of it) and any pretending about or hiding of 'undone work' (as Ken Schwaber likes to call it) is not helpful at all. Sustainable pace quickly becomes meaningless if we do this. (Cf Technical debt above.)
* Bad news does not get better with age. So, sustainable pace must be immediately linked to a strong and improving 'definition of done' for normal stories in a sprint.
* By sustainable we must mean we are doing everything we professionally can to assure we are keeping each sprint up with ALL the different types of work needed to keep the system fully 'done'. This includes fixing all bugs, doing all the refactoring, building all the truly useful documentation, visioning of future sprints, release plan refactoring, etc, etc.
* As soon as we discover some undone work (and we as humans will typically forget something and thus it is undone), we must address it professionally....do it immediately or put it on the product backlog. And consider how much it makes our previous information about velocity and progress a lie. (Always, to some minor degree, and possibly to a significant degree.)
* Just because we will always be imperfect does not mean we should give up on agile or agile principles or practices.
Can you put these ideas into action real soon? (Today is a good day.)
PS. I am not saying the Agile Manifesto and the Agile Principles are perfect. But maybe I am saying that our real worlds are messier than those ideas. Or so I see.
Laurie Williams, who is a great person and a great agile researcher, has done some work recently on, and I should use her words but don't have them handy, 'how do we feel about the Agile Manifesto and the Agile Principles now?'
One general reaction I had, which is also a reaction I have had recently in other situations....
When push comes to shove, what should give way: Agile principles or our local organization?
In my view, almost always the problem is 'us' and not the agile values, principles and practices.
And almost always, we make the agile stuff 'give right of way' to what we call 'reality'. But it is not 'reality' as in the law of gravity, but only reality in that these are the stupid ways our organization is doing things today.
Example: Sustainable pace.
Some people complain that the principle of sustainable pace means that managers can whip us to stay at 30 story points per sprint (after the team itself volunteered to go 30), and that it does not allow us to fix the technical debt or do the broader range work that must (at least eventually) be done.
This is my view:
* sustainable pace is very important in many ways. The main way I like to talk about it is that it is no longer about 'hard work', it is about 'creativity' and 'innovation' and 'inventive' solutions to difficult technical problems. Our brains have to be fresh to be creative as a team.
* sustainable pace (as measured via velocity) quickly becomes less valuable unless we are doing virtually everything possible never to allow technical debt to grow. Let's be professional.
* sustainable pace does not mean that the team 'must' maintain the same velocity every sprint. (Yes, Virginia, stuff does happen, for example.) AND, the team should always be challenging itself to remove impediments so that more 'work' can be accomplished in the same amount of time. In other words, in general and on average, 'velocity' should be upwardly sloping. But NOT by working harder.
* an empirical process requires transparency (or a high level of it) and any pretending about or hiding of 'undone work' (as Ken Schwaber likes to call it) is not helpful at all. Sustainable pace quickly becomes meaningless if we do this. (Cf Technical debt above.)
* Bad news does not get better with age. So, sustainable pace must be immediately linked to a strong and improving 'definition of done' for normal stories in a sprint.
* By sustainable we must mean we are doing everything we professionally can to assure we are keeping each sprint up with ALL the different types of work needed to keep the system fully 'done'. This includes fixing all bugs, doing all the refactoring, building all the truly useful documentation, visioning of future sprints, release plan refactoring, etc, etc.
* As soon as we discover some undone work (and we as humans will typically forget something and thus it is undone), we must address it professionally....do it immediately or put it on the product backlog. And consider how much it makes our previous information about velocity and progress a lie. (Always, to some minor degree, and possibly to a significant degree.)
* Just because we will always be imperfect does not mean we should give up on agile or agile principles or practices.
Can you put these ideas into action real soon? (Today is a good day.)
PS. I am not saying the Agile Manifesto and the Agile Principles are perfect. But maybe I am saying that our real worlds are messier than those ideas. Or so I see.
No comments:
Post a Comment