I have helped implement Agile project methodologies in a number of organizations. If your organization is anything like mine, you will be asked to define a project life cycle such that it can be explained, coached, and documented. I used to think the first step after this request was to work with management and educate them on the empirical nature of the agile process and that every project, customer, and team is different. As such, they will most certainly need something different in each case and therefore, a heavily prescriptive project methodology isn’t necessarily that valuable. Therefore, too many pictures and defined process is a bad idea.
Like I said, I “used” to think this was the right first step. I’ve found that this is an uphill climb (I’m sure you have too) and ultimately unnecessary. If a process design is what they want, you should give them one.
Agile concepts need to be “demonstrated” (and as soon as humanly possible) to show the real value. If some pictures will help, so be it. In that vein, I’ve created a few pictures of the overall process including two concepts that are probably unique to a waterfall organization, Iteration -1 and Iteration 0. Below is one recent example. I added a few artifacts from our current project process to show how they might be blended.
Again, this picture describes a blend of agility with the organization’s common, more prescriptive project methods (ie stage gates, risk plans, PDDs, etc). Everywhere I have worked, I’ve needed to blend these things into “agile” in one way or another. This was one approach.
The crux of Iteration -1 and Iteration Zero will be described in an upcoming post. In the meantime, if you have questions, don’t hesitate to email!
Update: A friend wrote and said, “hey, this looks like an iterative waterfall process. What gives!?” Is the above agile? waterfall? iterative? Scrumbut? Well, the point of the post was to illustrate that many organizations want to know that certain steps are being followed. The greatest value I think we can bring to organizations is to stop fighting about the presence of these artifacts and focus on what teams can deliver. Changing culture takes time. We often times dont have the ability to refuse to infuse some of the steps that organizations require…especially very large ones.
In my past, it has taken me months and months (and spent cycles) getting people “off the solution” to start “doing something”. In an attempt to get teams going, especially in organizations that don’t have agile experience, I think focusing my energy on removing impediments (like mapping the process) was a valuable start to protecting the teams. Over time, this process can change.
I do feel many organizations want stage gates (even though we hate them and know better). This visual depicts two very simple steps going from basic organization of the project team and vision / project definition, to construction (which includes all disciplines plus release if necessary), and then to the maintenance phase (warranty period). I think this depicts a basic approach that has worked well. That is indeed the point, isn’t it? The point is not to do “perfect Scrum”. The point is always, in the end, to add value.
Is it Scrum?
Does it need to be Scrum?