Continuous delivery gives the capability to identify a requirement, code a solution, test it, and release it within a few hours. As I see it continuous delivery will become the norm amongst software companies. I think the trend is inevitable.
Continue reading
Tag Archives: lean
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.
A Lean-Agile Perspective at the Project Research Institute (part 2)
Last year I wrote a series of blog posts for the Project Research Institute of Athabascau University in Canada. As I mentioned before the PMI’s aim was to introduce their relatively mainstream audience to an Agile perspective. My aim was to show how the principles and practices of Lean-Agile Software Development offer creative solutions to general project challenges.
The PMI has now published all of my posts, including:
Management on the Ground
You have to keep your feet on the ground when others want to put you on a pedestal. After a while on a pedestal, you stop hearing the truth. It’s filtered by the henchmen, and they read you so well, they know what you want to hear. You end up as the queen bee in the hive, with no relationship with the worker bees.
Bill Burns, CEO of Roche Pharmaceuticals
quoted in Goffee & Jones (2006), p. 43
One of my project managers recently mentioned that, despite being a programme manager, my own management style is quite "hands-on". In the sense of being on the ground with my team rather than in the technical sense although the two often come together. This approach has held me in good stead over the years.
Others, like Bill Burns quoted above, have realised dangers of being distant from the people doing the work and the corresponding benefits of being on the ground. I thought I’d take a quick look at some of these previous advocates of being on the ground:
- Military Commanders on the ground
- Management by Walking Around (MBWA)
- Toyota, Lean and Genchi Genbutsu
I’ll wrap up by having a quick look at the Agile practices that help me be on the ground.
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
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
Minimum Releasable Feature
There are a variety of terms in use for chunks of functionality that are worth releasing and the requirements that describe them. Desirable characteristics for these features include being minimum, releasable, and valuable. At the moment I am using the phrase Minimum Releasable Feature (MRF) so I thought I’d explain why and some of the alternatives.
Continue reading
Two Pillars of the Lean Thinking House
The Toyota approach to lean is quite sophisticated and is based on a model called the Lean Thinking House (Larman & Vodde, 2009). The Toyota model includes two pillars:
- Respect for People
- Continuous Improvement
These pillars struck a cord with me. I’m normally more interested in what practices work than in values and principles however these two phrases seemed to nicely summarise my approach to work and are key themes in my career.
References
Larman, C., and Vodde, B. (2009). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley.
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