This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Tuesday, May 27, 2014

Dealing with Complexity in Software Projects - The theory that explains why Agile Project Management works


Why do projects fail?

This is a question that haunts all project managers. Good and bad, experienced and beginners, Agile or non-Agile. The reason for that is simple: we believe that if we crack the code of why projects fail, we will be able to avoid failure in our own projects. After all who does not want to be in a successful project?
We believe that if we crack the code of why projects fail, we will be able to avoid failure in our own projects.
But before we can can answer such a difficult question, we need to understand the factors that influence project failure. Many will immediately say that lack of planning or bad planning are major causes for project failure. We've all been told that more planning is the solution. And we have been told that the "right" planning is the solution. Sure, we all know that, but does that "right kind of planning" look in practice?

Enter Agile...

We know that "the right planning" is the solution, but we need to have a functional definition of what that "right planning" looks like. Agile has contributed greatly to further our understanding of software projects. For example: thanks to Agile we now can confidently state that individuals and their interactions are a key enabler for successful projects, not just "the right kind of planning". But there is more...

We are also starting to understand that there are some fundamental failures in the existing Theory of Project Management. Thanks for researchers like Koskela and Howell[1] we even have a framework to analyze what is wrong - very specifically - with traditional Project Management. Most importantly, that framework also helps us understand what needs to be different for projects to succeed in the new world of Knowledge Work.

In the article below (sign-up required) I explore the differences between the existing theory of project management and what Agile methods (such as Scrum) define as the new way to look at project management.

This paper explains some of the ideas that are part of  the "Chaos Theory in Software Projects" workshop. In that workshop we review the lessons learned from Complexity and Chaos theory and how they apply to Project Management.

The goal of the workshop is to give project managers a new idea of what is wrong in the current view of project management and how that can be changed to adapt project management to the world of Knowledge work. To know more about the workshop don't hesitate to get in touch: vasco.duarte@oikosofy.com.

[1] Koskela and Howell, The Theory of Project Management: Explanation to Novel Methods, retrieved on April 2014
Picture credit: John Hammink, follow him on twitter

Labels: , , , , , , ,

at 06:00 | 0 comments
RSS link

Bookmark and Share

Friday, May 02, 2014

Real stories of how estimates destroy value in Software Development


A friend shared with me a few stories about how Estimates are destroying value in his organization. He was kind enough to allow me to share these stories anonymously. Enjoy the reading, I know I did! :)

The story of the customer that wanted software, but got the wrong estimates instead

Once, one of our customers asked for a small feature and, according to this customer it was quite clear from the beginning what he wanted. Alas, in my experience things often don’t go as planned and therefore I have added a good buffer on top of the needed estimates. Just like all developers I know do. Every day.

However, the story was about to get more interesting. A bit later, the sales team said those numbers were too high. "The customer will never accept those numbers!", they said. "And we really want this case."

After much negotiations we reduced our estimates. After all, we had added some buffer just in case. So, we reduced the estimates on the account, and I heard myself say (I should have known better): "Well, I guess that if everything goes well we could do it in that time."

My real surprise was that, a few days after the estimates were given to the sales team and the customer, I heard from the project manager that the company had agreed a Fixed Price Project with the customer. "That is madness", I said to the sales team. I felt betrayed as a developer! I had been asked for an estimate for the project, but I was tricked into accepting a Fixed Price Project through the estimation process! During the estimation I was not told that this would be a Fixed Price project.

The result was that the project was delivered late, we exceeded the estimates we gave. However, I did learn a valuable lesson: If you are forced to create estimates and the customer requires fixed price then never obey wishes from sales team: their target is different. Or, alternatively just do away with the estimate process altogether: just ask the sales team what number they want to hear ;-).

History repeated: never trust the sales team to handle estimates

A few months ago a customer called in and requested a small feature for their existing product. They were asking for an estimate. Part of the work was very clear and would be very easy to implement. But there was a part that wasn’t that clear. After some pre-analysis and discussions with other development team I knew about what would be needed to finish the job. Unlike the story above, this time I knew the customer asked for a Fixed Price Project and therefore added some buffer – just to be on the safe side.

After carefully estimating the work with the team we sent the total estimate to the sales team. This estimate included everything that was needed: from analysis, implementation, test, deployment. I did not split the estimates into its components parts because I didn’t want the customer to think that testing would be optional (Yes! It as it has happened before).

However, the sales teams split my estimate into the different roles. Big mistake! Magically the estimate that the customer received was half-day shorter than the one we provided. Not a big difference, but I learned my lesson!

Surprise number two was about to hit me: The customer said they hadn't used some hours from a previous contract and that they should get a discount. Long story short, when the project was started we had to reduce our "cost" to 50% of the estimation I had originally given to the sales team. I learned that I should never trust the sales team with mathematical calculations!

We did manage to deliver the feature to our customer, thanks to some very aggressive scope management, this meant that we had to deliver functionality that was requested, but did not perform as well as it could have if we had been allowed to work on the feature from the start, without the estimation back-and-forth.

I did learn my lesson: If you sales team doesn’t know how to sell software projects, and before you given them any estimates, add even more buffer on top of things learnt from the previous story! ;-).

Estimation as an organizational smell

Certainly there are many organizations in the world that do not go through similar stories as these. However, many still do! For those organizations that are affected by stories like these I suggest that we look at different ways to manage software projects. #NoEstimates provides a clear alternative that has proved very successful in the past. For example, in the paper below I mention a story where a team would have given an estimate within 4% of the actual time it took the project to complete, if they had used #NoEstimates!

The Silver Lining

The story continues, however. Here's what my friend added at the end of his email:

Well, after all having successfully changed the mindset of many in the company and in our team. We are already doing quite well.

Now I do things differently. The first thing I always discuss with the customer is how much money they would like to spend for the work they want to have done. This already gives me a good picture if we are even close in understanding of the amount of work that is necessary or more in the direction of “insane”.

Today I don't negotiate traditional contracts with my customers. Every job is now build on trust, communication and transparency.

Labels: , , , , , , , ,

at 11:20 | 8 comments
RSS link

Bookmark and Share

 
(c) All rights reserved