This post is partly about the game of rugby and partly about the agile method called Scrum. Although I’ve a lot of experience with Agile approaches to software development, including Scrum, I must confess that my experience of rugby is limited to watching the All Blacks during the Rugby World Cup. Despite that caveat the theme of this post is that rugby is a better analogy for agility than Scrum is.
Continue reading
Tag Archives: scrum
Use a WIP Limit During a Sprint to Avoid the Cataract of Stealth
Mike Lowery – a fantastic Scrum coach – has written a post called It might look like rapids, but it’s still a waterfall. This is part of Mike’s series on Scrum coaching patterns (or team anti-patterns) and in this post he concentrates on the “The Cataract of Stealth”.
Mike starts by outlining how a sprint should look: “you should see a sort of tag team effect where 1 or 2 stories are in flight, as they get close to being finished the next stories are kicked off”. In contrast “The Cataract of Stealth” means the team start too many user stories at the same time thus risking finishing any of the user stories at the end of the sprint. Often this is caused by team imbalance, e.g.. too many developers for the number of testers.
The cataract of stealth is a real problem and I recommend people have a look at Mike’s post for more detail including his very sensible solutions. (It also has shades of the Overcommitment Bear Trap.)
I just want to add one thing. What Mike’s post highlighted for me was a (small) convergence of Scrum and Lean/Kanban thinking. The constraint on having “1 or 2 stories” in flight during a sprint is work in progress (WIP) constraint – a concept straight from Lean/Kanban.
New Agile Teams and the Overcommitment Bear Trap
The most common problem I’ve seen with software development teams is over commitment. Invariably individuals and teams are overly optimistic about what can be done in a certain time period. There are any number of reasons for this including arbitrary management deadlines and the team not pushing back, the developers desire to please, and just the fact that estimating in software development is hard.
Agile development teams are just as prone to this problem as any others. Every team I have helped transition to Agile has stepped into this bear trap almost immediately. And forewarning them doesn’t help. I now see stumbling into the trap as a valuable lesson and an essential step in the process of getting more mature about software development. I don’t mean maturity in the sense of the SEI’s Capability Maturity Model, I mean maturity in the sense of growing up, being realistic and accepting the limitations in themselves, their team and the organisation.
The difference about Agile, compared to traditional approaches to software development, is that Agile offers techniques to avoid the over commitment bear trap.
Continue reading
Agile: I Prefer Hype to Ignorance
The good news is that Agile has crossed the chasm (Moore, 1991). On the down side there has been, and is, a lot of hype and hyperbole around Agile, Lean, Scrum, XP and Kanban, etc, etc. In particular, and despite the Agile Manifesto, the meaning of the term "Agile" has become very diffuse. So much so that there are many people, like a colleague of mine and one time Agile fan, who now says "I don’t talk about ‘Agile’ any more; it doesn’t mean anything".
I find the hype annoying, and Agile’s loss of meaning exasperating, but I also think it an inevitable part of progress.
Continue reading
Glossary definition for “Agile”
I was asked by a corporate Programme Management Office (PMO) to provide a glossary definition for “Agile”. This is the definition I gave them.
Continue reading
Using a Product Led Matrix in Lean-Agile
I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.
Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.
Continue reading
Agile Change Management
My background is running Agile projects for external customers in the context of a contract, often fixed price. That influences my focus on good project management and specifically change management. Change Management is the mechanism to combat scope/feature creep.
Within the Agile world scope change is expected and time is considered more important than functionality. So if something has to give to allow change then functionality/scope loses and time wins. To do this the customer must make Requirements Trade-offs. The Customer directs development in Timebox and minor changes are just accepted. Big changes are handled different depending on whether it is a change to the Release Plan or Timebox Plan.
Continue reading
Agile Project Management
Traditional project managers are often uncomfortable with the apparently unstructured nature of agile software development. This article gives a definition of project management, and then goes on to cover traditional project management, why software development is different, how agile project management is different, and the role of an agile project manager.
Definition of Project Management
According to Wikipedia: Project Management
Project Management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.
Unlike operational activities, which are on-going, a project is finite with a beginning and end. Each project is trying to achieve a clear objective and bring about change. Not surprisingly in the software development world that typically means building software. Project management has to balance scope, quality, time and budget to achieve the given objective.
Continue reading
Agile Lifecycle / Agile Heartbeat
All software development methods, including the Agile ones, have some sort of underlying project lifecycle. System Development Lifecycle (SDLC) is the common name for a software development process, but in the Agile world I prefer calling it a “heartbeat” reflecting the organic nature of an Agile project. Some of the big Agile methods don’t make a big deal of the heartbeat and others do. Some have such abstract lifecycles that it is actually hard to know what activities to schedule. And they all use different terms for the same thing. I have pulled out the common activities to create a generic agile lifecycle.
Continue reading
Evidence for Agile
Although “everyone is doing it” is a reason to consider Agile it isn’t necessarily a reason to go Agile. I’ve thought it useful to outline reasons for going Agile and where possible provides research data to back up the argument. The data can be used to form the basis of a Business Case for Agile.
Continue reading