Dysfunctional teams

I finally read "The five dysfunctions of a team" by Patrick Lencioni.   I took it to read on the airplane going to and from Vancouver, but it's such an easy reading book I now have to find something to read on the airplane on the way home.  Then again maybe that's a good opportunity to catch up on my sleep.  Linda Rising pointed out at the conference that true greatness requires sleep!  Ha!  If only it were that simple!

In his book Patrick has illustrated a five tier model for the dysfunctions of a team, and once you understand them you have a chance of starting to correct them.

The book is written as an account of how the new CEO of a company worked through the process of making the executive group a team (rather than a group of individuals).   In it's own way the process narrated in the book reminded me of stories I've heard from a friend regarding his experiences in the USAF basic training camp.   In basic training they work to break down the individuals, and they go through a very difficult time of realization.   This removes numerous barriers allowing the USAF to start building a strong team.  Although they do lose some people along the way, the result they are working to achieve is to build a world class team. This isn't too far off the story line for the book.

The model Patrick has built for us makes a lot of sense.   The way to read the triangle is from the bottom up, and here's my summary:

5) Absence of Trust - team work begins with trust, as without trust it is not possible for effective conflict to occur.   In otherwords, we have artificial harmony resulting from a fear of conflict.

4) Fear of Conflict - conflict can be a good thing if it's used as a means for reaching good decisions the whole team can buy into.  Conflict must be constructive, and be used as a tool to reach great decisions.   The root of this dysfunction is ... you do not have good/clear decisions you will have ambiguity leading to a lack of commitment.

3) Lack of Commitment - Commitment is a function of Clarity and buy-in.   You need to ensure everyone on the team is committed to decisions, even if they voted against it.  If you lack commitment from the team it is very difficult for them to call each other on commitments, and so you lack accountability:

2) Avoidance of Accountability - Accountability is the willingness to call a peer on their behaviours which can be damaging to the team. The dysfunction stems from an unwillingness to deal with the personal discomfort associated with having these conversations. In the absence of accountability team members are more likely to turn their focus to their personal needs leading to Inattention of results.

1) Inattention to results - This is where people are more interested in their personal status and ego than they are with the team results.  Truly great teams do not have a group of individuals concerned about their individual status, rather they have a group whose primary focus is on the end result at the team level.

I highly recommend reading this book!

New PMI Agile Certification -- Really?!?

If you haven't noticed yet PMI has released initial information regarding a new certification for the Agile project manager.    When I first saw the information released I was excited as I would likely go after this certification to add to my PMP and PgMP.   However, since that time I've had time to reflect and now I'm not certain. 

I have had my PMP since 2003 and PgMP since 2008.   I am still very happy with those accomplishments and believe it certainly cannot hurt in my professional life to have those designations behind my name.   However, the place I have become disillusioned is as I've watched PMI dilute the PMP designation to the point of it almost being irrelevant.  I have heard many stories (and have a few of my own) of people who are certainly unqualified and earn the PMP, and use it to try and put themselves on par with PMs who hold far more experience.   The PMP is not difficult to earn, and can be accomplished by studying the theory.   In my mind the PMP shows someone has written a test on the theory, but really doesn't mean the person can manage a project.

When the PgMP certification was released I decided to pursue it due to the rigour involved with the process.   It was brutal in comparison to the PMP, and as recently as late 2010 PMI was still auditing 100% of the apps (or at least the symptoms suggest that).   I place more on the PgMP as it will be far more difficult for an inexperienced person to obtain this certification.   However, due to the low exposure of the PgMP I find anytime I talk about it I also have to explain what it is, but don't mind as I worked VERY hard to earn this.

So now PMI releases the agile certifcation for project managers.  The initial announcement was accompanied by a preliminary skills test for those who were interested.   I think a posting on Twitter said it all "... were they drunk?".   The sample questions were so basic and hoky, it left me wondering if those who wrote these samples knew much beyond some simple references to Agile.   It was truly bizarre.  

The sample questions, the low requirements to apply for the certification, the low cost of the certification all leave me wondering what PMI is looking to accomplish with it.   I worry the certification will go the way of the PMP, where so many people have earned it, and it's so easy to earn that it will eventually become irrelevant.  

At this point you might be wondering if I'm going to go after the certification myself.   For those who know me, you know how passionate I am when it comes to the domains of Agile, Lean and Kanban.   The answer is "I don't know yet".   I'm not convinced it is worth the effort, or provides any return for me in my career at this point.   I would much rather invest the time sharing my thoughts, teaching my peers, or furthering my understanding in areas providing greater return.   I'll have to see what the 2012 brings and whether this is truly just a case of PMI jumping on the band wagon, or if they are truly trying to established a measure of the Agile PM (which if you truly understand Agile you'll know how difficult it would be to measure what an Agile PM is).

