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

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

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