Product Development

On hold...

2010-06-07T21:49:00.000+02:00

Dear readers,

When I started this blog one of the goals was to get feedback and a rewarding dialogue that would help me and others to develop in this field. Unfortunately the amount on monologue from my side has been much greater than the dialogue. Therefore I have decided to put this blog on hold for now.
Kind regards

Anders

Be flexible on product scope. Not time and quality!

2010-05-11T21:09:00.000+02:00

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

Create teams that avoids the five dysfunctions

2010-04-23T19:06:00.011+02:00

Dear reader,

When I was twenty years old I was still quite naive when it comes to leadership. Then I did my military service as reconnaissance squad leader. Before the recruits started, the squad leaders were trained in leadership. I learnt both the theory around FIRO and about formal/informal leadership. I also had the “pleasure” to practice this leadership training the following 9 months with the recruits that joined my squad. For example we had survival training where we all were pushed to our limits with no food or sleep. This changed me as a person and I discovered many new things about myself and about other people. So why I am writing about this? Because this was probably my biggest paradigm shift in life when it came to understand interpersonal communication or actually even see that it existed. In this post I am going to explain how to generate a paradigm shift for the people in your group to be able to avoid the five dysfunctions and to be able to create a very effective team that everyone enjoys working in.
Below I will explain hands-on how I use the theory from Patrick Lencioni´s book: “The Five Dysfunctions of a Team” and how to avoid them as much as possible.

Just to repeat from the book these are the Five Dysfunctions:

Absence of Trust,
Fear of Conflict
Lack of Commitment
Avoidance of Accountability, and
Inattention to Results.

1: To be able to feel “real” trust you need to know the people you work with a bit more than just from work. Therefore start of with a two day kick-off for the team (usually people know each other from work but not so much outside work, hence the social part of the kick off is very important). The first day, use a normal kick-off setup with a lot of different exercises. For example; people should tell everybody about themselves (both work related and private things), as well as some team building activities in the afternoon and evening.

On the second day focus on group psychology, for example the theory from 1958 created by Will Schutz during the Korea war: Fundamental Interpersonal Relations Orientation (FIRO). (Read more about FIRO here). Also explain and talk about the theory around the five dysfunctions. Let the group do group exercises about the two subjects. This will give the team the fundamentals to avoid the dysfunctions, because they will have a common language to start understanding the main issues (i.e. you will get the group communicating with each other about these things). But do not forget that FIRO also tells you that there is a lot of work to get to the “openness phase”. Therefore you can not rush it, but you can give the team the tools to get there (which is a giant step to take and a great step for the team if they can get there, many teams never do) and most of the time you will help the team to get there even quicker than normal.

2: After the kick-off give them each a copy of the book (no I am not sponsored by Patrick Lencioni :-). Also in some cases you have people in the group that might not want to take part in this, some developers might not want to speak in bigger groups or share with the team. Therefore I also recommend you to give everyone a copy of the book “The 7 habits of highly effective people” by Stephen R. Covey. This might/ or will get these few people onboard as well since they might need a bigger paradigm shift to be able to be part of this change. Nonetheless your team will learn a lot form this book.

3: Keep on talking about these issues and talk about how important it is to have a good communication in the group. Since this might be a big change for some people, you need to repeat the message as often you can without sounding like their mother :-). In the long run you will see results and get team members that will enjoy working in your team/group, hence delivering more and producing better results.

4: Use processes and methods that support this way of working. For example “Scrum” that among other things increase communication with daily meetings and/or XP that creates interaction and understanding between team members.

Sounds simple? No it is not, it requires that your leadership is more a servant type of leadership and that you yourself lead by example. I believe that servant leadership will give you better results in the long run, however the world is not black and white, therefore you also have to be able to use other leadership styles if necessary (more on the servant leadership style in another blog post later).

Yet another long post, so I will save the: “be flexible on the product scope. Not time and quality” for a coming post.

Thank you for reading and please give some feedback!

Best regards
Anders

How to reach deadlines?

2010-04-13T19:31:00.006+02:00

Dear reader,

“I love deadlines. I like the whooshing sound they make as they fly by” (Douglas Adams English humorist & science fiction novelist 1952 - 2001).

I like this quote because it is a bit therapeutic for someone that always chase deadlines and also because it is totally the opposite of my personality, since I hate missing a deadline. However a lot of statistics show the gruesome fact that SW projects most of the time do not get delivered on time and within budget.
Even projects with unlimited founding and the best people fail as an anonymous person commented on the blog on my post form 22nd of February this year: “It is interesting to read the the GAO reports from DoD (www.gao.gov/products/GAO-09-326SP) which goes through of the 50 major weapons programs in USA which has (almost) unlimited founding, the best people and still fail. Many of the reasons identified for these failures apply in smaller scale as well - failure to understand complexity, mistaking new technologies for proven and shear optimism that "it will probably be worked out" without any contingency if the expected miracle does not happen”.