Please let me know your thoughts!   Do you agree with my point of view?   Do you have plans to write the certification exam?   Maybe you'll help me make up my mind one way or the other!

Agile and personal responsibility

I learned an important lesson long ago from my Cub leader (Scouts Canada):   “To do my best”.    In Scouting all of the promises start with “I promise to do my best…”.   In Cubs we even had an opening/closing ceremony which had us challenging each other to do our best!   It’s a constant theme in the program, and perhaps there are some lessons we can draw from it.

Much as in Scouting, the business world should always be challenging our people to do their personal best.   In the principles of Agile we can find numerous examples of this foundational behaviour.  

• Build Projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done
• Working software is the primary measure of progress
• Continuous attention to technical excellence and good design enhances agility
• The best architectures, requirements and designs emerge from self-organizing teams
• At regular intervals, the reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Self realization and people always striving for their personal best!   So how can you realize this lofty goal?   As a leader in our teams your job is to help people reach for this goal, and help them through the transformation.   I’ve always been impressed and amazed when I take the time to bring the best out of people how they rise to produce amazing results!

Inspiring people towards always achieving their personal best takes some time and patience to achieve..   You cannot mandate them to be amazing as it simply won’t happen.   It doesn’t work this way!     Dr. Peter Jensen has written about helping people realize their true potential, and talks about the importance of sparking personal greatness in his book “Igniting the third factor”.   As a coach of Olympic coaches (including the 2010 Gold Medal Canadian Women’s Hockey Team!), Dr. Peter Jensen talks about how achieving personal greatness can only be achieved if you have ignited them from the inside.   The book talks about how as leaders we should be using five things as tools for helping people find their inner greatness:

• Manage yourself
• Build Trust
• Encourage and use Imagery
• Uncover and work through blocks
• Embrace Adversity

 Another key tenant to personal greatness is the ability for people to take responsibility for what happens.   Christopher Avery teaches his classes about responsibility.  Not the type imposed by a process or organization, but the internal type which when captured causes people to produce great results!   

Christopher will tell us the basis for taking responsibility lays in the three keys of:

• Intent – awareness is useless, unless you intend to step up and fix it
• Awareness – you need to know what’s happening, and where you’re landing
• Confront – you have to face the reality of your actions

With the three keys to responsibility in place you can start to examine Christopher’s Responsibility Process.   The Responsibility Process is based in human nature, and no one is exempt from going through this process.  

When faced with issues and adversity humans land in one of four spaces:

• Obligation – you believe you are doing something as it is required of you
• Shame – you hang your head low in disgrace for the result you produced
• Justify – you use other factors to explain the result you produced
• Lay Blame – you point to others as the cause of your situation

Everyone goes to one of these spaces as it’s just human nature.   You might think smart people are exempt, but in reality they just have better stories.    The key to responsibility is what you do after you’ve landed in one of these spaces.    Let’s try an example:

A colleague of mine recently explained how unhappy he was in his current job.   He knows he’s doing a poor job, but he’s just so unhappy about his current role he isn’t paying attention to quality like he knows he should.    We discussed the current situation, as I was trying to help him find the root cause of the dissatisfaction.   In the end he just doesn’t like the work he’s doing any more.   So I asked him, why he doesn’t go find another job and get out of this situation.   His response was the money is so good.   At this time I pointed to the responsibility process and asked him where he was in the model.

For this friend he has two choices to make.  Either way he needs to move himself up to taking responsibility for his situation, which means he has to make a choice:

• Find a way to find satisfaction in his current role
• Go find a new role, and if the money isn’t as good accept that it’s easier to take responsibility in a better environment

There is nothing easy about helping people produce great results!   Models such as Christopher Avery's or Peter Jensen's can provide you with tools to help you accomplish such a lofty goal!  

Please let me know if you have other tools & models you work with in the area of personal greatness.   The human factor is a difficult one, and I'm always looking for new tools.  

Symmetrical organization structure

As I'm studying Agile in greater detail what becomes increasingly obvious is how important the team is to achieving truly great results.  In the past year I've changed my view on how a project team should be organized.

In the past my project teams were organized as a hierarchy.  I now like to think of this as the 'pyramid of power' that had me at the top of the IT part of the team, reporting directly to the project sponsor. It was great in my mind as it made me a very important and in demand.

The problem with this org structure is how disconnected some of the people at the bottom of the chart become with significant portions of the team.    I've been on many teams where only the core part of the project team meet on a regular basis, and would devise what needs to be done.  The definition of work to be performed is then passed along to the others in the hierarchy. 

