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!

An Agile Project Lifecycle (Click Image to Enlarge)

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?
No.

Does it need to be Scrum?
No.

Organizations stagnate for a variety of reasons. One that I have come to recognize through the work of Dr. Russell Ackoff is a systemic, abiding fear of failure. Most leaders are gripped with this fear. If you think through our accounting structures in public and private organizations you start to understand why employees find complacency as the “safe bet” to career growth over evolution and change.

Fear Explained

To dig deeper, Dr. Ackoff describes the two key types of errors: errors of commission, and errors of omission. An error of commission is one where something is tried and later fails. Our current accounting systems are built to track these errors and they do it well. As do our internal “cultural” tracking systems through mores and norms.

Jim’s initiative was a complete disaster! What a terrible leader and failure he must be.

This is compared to an error of omission, where an organization or leader fails to do something they should have done. There is a stark contrast in the way our culture and accounting methodologies track this type of failure. In short – they DON’T. In your organization, how often are employees blamed for NOT creating change? We pay lip service to improvement, but rarely do employees have their feet held to the fire regarding too little change and missed opportunity.

We’ve Learned Our Lesson

So what’s the lesson? For employees, the lesson is that the only error that we seem to track, and can have an effect on your longevity, career and social standing are errors of commission.

You effed up Jane! Now what do you have to say for yourself!

Yes, our organizations tend to focus on errors of commission and track failures this way. Now ask yourself this question. What do you suppose is the most likely strategy employees utilize to protect themselves from the fear of failing when they try new things?

You guessed it… They try NOTHING. They play not to lose…and sadly lose the ability to be great in the process.

Maybe we don’t have exactly what we want, but as they say, no one’s ever been fired for buying IBM.

Leadership Opportunities

The key to solving the complex, sometimes mind boggling system problems we face every day is to help craft an environment that accepts failure and disdains apathy. Those creative souls trapped in your organizations and on your teams will never produce amazing results if leaders don’t free them from the crippling (and real) fear of failure and begin to demand experimentation.

This will ultimately teach us, allow us to develop, and expand our ability to solve complex and growing system challenges. Paradoxically, failure allows us to learn how to be great. Maybe we should start looking at failure as evidence of the drive for greatness.