Product SW quality (part 1)

Dear reader,

Nice to be back after a relaxing vacation. In this first post about product SW quality I want to focus on number 2 from my post on the 22nd of February. Lack of quality control and good quality code measures (software Metrics). Most companies measure SW quality in some form, for example number of open defects often connected to a ranking system. This is one simple way of measuring product quality, even if it standalone will not tell you very much. To be able to get a full overview of your products quality you need more than just one measure, you need to find a number of measures that give you the full picture of your product SW quality. However, first I want to elaborate some on what I mean with SW quality. There are of course a lot of things that can fit into this term. My number one focus is on product SW quality and the main quality factors for me are reliability, usability and correctness. Of course you also have many other factors like maintainability, reusability, portability etc but it is not as important as the other three in succeeding with a good customer "perceived" quality level (looking from the out side an in).

Below you can see the metrics I think you need to use on a top level:

• Reliability: Mean time between failure (MTBF), the S-curve (accumulated number of found defects over time) and SW complexity metrics (i.e. Cyclomatic complexity).


• Correctness: Open defects rank of A, B and C, % pass rate for test cases (all test areas: i.e. function test, integration test etc), test coverage, performance metrics.


• Usability: Performance metrics (latency), effectiveness, efficiency, user satisfaction (or perceived quality).

If you make sure you get reliable data on the above quality factors you are getting very good input into how to improve you product quality. More importantly you will also have the right information on your product quality status to be able to make the often hard decision on when to release you product to real customers.

Even the most mature companies I worked at best case use most of the correctness quality factor and MTBF from the reliability quality factor. This often lead to products that are released too early (i.e. with too low quality), since missing the S-curve and a good complexity metrics you miss 2 out of 3 metrics for reliability. The SW complexity metrics has been around for over 20 years, but I have yet see any company using them, even if there has been automated tools available since at least 15 years back. I myself did my master thesis at Volvo Cars in 1995 on SW complexity metrics (I do not know if they ever went ahead and implemented my suggestions :-). However in TFS 2010 you will find a automated tool for measuring Cyclomatic complexity, maybe that will make it more frequently used?

That’s it for today. In coming posts I will drill down to details for each quality factor.

Kind regards
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

The development process part 3!

Dear reader,

In the first 2 post on the development process I have written about the business process and project execution model. But before I talk about the feedback loop process which is the 3rd part of a successful product development process, I just want to also finalize with some comments on the 3rd part of the project execution model the maintenance phase. Basically the maintenance phase is more or less a copy of the before execution phase and the execution phase but often in a much less or strict form. It can often be run with only two light wight business decision and using Scrum as execution model on the existing product backlog.

Okay now back to the feedback loop process. It is part of a very important part of the so called learning organization. As I stared of with in my first post I have yet to see any organization that know 100% what they are doing and a common mistake is that most organization does not learn from the mistakes or even from the good things they do. Or as George Bernard Shaw put it in one of my favorite quotes: “We learn from history that we learn nothing from history”.
Also since many organizations often are on the level 1 of the CMMI-model they trust heroes in there organization to fix the big issues and come through in the end, however sometimes these heroes leave your company and then you need a process that anyone can use and repeat the success of the last time and a process that is world class. Therefore you need a working feedback loop process.

So, how do you setup a working feedback loop process. First to be able feedback things back to something you need process and other frameworks in place to start with. The process and frameworks you need are the following:

• Process for all part of the company: Sales & Marketing, development, support, operations etc…


• Product development checklists for product managers, project managers and developers to have as support tools when developing new products.


• Written down clear roles and responsibilities

Now if you have the above, very good! You can now start using a controlled feedback loop process and become a learning organization (if not you have some work todo :- ). So how does the feedback loop work. You should introduce in your product development checklists that the project should have lessons learned sessions on a regular basis and also use the part in Scrum that is used after every sprint that is called a Sprint retrospective. These two tools and on the softer side work on a company culture that want to improve productivity hence feedback improvements continuously.

The trick then is to get your employees to feedback lessons learned sessions and sprint retrospective feedback to you or any manager within the company that might need to have the feedback and in 95% of all cases you as manager can feedback this data into any of the above 3 things (i.e. checklists, roles and responsibilities or your process). And voila, you have feedback loop process and have become a learning organization. Sounds easy? Yes but it is not so easy in reality, there are many pot holes you might fall into. For example do not implement a huge database where you store all lesson learned and hope that people would be able to ready it all…It will not work you will be overwhelmed with data. Keep it simple and try to feedback and upgrade process, checklist and roles and responsibilities on a regule basis so these documents become living document, then you also have a much bigger chance that you will get your employees to read them more often.

Have a nice weekend!

Anders

The development process part 2!

Dear reader,

Yesterday I wrote about the top level of the product development process, today I am going to focus on the project execution model. This part is the core part of the product development process but I will not work without the business process.

The project execution model is divided in 3 parts as well.

1. The before execution phase


2. The execution phase


3. and the maintenance phase

