I did a big Agile roll out and the team came up with a list of the things which might upset the Agile process – Agile gotchas. When I have sometime I will add suggestions for how to deal with them.
Continue reading
Author Archives: Steven Thomas
Agile Project Initiation
One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation.
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
Agile Terminology Comparison
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
Agile Risk Management
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
One Page Agile Standard for team of 350
For the last two years I have been rolling out a standard Agile approach to a department of 350. One part of the roll out strategy was to have a published standard. This was to make the goal / end-game obvious even if we didn’t initially mandate everything.
The first version of the standard, published Oct 2006, was a 50 page document. Earlier drafts had been quite short but in reviewing the document people kept asking “What does that mean?” so we’d add another section explaining it. All rather worthy but, aside from the initial reviews before publication, nobody read it. And it diluted the document as a standard, defining what must be done, as opposed to a guideline about how to do it.
We published version 2 today. This version of the standard is one page. I want to give people a simple checklist so they know whether or not they are following the standard.
Continue reading
XP Refactored by Stephens and Rosenberg
In their book “Extreme Programming Refactored: The Case against XP” Stephens and Rosenberg (2003) outline their reasons for not liking XP as it is published, but they also outline what they do like and how risk can be reduced when using an XP like process. I found their book rather long (and the humour rather unentertaining) but they made some good points and I made a few notes about their conclusions.
Continue reading
Mk II Function Point Analysis (FPA)
I wanted a summary of the function point counting process as the various manuals and books tended to be overly fulsome.
The effort involved in a count typically takes 0.2% – 0.4% of the total project effort for a new large development project (UKSMA, 1998).
Continue reading
Scaling Agile Software Development for Larger Projects
“Small projects can succeed through sheer force of will and a bit of luck. Medium and large projects require a more systematic approach” (McConnell, 1998, p. 36).
Most of the Agile Software Development methods are designed for small team sizes, for example the original XP team had 8 people, but what if we’re talking about 30 developers (let alone customers); what process should we use?
Continue reading