So what should you do to reach deadlines? First of all, imo I think that if you can deliver on time with the right quality and with a maximum overdraft of 10 % over budget you are doing very well for a SW project. Secondly to be able to repeat (only once does not count) your success, you need to have processes, people with the right technical knowledge and tools etc that paves the way for the projects. But setting this a side there are a lot of things that is less tangible and more based on the soft side and they are often even more important. These soft things are what I am going to write about today.

Below you can see my top three things:

Never give up, but face the brutal facts as early as possible
Create a team that avoids the "Five Dysfunctions"
Be flexible on the product scope, not time and quality

Never give up, but face the brutal facts as early as possible:
I have been working as a project manager for many years and a too common thing you hear from project members or sub-project managers are we have failed to deliver this or that and we need to move the deadline since we do not see the possibility to get ready on time. Unfortunately it is also all too common that you get this feedback very late. Many project managers then accepts the situation without looking at all options and gives up the target deadline and starts working hard on new plans and suggesting a new deadline to management or the steering committee. If you have a good project team you should instead sit down with them and look at all your possible options before you “give up”. Be as creative and innovative as you can, you might have to delay this particular activity, but you can almost always find other solutions that speed things up on other parts of the critical chain. If it is really tight you often have to increase the risk level, but that is okay if you can stay on the target (please note: just adding developers seldom has an effect). Imo too many people too easily accept delays, I think this mostly is a mindset issue or maybe they like the whooshing sound :-). By mindset I mean that somehow they have got use to that delays are okay and as long as I can make a new plan everything is fine. If you instead do not accept the delay and try your utmost to find an alternative route most times you will. If you on top of this have a team that avoids the five dysfunctions, hence faces the brutal facts as early as possible instead of waiting to tell you about the problems until it might be too late, you will have even more options to reach the deadline in time. In the very good book: Good to Great you can read more about “Face the brutal fact” (Jim Collins is the author of the book: Good to Great, Built to Last, and How the Mighty Fall).

This post is already too long. I will save the two other parts: "Create a team that avoids the five dysfunctions" and "be flexible on the product scope, not time and quality" for my next blog post.

As a final note, of course there are cases when you have to delay a project, all I am saying is that do not be to quick to accept delay. Because if you are you will create a culture in your department that might think it is okay with the whooshing sound or even start liking it ;-)

Thank you for reading and please give some feedback?

Anders

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

2010-04-12T21:09:00.002+02:00

Dear reader,

Quality factor correctness is maybe the most common measure for SW quality, and it might be kicking in open doors writing about them? However as Henrik quite correctly pointed out in his comment on my first post about Product SW quality, “correctness is measured at a specific point in time”. This fact makes these quality metrics less trustworthy the more changes you make to the code without performing the right regression testing. Therefore I use them for making release decisions on the maturity of the product together with the other quality factors at a specific point in time. Normally it should be measured against a preset targets for beta SW or final SW. Only looking at one or two of the quality factors correctness can give you a false sense of good quality. For example: You might have low number of open defects and a good pass rate. Without knowing the test converge and the S-curve you will still be in the dark.

Here are some details that I think of when using the correctness quality metrics.

Open defects rank of A, B and C :
This metric is very straight forward, nevertheless the truly hard part is to set the targets that is right for your product. It can be very different for a mobile game compared to a heart-lung machine. The only way I have found that works so far is actually to learn the right limit as you go ahead (maybe not the best way if you do heart-lung machines :-) and releases your product and get customer feedback (if possible before market launch using beta testers). I.e. is zero A-ranks something your customers expect or is 10 A-rank okay? If you have any better way of doing the target setting please let me know? Also what is important is that you use a good ranking system and that everyone gets trained and good at using the ranking system when reporting defects. In addition to this it is very important that everyone buy-in on always adding all defect that is found to your defect tracking system to get traceability. Without 99,9% buy-in form the organization you are in trouble.

% pass rate for test cases:
This metric is also quite straight forward. You just measure the passed test case divided by the total amount of available test cases. This should be measure for at least unit tests, integration testing and system testing.

% test coverage:
Again this metric is not rocket science .You measure % test converge of all the available test cases you have, to validate that the % pass rate tells you the true story. This should be done for all test cases. The targets in an optimal world is of course 100% if you have no blocked areas. For for example unit test it is also good to try to accomplish as close to 100% code converge as possible for the metric to be even better.

