Product SW quality (part 2): The quality factor Reliability

Dear reader,

Today I will drill down more into the details of the quality factor Reliability.

The following three measures are of importance:

• Mean time between failure (MTBF),


• S-curve (accumulated number of found defects over time)


• SW complexity metrics (i.e. Cyclomatic complexity).

MTBF:
For this measure I think you should included “everything” that is a failure. Not just a crash or restart of the SW, but also when the product hangs in some way. It can also be very good to include a sub-measure like mean time to fist failure (MTTFF). Since MTTFF impact very much on the customer perceived reliability of your product.

S-curve:
The S-curve is mostly used to understand the quality maturity (or reliability status) of your product. The accumulated number of found defects over time is a measure that I think tells you the most when it is 100% connected with the correctness quality metrics like number of open defects, pass rate and test coverage. You also need testing done consistently and defect needs to be registered consistently in your ALM tools otherwise you might be fooled.

SW complexity metrics (i.e. Cyclomatic complexity)
This measure is not very often used but I believe many organization would be able to increase the SW reliability a lot if used the right way.
Cyclomatic complexity will tell you how error prone a function, module, method or classes is. If you would like to know more details look at this Wikipedia link: http://en.wikipedia.org/wiki/Cyclomatic_complexity.
The important part here is to make sure that your cyclomatic complexity is lower than 10 for all modules within your product. Otherwise the risk of faults increases a lot and your SW reliability is at risk. A number of studies have investigated cyclomatic complexity's correlation to the number of defects contained in a module. Most such studies find a strong correlation between cyclomatic complexity and defects: modules that have the highest complexity tend to also contain the most defects. For example, a 2008 study by metric-monitoring software supplier Enerjy analyzed classes of open-source Java applications and divided them into two sets based on how commonly faults were found in them. They found strong correlation between cyclomatic complexity and their faultiness, with classes with a combined complexity of 11 having a probability of being fault-prone of just 0.28, rising to 0.98 for classes with a complexity of 74 (Rich Sharpe. "McCabe Cyclomatic Complexity: the proof in the pudding". Enerjy.).

As mentioned before there are a lot of automatic tools available and I am looking forward to TFS 2010 that will also have this measure included.

Happy Ester!
Anders

Scrum part 2: How I practically use Scrum!

Dear reader,

I am not religious when it comes to use a methodology; hence always being pragmatic is key for me. Today I am going to write about how I would like Scrum to be executed in a project and what practical things you should think about.

First of all, as I have been writing about in the 3 product development posts, Scrum is part of the execution part of the project. What I mean with that is that you have to find a good point between when you exit the waterfall process and moves into the agile development that Scrum is. For me this happens when you reach the point in the requirement analysis phase where you know enough of what you need to implement on a high level and where top management has enough data to make a business decision on starting spending money (i.e. putting more resources on the project). This stage is for me often after a small team with the product owner, lead developer, chief or system architect and system designer, usability experts etc has done a top level pre-study with estimations (at this stage a +/- 25% accuracy is very good). Now you have your stack ranked product backlog (based on maybe focal point analysis) and you also have all your work included (not just the coding).

With ALL work I mean not just coding: All testing: Unit testing, integration, regression, user stories, more requierment analysis, documentation, bug fixing, platform testing 32/64 bit, platform set-up time, virtual development environments, installation programs, packaging, training etc.... The ALL work part is what is often missed when a product owner or a manager asks a developer how long time it takes to develop function X. This is often the 3 times factor many people use to get the right time estimated. Any way if you done this right the +/- 25% accuracy is not too bad and that can often be handled within the Scrum execution process (if you don’t have a backlog that only consist of show stoppers of course).

Now you have started the execution process, you have assigned the resources and the Scrum Master/s are ready to go. First you need to divide the work from the top of the product backlog to the Scrum team/s and you have to find all dependencies between the teams. I like to have a project manager running the top level dependencies between teams making sure nothing falls between chairs and an integration team that can integrate the deliveries.

In each team it is great to use planning poker for sprint planning session. Why? Many developers are not the most extrovert persons and will not share their great wisdom if not forced by a poker game :-). Also if everyone is involved you will get commitment (again the great book “The Five Dysfunctions of a Team” by Patrick Lencioni).
Then the execution of the sprint is straight forward and the daily meetings should always be used with great focus but I am not 100% religious around the pigs, chickens and or the 15 min it is okay if it is 20-25 min as well if it is produtive.

A very good support in the execution is a good ALM tool. You can use Microsoft Team Foundation Server (TFS) as the ALM tool with the task board add-in with virtual post-it notes (for more on this look at this site: http://www.scrumforteamsystem.com/en/default.aspx ). Also use Skype for Scrum meetings when we have several locations involved. I recommend to use more or less everything in TFS like sources control, testing tools, data collection, reporting, daily builds and project tracking (with project portals for burn down graphs etc). Since TFS 2008 does not have very good support for agile development I recommend the use of the Conchango template for TFS (hopefully the TFS 2010 release will improve, it seems to be a lot of nice things in the next release for this and for test support).

Okay that was a lot for one post! There is a lot more and I will see if I can write more on the execution topic, but now I am of for a two weeks’ vacation and will not write any posts for some time.

Have a great day!
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