Be flexible on product scope. Not time and quality!

Dear reader,

This is the third and last part of “How to reach deadlines”. This is possibly the simplest part and it might be that I am kicking in open doors for many of you. But I am going to write about it anyway.

To be able to be fully flexible on your product scope it is best to work with agile development. If you have developed your product starting from the showstoppers going down the product backlog to the "good to have" stuff, you are in a quite good position to decide when to stop adding new functionality. Many times we think that a functionality is a showstopper, but I am sure that it might not be if you think really hard about it...So be smart and de-scope things that you surely can live without and add them as an upgrade later. Even fundamental things that have been on your showstopper list might not be a showstopper.
For example, with the very much hyped iPhone, I am quite sure that they wanted to have multitasking even in the first release. But they probably ran low on memory when opening too many applications, which creates the feeling of a slow UI etc. They simply had to make a decision not to include the multitasking; to be able to release the product with as good quality as possible. Many people have of course criticized Apple for not having multitasking, but they are selling like no one else, so I think Apple is not too sorry about it. In my opinion it was a very very wise decision and I know another company that might had been more successful today if they would have made the same type of decisions in 2005/06.

So the point is, always look at the scope first and be creative, the showstoppers you think you have might not be showstoppers and never compromise on time and quality.

Best regards

Anders

Scrum part 1: Why I like Scrum!

Dear reader,

For me Scrum has three things that makes it very good for execution of software projects:

1. It is a simple process
2. It uses a methodology that gives clear results and
3. It introduces soft parameters that drive efficiency

What’s good about the simple process in Scrum:

• If you can learn it by hart and do not have to peak in a process chart the chance of succeeding is much greater.


• If the process is simple top management, product management, sales and the rest of the company will understand what engineering is doing and hence it is much easier to get an overall buy-in from the rest of the company.

What’s good about the methodology in Scrum:

• You spend minimal time investigating requirements that might not be part of the product in the end.


• The daily Scrum meetings give you instant feedback on your development status. Or as Addison-Wesley put it in the The Mythical Man-Month (1975): Question: How does a large software project get to be one year late? Answer: One day at a time! This was written in 1975 and is unfortunately still true.


• The burn down graph/s give anyone in the company 100% transparency on the project status if you have a good project portal available in your ALM tool (application Life cycle management tool) or team collaboration platform (more on ALM tools in a later post).


• You have a very clear distinction between the one who orders the products and sets priorities and who delivers.


• When the sprint is running you have a very low risk for requirements creep i.e. the sprint is closed. And if anyone want new requirements they have to put them into the product backlog, and then they are always measured against the most important stuff that is in the product backlog, and when you do it, it is often very clear that the new requirements has a lower priority.


• In the end you often get a better products since you reevaluate the product after every sprint and you plan for the flexibility and change (change is not something evil that you feel when you are doing waterfall projects).


• Sprint Retrospective gives you part of the learning organization for “free” (for more information see my blog post from Saturday, 6 March 2010: The development process part 3!)

What’s good about the soft parameters in Scrum:

• The team is isolated during the sprint (i.e. efficient and easy to understand for the rest of the company)


• The daily Scrum meetings gives the team a nice peer pressure to deliver results every day. Who would like to come every day and tell there friends I did not do what I promised?


• Delivering in short iterations give a much greater satisfaction than working with something for maybe 1 year without seeing the results.


• When you are having the sprint planning meeting you get a buy in from the team to deliver what you agree on (do not forget to use planning poker if you want full impact of this soft parameter). This address many of the issues addressed in the book “The Five Dysfunctions of a Team” by Patrick Lencioni. Patrick Lencioni book explores the fundamental causes of organizational politics and team failure. In later post I will explain how I use this book and what it has give me and how you can use it to increase efficiency and trust etc.

Okay that was a long list and not the complet list! But as you can see it is absolutely attractive to start using some agile development :- ) for your project execution.

In part 2 of Scrum I will give you best practices and how to use Scrum in the most effective way in your development (imo) and write more about why you should use planning poker..

Thank you for reading and please give some feedback?

Anders