Search This Blog

Showing posts with label Leadership. Show all posts
Showing posts with label Leadership. Show all posts

Friday, 23 April 2010

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

Tuesday, 13 April 2010

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