In the past year my view of team structure has changed considerably.  The change I've made in the past year is really quite simple.   The primary change is to bring everyone up to the same level on the org chart:

There are many advantage to this type of organization some of which are:

1. Reduces hand-offs - did you ever play telephone as a kid?   You know the game where you pass a message from one person to another?   How much did the message change by the time it made it around the circle?  Now imagine if the message was just given directly to the whole circle?  Everyone would hear the correct message directly from the source.   The same idea applies to our teams, and we should be looking to reduce the number of hand-offs for information whenever possible.
2. Team can self organize - the Agile Principles tell us the best architectures, requirements and designs emerge from self-organizing teams.  The symmetrical team structure can certainly help enable a self organizing team as it creates an environment where everyone is working and collaborating together.   For me the organization structure is one of the keys to the team being able to self organize.
3. Find defects early - in a recent project my team found a significant defect early while still in development.  The best part was the fact the team found the defect while we were still in development, which meant it was very easy to correct.   This happened simply because the developer was talking to customer directly, which goes back to #1 above -- reduce the hand-offs!
4. Creates an environment of trust - the best way to earn trust is to extend trust.   Trust your team to do the job they're good at without you hanging over them at every step and you would be amazed what they can do!  
5. Reduces the need for extensive documentation - documents are necessary, but when teams don't collaborate effectively it means we have to create very thick documents to try and capture the complete set of information.   However, it is never possible to capture all information in a manner that it is accurately interpreted.   The best way to convey information is face to face, and that's exactly what a symmetrical team structure encourages.

It's amazing what will happen when you trust your team, and create an environment for them flourish.  It's not that difficult to make happen, so give it a try!

In my next blog I will talk about The Five Dysfunctions of a Team.   If you haven't read the book I highly suggest it.

Until then ... Be Agile!

Mike

Project Management on Agile Projects (part 3 of 3)

In my last two blog entries I shared the first four primary points I made during presentations in the past month.  This has been a great experience, and I've certainly enjoyed talking with so many people.   The effort has been worth while as it's opened up so many great opportunities to learn and expand on my view of software development in general.

In the first two blog entries I shared tips 1-4 for being an effective agile PM:

Tip #1 - Figure out what is truly valuable to your customer
Tip #2 - Stop imagining you can predict the future
Tip #3 - Stop thinking your customer can accurately tell you in detail what they want at the start of the project
Tip #4 - Don't just communicate ... collaborate!

Here's the last two from my presentation:

Tip #5 - Be lean!  (aka eliminate waste)

Last year I had the opportunity to attend a Mary Poppendieck workshop on Lean Software Development.   Lean is a concept coming out of the manufacturing sector, but applies to what we do in software development as well!   Mary defines waste in software development as:

Extra Features

• Unnecessary Documentation - Your customer cannot run their business with project documentation.   Documentation is a necessary tool for effectively managing projects, but unfortunately too many organizations have taken it too far.   Rather than creating more detailed documentation, look to replace it with collaboration.   Also examine the timing of documentation.   It's always cheaper to document something which exists, rather than documenting something which doesn't yet exist
• Extra Steps - look at your software development processes.   Are there extra steps inserted for the sake of process?   Break those down and create the most efficient process possible, with the fewest steps required to assure good quality products.
• Finding information - it is wasteful anytime someone needs to search for information.   If you find members of your core project team in particular are searching for information through the documentation, you should examine how effectively you're collaborating (or not).  
• Defects not caught in testing - any defect creates waste regardless of how soon you catch it.  The most effective way to deal with defects is to create an environment which doesn't allow them to be introduced in the first place.  For many of us this is a goal somewhere in our future, and until then we need to continue finding them less effectively.   However, do strive to eliminate them before they cross from one domain to another.  Is there a way your team can collaborate with the developer to find more defects in unit testing?
• Waiting - every day your customer waits for a new feature is wasteful.   So rather than forcing them to wait months for a complete set of new features, strive to deliver it incrementally throughout that period of time.   Your customer will be able to start using the new features incrementally and starting building value immediately.   The other significant benefit of this incremental approach is your customer will learn what they really need as a result of using the features. 
• Handoffs - this one is so obvious I wasn't paying attention!   Any time your team has to pass work from one person to another (especially when it's being passed outside the team), you create waste as the new person needs to come up to speed.    Work to bring as much of the knowledge required to build the product right into your team.   This can be difficult in many enterprise environments, but reduce the handoffs as much as possible.   In situations where your team must do a hand-off, don't let the team lose sight of the fact they still own the project work so they need to take the initative to stay in touch with the person it was handed off to.

