Create teams that avoids the five dysfunctions

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?

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

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

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