My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.

 

#NASA Agile Mindset

One of my favourite websites is Digg for the variety of interesting articles that they link to. In reviewing the list of articles today, there was a very interesting article that immediately struck a chord with discussions I have heard about being Agile and having an Agile Mindset.

The Problem

It turns out that a problem was encountered a few years ago with the Constellation Programs. The Ares 1 rockets were encountering excessive vibration that made it impossible for the astronauts to read the new digital displays. The last time NASA had to test for vibration problems was 50 years ago with the Gemini program with all their analog dials. So they enlisted the same group that did the testing for the Gemini program and tested vibration issue with the Ares 1 rockets.

It turns out that the astronauts were experiencing 4 G’s at the point that the solid rocket boosters were burning down. On top of that, the vibration caused by the solid rocket boosters burning down added another 0.7 G’s. It turned out that even the 0.7 G’s made even the largest numbers illegible.

It was at that time that NASA realized that they had a huge problem and started to investigate how they could possible correct the problem. They were investigating counter-measures to offset the vibrations and make the controls readable once again.

The Solution

In an act of pure problem solving genius, someone had the following idea:

“Instead of spending millions of dollars to ensure the astronauts are not experiencing excessive vibrations, what if we just synchronize the astronauts vibrations with the strobing of the display so that the reading would be legible?”

Awesome.

They went through a couple of iterations. The first attempt just tried a strobing frequency of 12 Mhz as the chair the astronauts were in vibrated at about that frequency. But in reality, the chair could be vibrating between 10 Mhz to 13 Mhz. So although it was better, it was not good enough. So finally they attached an accelerometer to the chair that would be used to exactly synchronize the frequencies between the chair and the display. It was perfect.

An Agile Mindset

Besides this being an excellent example of problem solving, I felt it also was a prime example of having an Agile Mindset and being adaptable. I firmly believe that a crucial part of Agile is adapting to the frequency of the project, team, and client. Rather that creating counter-measures to modify the external frequencies (Imposing practices), I feel Agile is about modifying practices and processes to put them in sync with the realities of the project. We all know there isn’t a one size fits all solution out there, but I thought this story was a great example on how adaptation is so important.

Recommending any practices without first being in sync with the project, team, and client is terribly risky. But once you are able to adapt and are in sync, then possible changes can be suggested and implemented to deliver more value to the client.

You can find the full story here.