In the before phase is where you decided what kind of product you would like to develop. Agile purist might say that that 1 and 2 should be one and that you can start with just a few user stories and from that build the product sprint by sprint. However I have yet to see any product being built like that. Even if you are very agile, product management need to have a vision for the product already from the start and product management probably have to have a business case and wanted delivery date etc. If not top management will not spend any money on the project. So most of the time you must have most of the framwork for the product given, a maximum budget and a delivery date even before your start any of the project execution. If we agree on this, then you need to do no 1 as a pre-study and possible a deeper design an system analysis (even if you are very agile) to be able to at least set an optimal system architecture, high level requirements estimates etc. When you have your top level requirements stack ranked and guesstimated the effort i.e. the product backlog (see my other blog post on how to do the stack ranking with for example focal point), you now have a good top down view of the overall project.

Now you have an high level time guesstimated and a wanted delivery date, a budget and a product backlog (i.e. your system requierments). Now it is time for the business decision on the top level business process to make a decision on the possible bright or dark future for the product. If it is a bright future it is time to start the execution phase (2) using for example an agile method like Scrum. I think Scrum is very good to use for the execution phase of most SW development projects (more indepth evaluation of Scrum and best practice in a later blog post).
In my opinion an agile project should only be agile in two parts or maybe only one (it depends on how much money you have :-). But normally you should only be agile on the requirements because the delivery date, the quality and resources /cost should or is almost always fixed. Now execute your project sprint by sprint to reach your targets.

If you have a very mature organization with a good test organization and test cases, daily builds etc. You might be mature enough to release your product after the last sprint, if not always plan the last sprint with new features as a beta release and try to learn how many/long you stabilization sprints should be.

I use this mix of a business and execution model since no one model often give you all what you need. This way of working is a mix of the waterfall model and the agile project execution model.

This is it for today…

Kind regards
Anders

The development process part 1!

Dear reader,

A working product development process is very important to have if you want to be successful delivering product within time, budget and with the right quality. Your process needs to be more or less tailor-made for your own organization, however I will write about some very important building blocks today and in the coming weeks try to give more details into all building blocks. The process must consist of at least 3 parts:

1. An overall business process (with business tollgates)
   


2. A project execution model with: milestones, execution methodology (possibly an agile model), checklists, etc.
   


3. A feedback loop process to always improve the above

Why an overall business process?
Today every one talks about using scrum and being agile. However it is not enough to just send a few people to a Scrum Master course and tell your developers to work with scrum. I really like scrum and it is a very good execution methodology but it does not really support the business side of things. Hence you also need to provide a business tollgate process on top of your project execution model to make sure you use the companies development resources in the best way producing customer and business value. I see the need for a minimum of 4 business tollgates.

1. To start a pre-study/design phase


2. To start execution


3. Release of the products to customers


4. Ending the products life

Each business tollgates need to have in-put from product management on the business case and market, from development on resources, quality and project status etc.
This process should be supported by a steering group with the right management people attending for decisions. In a company smaller than 200-300 people it can often be the companies normal management team + the head of projects / program management.

More about the project execution model soon….

Kind regards
Anders

So how do I make sure I get the right requirements for a product?

Dear reader,

Of course it is not the R&D/development department that actually should go about and collect the requirements for the product. It should be the product manager (or product planner) that collects the requirement on a high level. Often the product manager listens and talks to the customers and follows the latest technical trends and so forth. There are seldom any issues in these areas if you have a good product manager you will normally have the right requirements in these areas (however a bad product manager can kill any product). The difficult parts are often the non functional requirements, usability or requirements on perceived quality or performance. To get these requirements right you might need to push the CEO or head of product management in the management team to improve the requirements gathering process to include the right stakeholders. Stake holders that are typically not included are operations (including the installation team), usability experts, executive management (to make sure you get early feedback, otherwise you might have to make changes later) and customer support.
Now! When the product manager have collect the “right” requirements your system design department and chef architect should add all technical requirements that are needed in the pluming to fulfil all top level requirements and start a pre-study (more on the process when to start new pre-studies in later posts) to quickly assess the work effort for each work item on a top level. In the meantime the product manager need to start ranking the requirements 1-n. If you have a very big number of requirements you need some kind of tool to help you prioritizing the requirements. I recommend the product manager to use IBM Focal Point (IBM® Rational® Focal Point™). If you have a very big number of requirements you should make three piles:

1. These are all must have (i.e. without these there is no product)
   
2. These are the requirement that will give your product an edge, but you could live without them if you must
   
3. These are good to have stuff

(Please note: if you have less requirements you can just use a Scrum type product backlog to have control over all your requirements.)
However if you using the 1, 2, 3 approach above you do this because you have a limited budget or resources and a fixed wanted delivery date for you product. In most cases you can forget about the 3 in the first release of the product so it is all about doing a focal point on number 2 and get all the most important requirements from this group into the product within you budget. Ready more about Focal point here: http://www-01.ibm.com/software/awdtools/focalpoint/

In the end, independently what type of tool you use, in my opinion you need to have a long list of the requirements that are individually ranked from 1-n, no. 1 being the most important requirement and 2 the second most important requirement etc (i.e. the same way you do a product backlog when using Scrum). Why? Because when you use for example groups of priority 1, 2 and 3 that many companies do, you often end-up not thinking the requirement through 100% and you do not get the right grouping in your incremental development when it starts. When the above is done you should now have a product backlog and the requirement part of the pre-study for the product should be ready for the next step: The detailed design and analysis phase.

Kind regards
Anders