Proof that Agile Works

I came across a very interesting article yesterday from Cutter Consortium (read it here). The article provided evidence about how offshoring doesn't really save you any money, but it also showed how agile does save you money.

The conclusions were based on 20 years of research across 8000 projects. It compared projects of similar size in terms of lines of code. The average project cost $3.5 million. Offshoring it reduced the cost to $3.2 million. The agile project cost $2.2 million.

From a time perspective, the on shore project took 12.6 months, 9.6 for the offshore, and 7.8 months for the agile project.

From a quality perspective, the onshore project had on average 2702 defects, an astounding 7565 defects for the offshore, and only 1372 for the agile project. So even though the offshore project cost less, you made up for it in fixing defects.

This was a pretty comprehensive study and the conclusions are pretty clear. I have been involved with offshore work, and to me that large physical gap between the user and the developer proved very challenging. Organizations I saw struggled to communicate requirements across the gap. I've always been a strong believer in close interaction between developers and users.

Not Waiting for Great

Wired Magazine had an interesting article in the September issue titled The Good Enough Revolution. The article discussed how people are no longer demanding the best, but things that are good, portable, cheap options. Music was one example they used; most people prefer the low quality of MP3s over the higher quality a record can deliver because MP3s are more portable.

This is actually a theme I try to push with my clients. We could spend 9 months building an application with all the bells and whistles or 3 months delivering just the important stuff. It's much cheaper, and if you deliver faster, you realize the benefits sooner. I'll admit I don't have a 100% success rate at getting clients to see my perspective, but I'll keep trying.

Getting people to change

I've been encountering a pretty common situation with some of my clients. While they seem to get what agile is about intellectually, they are still doing things the old way, seemingly unable to break their old (bad) habits.

A colleague of mine, Donna Brighton of the Brighton Leadership Group, introduced me to a new model for change, the ADKAR model, developed by Prosci.

• Awareness
• Desire
• Knowledge
• Ability
• Reinforcement

So the first step is awareness. Are people aware of why they should adapt agile? Are there project failures in the organization? Do projects miss dates, fail to deliver on quality, or run over budget? How can agile solve these problems?

Next, do people have the desire to change? If they've come to accept the status quo, maybe there's no incentive to improve.

The third step is knowledge. This is where training would play a part, so people can understand the desired future state.

However, knowledge doesn't guarantee ability. Can people try the new approach without fear of punishment? Is there support in place to let them succeed?

Finally, when the desired behavior comes about, what is being done to make sure people don't fall back to their old habits?

I have always used the term Organizational Change Management (OCM) when I talk about this type of change, to distinguish it from technical change management such as scope change. I have always approached OCM from the organizational perspective; how do I get the organization to move in the new direction? What I haven't thought about much is that an organization is made of individuals, and each person will make this change journey at their own pace. My effort to change the organization must take individuals into consideration. I'll have my early adopters that can help me. I'll also have those late adopters that I have to account for. I can't assume everyone will change according to my OCM plan.

As for my clients, I think the awareness is there, so it's time to focus on the other steps to get them on the road to agility.

Afraid to Fail

I am reading the book The Art of Possibility and came across an interesting section about failure. There is a story about the composer Stravinsky. When questioned about one particularly difficult section of music, he replied that he didn't expect anyone to play it, but to sound like they were trying to play it. His purpose in writing the passage was to get someone to fail when they attempted it.

Throughout our life, we are told failure is bad. However, it's through failure that we can learn. Thomas Edison didn't think his earlier attempts to invent the light bulb as failures, just steps pointing him in the right direction. Abraham Lincoln had some political setbacks before eventually becoming President of the US.

So when is it ok to fail? If you're trying a new technology, running a pilot project is a good idea. That way, if it does fail, there isn't a lot invested, and you learn something from it. If you're trying to run a 4-hour marathon and come in a few minutes slower, it could be looked at as a failure, but you still accomplished something.

We need to set stretch goals for ourselves. If we don't accomplish these goals, we've still increased our abilities and learned from them. If we always sit in our comfort zone, we never grow.

A stretch goal for me over the past few years has been to develop as a public speaker. I still get nervous anytime I stand in front of a group, but now I am much more composed. There have been presentations I've done in the past that haven't gone as well as I would have liked. I've learned the importance of spending a lot of time practicing before any presentation, even if it's just a project kick-off meeting for a small project team. If I wasn't afraid to fail, I would have never gotten to this point.

So, are you willing to fail?

Photo Credit: Ian Lewis, licensed under Creative Commons

Projects to the Point Conference - Final Wrap-up

I'm home from Cairo. The P2P conference wrapped up on Thursday. I am already looking forward to the 3rd annual conference next year.

The agile track for the conference wrapped up with a panel discussion. In addition to myself, the panel included Jim Cundiff, Jesse Fewell, Dave Prior and Thushara Wijewardena (Dave and Jim pictured here during an earlier session). One of the topics we discussed was when to use agile.

I tend to look at agile as a tool, just like traditional project management tools, ITIL, Six Sigma etc. I think you have to look at your particular project and decide if this is a good project to apply the agile tool. If you're talking software development, chances are that the answer is going to be yes. I pointed out in construction, agile isn't the best approach. If you're building a bridge, you need to have all the requirements before you start construction. However, even here, you could use an agile approach to the design stage.

Dave Prior used the term "enlightened project manager" to describe someone that knows how to apply the right tool at the right time. So do you have all the tools you need in your toolkit?

Day 1 - Project to the Point

I am in Cairo and the first day of the Projects to the Point conference has just wrapped up. Today featured a number of keynote speakers, including the current and immediate past chairs of PMI (Ricardo Vargas and Philip Diab), as well as H.E. Dr Ahmed Darwish, Minister of State of Administrative Development for the Egyptian government.

The Arabian Gulf Chapter of PMI recently conducted a survey into project failure. The leading cause, based on their failure, was project managers without the proper training/experience to run projects. Mr. Diab cited the young workforce in the middle east region as a factor in being able to meet the project management demands.

One of my presentations tomorrow is on knowledge management (KM), very relevant based on today's comments. A part of KM is being able to implement coaching and mentoring to share tacit knowledge among project managers. Tacit knowledge is that stuff that isn't easy to communicate, like how to run a project successfully. It requires more time commitment for experienced project managers as they need to bring their protégées up to speed as a master craftsman trains an apprentice.

Multi-tasking and Kanban

I was at a presentation on Kanban put on by the local agile group tonight. I'm familiar with Kanban, but still picked up some good information.

One thing that struck a chord with me had to do with multi-tasking. In a previous blog post, I've discussed how multi-tasking doesn't work. In tonight's presentation, a statistic was shared that software developers waste 20% of their time when they are multi-tasking.

Kanban is the solution. The idea is you only take 1 task at a time and work until that task is done before you grab another one. You don't have a long backlog of work and you're not trying to manage a full plate of work with all the task switching that goes with it.

I find I'm more successful when I take this approach to work. At the beginning of the day, I figure out the tasks I need to accomplish. While I'm working on a task, I do my best to avoid interruptions. I ignore my email and avoid other distractions (or at least I try). I'll catch back up on email and other stuff when the task is done. It helps when I can keep tasks to an hour or less. If it's a big project, I break it into smaller chunks.

So if you find you are often interrupted, look at how you can break your work into small chunks and turn off the distractions while you complete your task.