I could write a lot on this topic.   However, I'd highly recommend you pickup Mary's books and go through them. 



Tip #6 - Learn & Improve!

For me this is one of the most important concepts of being an effective Agile Leader.   You need to help your team learn continuously and apply those learnings in their work immediately as they move forward with their work.  An effective means to do this is to host regular retrospectives.  My preference is to host them at the end of each week, before they have a mental break (ie. the week-end) and they forget everything they learned.

One technique for doing this is the perfection game.   I’ve adapted this from a vendor I work with, but ultimately it came from Jim McCarthy.   The concept is very simple.   On the whiteboard draw three columns with the labels “What worked great this week”, “Score”, and “What would have made this week perfect”.  Each and every team member is required to attend and participate in this activity.   I usually start as often people have a fear of being first (over time you may find your team changes this).   In the first column I write 2-3 things which I thought were great in the past week.   Keep it brief and clear, and avoid the temptation to tell big stories.   In the second column write a score from 1-10 (whole numbers only) where 10 is perfect, and 1 is at the level you couldn’t imagine it being worse.   This is a very subjective measure of mood so do not try to over analyze it.   Finally in the third column – if you did not score a 10, then you MUST provide suggestions for what would have made the week a 10 (ie. perfect).  

If you use the perfection game effectively a team of 8-10 people can get through this process in 15-20 mins.   Some tips to help with your success are:

• Do not allow debate to start – clarifying questions are acceptable, but that is all
• Do not track long-term trends on the scores – last week to this week is all that is relevant
• Do this as a stand-up meeting – it will keep the meeting moving and focused rather than letting people sit down

That concludes Mike’s top 6 tips for being an agile PM.   Unfortunately there are no silver bullets, only experience and great ideas to build on.   If you stop to view the work you do as a journey (not a destination) you will have a better chance of success!

In my next blog entry I will talk about my view of Symetrical teams!

Until then … be Agile!

Mike

Project Management on Agile projects (part 2 of 3)

In my last post I started to summarize my presentations over the past month.   Now that I'm a week later, I continue to be very happy about the results of my presentations.   I'm starting to hear feedback from the presentations and it appears at least some of the people in the rooms received value for the time spent.

In my last post I shared 2 of the 6 tips I provided to help PMs understand how they might be Agile.  They were:

#1 - figure out what is truly valuable to your customer
#2 - Stop imagining you can predict the future

In this posting I would like to share the next two points:

TIP #3 - Stop thinking your customer can accurately tell you in detail what they want at the start of the project

Have you ever found yourself in the position of having a 'solid' scope statement at the start of a project?   You've put a considerable effort into ensuring you clearly understand exactly what the customer wants, detailed in a document that has been signed off by the sponsor.   You've detailed scope in terms of what is in scope, out of scope and possibly what is unresolved at the time of writing.   Then as your project progresses you find yourself writing many change requests to alter the details of the scope.    Was your project a success?   I used to think so!   On very large programs I would have lots of change requests, and I prided myself that the customer wasn't suprised by the results.   However, I now wonder how much value we left on the floor as a result of having to cut scope so significantly in some cases.

Since I've adjusted towards to be more Agile my project experience is foreverr different! At the start of this year I led an Agile project in which my scope statement was very simple.   The scope statement merely said to add a business feature and supporting functionality.   It was a very vague statement, but turned out to be the best one I ever wrote.   We delivered what the business required and exceeded their expectations!

What you need to find is a way to manage the scope of your project.   I used a technique taken from a webinar put on by Allan Shalloway from Net Objectives:  Webinar.   Within the webinar you will find Allan talking about a technique for managing the scope using front burner, back burner, fridge and freezer.   We adapted it, but basically used this technique to put scope control into the hands of the customer.   The experience was great!

(note:  since my presentation I've had conversation with Allan Shalloway who says this is an old technique he no longer subscribes to as he's transitioned to the use of Lean-Kanban techniques.   That's OK though, as we're just starting our Agile journey so old techniques were probably an easier step for us.   Besides ... results speak for themselves!   I am now studying the Lean-Kanban thought process and am sure I will write about it at some time in the future)

TIP #4 - Don't just communicate ... collaborate!

Anyone can communicate!  All you have to do is send an email or document out to someone.  Collaborating is tough stuff as now you have to get people sharing information and ideas effectively.   This doesn't seem to be natural and takes a lot effort on the part of the leader and team to make it happen.

