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 →
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 →
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 →
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 →
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.
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 →
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 →
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 →
All the major Agile methods have different terminology. I try to use traditional terms rather than the term used in any of the Agile methods. I’ve put together a table that gives a rough comparison of the different terms. Continue reading →
Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management. Continue reading →