Performance metrics:
It is of great help for the development organization to receive targets for none functional requirements like performance metrics from product management in the product specification, before the development starts. Then it is much easier to spend time on estimating the needed work to archive the targets. One example could be the start up time for the product. Without targets you often end-up arguing before launch what is good or bad. If product management do a good job they benchmark with competitors or set good metric targets based on customer expectations.

Thank you for reading and please give some feedback?

Anders

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

2010-04-02T10:18:00.006+02:00

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

Product SW quality (part 1)

2010-03-28T16:44:00.006+02:00

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!

2010-03-10T17:35:00.005+01:00

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!

2010-03-08T19:35:00.007+01:00

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!

2010-03-06T13:47:00.006+01:00

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!

2010-03-04T18:12:00.004+01:00

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.

The before execution phase

The execution phase

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!

2010-03-03T19:15:00.005+01:00

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:

An overall business process (with business tollgates)

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

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.

To start a pre-study/design phase

To start execution

Release of the products to customers

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?

2010-03-01T11:46:00.004+01:00

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:

These are all must have (i.e. without these there is no product)
These are the requirement that will give your product an edge, but you could live without them if you must
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

So what issues do I typically find?

2010-02-22T10:19:00.003+01:00

Dear reader,

It is not difficult to find challenges to work with in most companies, often you think that it is quite normal in small start-up, however even multinational companies can get you flabbergasted looking into the truth below the nice development process charts.

In my opinion the number one issues is always requirements. How do you make sure you have the right requirements or even have them written down somewhere? How do you impose change control of you requirements? How do you priorities requirements? How do you get the right input for the requirements from all important stake holders? I will write a lot about these issues in my coming posts. However, just to give you a preview, here are some of the issues I typically find:

Requirements in all forms...

Lack of quality control and good quality code measures (software Metrics)

Lack of quality control and good quality code measures (software Metrics)

Lack of 100% working development process or even no process

Bad architecture

Poor understanding of project management, project estimation and software complexity

Lack of good steering for all development projects i.e. no steering committee on the right level of the company, or only obligations and not the right authority for people who drive projects

Lack of commitment due to poor understanding of people management skills

Lack of drive and commitment due to poorly connected company goals with individual goals

Political games

Line and projects not clearly separated

Poor visibility or transparency on the status on ongoing development projects

Lack of good customer support and handling sw bugs

This I s just the short list :-). However if you solve many of the above issues you are on your way to a much better future.
But remember in the end it does NOT help you if you can write fancy process or buy nice tools. The number one thing is to get everyone in you team onboard and actually implement and work according to the new ways of working and that is the most difficult task to achieve IMO.

Over and out for this time…

Step 1. Find out what is actually wrong!

2010-02-21T23:17:00.004+01:00

Dear Reader,

If you are new or have had the CTO/VP engineering position for 10 years, it does not matter. You must start from square one. Of course it might be a bit easier if you are new at the job to do this, but do not fall into the trap that you know your organization, especially if you been on the job for sometime. You must get out from you room and start talking to all people in you organization. Start with your own organization and next inline is the organization who orders the products from development (for example product management or product planning). If you have product management or product planning in your organization, you have already found one problem right here :-), more about this in future posts (link).
Why talk to your people yourself? (NOTE: Do not fall into the trap getting a management consultant doing the job for you). Talking to your people yourself will give you at least three things.

You will hear and understand the feedback first hand (hence no whispering game, i.e. loss of data) and you can ask follow-up questions directly to fully understand what he/she says.

All employees want to be seen even more so if they have been seen by the boss or bosses boss etc. Even better if they also feel they have been heard. Do not underestimate the power of this…

And most importantly in 99% of the cases, they do not only know what is wrong, they will also know how to fix the problems in most cases

Do not fall into the trap of to many questions. Two simple questions is usually enough (you should of course not forget the “social part” of the meeting as well).

What things can we improve?

How would you go about to solve these issues?

If you do this simple first step you will have plenty to work with for the coming years…I once meet a manager that did this with more than 150 employees, he was a true inspiration and a fantastic leader.

Next post I will talk about what to do with the stuff you find…

Kind regards
Anders

Why?

2010-02-21T22:26:00.000+01:00

Dear Reader,

You should always ask yourself why you do something? In my case it is simple. I have worked for many different companies big and small over the last 15 years and I have yet to see any company that uses its full potential. On the contrary many times I have been surprised how badly they have been run. I now feel I have found at least parts of the holy grail of software development and I want to share my findings and also get feedback from others in the same situation. There is of course not ONE solution for all companies. But I will show you in this blog a structured way of finding your challenges and most of the solutions/answers to them both soft and hard.

All feedback are welcome!

Happy Reading

Anders Storm