Think about how you organize your team.   The most effective organizational structure is a circle where everyone is on an equal level with clearly defined roles.   No intemediaries as that is wasteful and leaves things open to interpretation.  I will be writing a future post in the coming month with more on the topic of a symetrical team structure, but for now the important concept is everyone has the opportunity to collaborate with everyone else directly.
Host 15 min stand-up meetings each morning.   Please note 2 key things in the previous statement:  '15 min' and 'stand-up'.   This has turned out to be a very effective tool for keeping the team in sync each day.   During this quick meeting each member of the core team must share three things:   what they accomplished since the last meeting, what they plan to accomplish today and what barriers are in front of them.    Keep it on track and moving and you will find people dont' have a problem coming to the meeting each day.   If you'd like to read more about stand up meetings check out Martin Fowlers blog entry:  Its not just standing up

This is a big topic, but hopefully I've summarized a couple key points for you on tools for collaborating more effectively.   Don't just be a manager or boss!  Be their leader and inspire them to do the best job possible!   Make them believe they're the most important thing happening and watch how they'll rise to the challenge

Next week I will post the last two suggestions I have for being an effective agile PM. 

Until then ... be Agile!

Mike

Project Management on Agile Projects (part 1 of 3)

 Over the past three weeks I’ve been fortunate to be selected to speak at three different conferences.    Toronto Agile Tour 2010, PMI-CTT Symposium in Waterloo and this past week at the Agile Vancouver Conference.  My topic was basically the same at all three, but turned to suit   my audience.   The two Agile conferences heard the message of what benefit project management brings to Agile projects.    The PMI group heard me talk about extending their PM career by learning what it means to be agile, and then apply it to the ways in which they behave and conduct their business.

Rather than doing this as one big blog entry, I’m going to split this topic over three weeks.  It’s easier for me as I can spread the work out, but more important it’s easier for you to read something short in your busy life.

The following are Mike’s six tips to being an Agile Project Manager.   If you’re interested in the other message (what benefits project management brings to agile projects) please contact me and I will be happy to pass it along.

Tip #1 – Figure out what is truly valuable to your customer

A company once set out to build their customer a drill.   They started working on it, and before long they were having lively discussions with regards to the design of the drill.   They would debate colour, materials, chuck type, power source and many other details at great length.   It took months to deliver the new drill, and the team was very proud of their accomplishments!  So did this company deliver value?   Not really as all the customer really wanted was a hole!

What needs to be done first is to figure out what is valuable to your customer.   I’ve come across many IT people who believed their customer actually wanted to work with them.   This is a dangerous attitude, as it leads in the wrong direction.   The business comes to work each day wanting to make their business activities successful and they need tools to do this, which is where IT comes in.   IT makes a business out of enabling our customer's success.    With this notion in mind you need to seriously examine everything you do, and question the value it brings to your team’s ability to deliver value.    No one ever ran their business with your project schedule, requirements document, or project plan.

These artifacts do deliver the ability to enable effective delivery of value for your customer, which is why we continue to build and deliver them.   They’re important, but don’t lose sight of the fact they are not what the customer sees as providing long term value.

Tip #2 – Stop imaging you can predict the future

In the past I’ve prided myself in creating detailed schedules.   I took a year and focused on improving this skill, and I can now work MS Project in all kinds of ways (yes including leveling successfully).   About 5 years ago I had a work assignment in downtown Toronto.   I would ride the VIA train there 2-3 days per week, and during that time I primarily worked on my schedule.   It was a great schedule, with hundreds of the tasks clearly laid out and connected together in the perfect network structure.   With this schedule I thought I had perfect control of my project … WRONG!  I only had the illusion of having control, and the evidence of this is how much effort went into adjusting the schedule as it simply didn't reflect reality. 

Instead of creating detailed schedules, give your team some ownership on this front.   Find a better balance by providing them a framework from within which they can self organize and figure the details out themselves.

On a recent project I created a schedule out of flipchart paper, and post-it notes.   I created a giant grid with the far right of the grid representing our time box which we could not exceed.   We established further constraints inside the schedule, which could not be broken (e.g. No single person’s activity could go more than 2 weeks duration).   Every morning we would conduct a 15 minute stand-up meeting, and would use the schedule on the wall as our focal point.   At the start of the project I was secretly concerned about how on earth I was going to effectively control my project if I didn’t have a detailed schedule.   However, I have never felt so in control of my project as I did that time.

I’ll draw on the Agile Manifesto principles to explain why I believe this happened:

“Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.”  

Try it … it works!  

Next week:

Tip #3 - Stop thinking your customer can accurately tell you what they want in detail at the start of the project
Tip #4 - Don't just communicate ... collaborate!

Until then ... be agile!

Mike