I am not an animal...I am a man...ager!

I have been pretty excited lately about the synergy of ideas in the diverse books that I have been reading. I have enjoyed discovering the synergy between Peter Senge’s systemic thinking (The Fifth Discipline) and Eli Goldratt’s global optimization in his Theory of Constraints. And the parallels in Agile’s ‘People over Process’ with the concepts of Servant Leadership from the Greenleaf Institute lets me know that being an Agile PM at ThoughtWorks is a great place to be.

Now Andrew, I hope that you have noticed that there seems to be a common theme emerging from my postings - integrity in project management. So you can imagine how blown away I was this morning as I saw the synergy of ideas related to integrity that I found while reading on the train to work:

“Dee Hock has a unique perspective on the responsibilities of a manager. The first is to manage self, which he defines as “One’s own integrity, character, ethics, knowledge, wisdom, temperament, words, and acts.””
Jim Highsmith, Agile Project Management p. 207

“If I speak in the tongues of men and angels, but have not love, I am only a resounding gong or a clanging cymbal. If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. If I give all I possess to the poor and surrender my body to the flames, but have not love, I gain nothing. Love is patient, love is kind. It does not envy, it does not boast, it is not proud. It is not rude, it is not self-seeking, it is not easily angered. It keeps no record of wrongs. Love does not delight in evil but rejoices with the truth. It always protects, always trusts, always hopes, always perseveres. Love never fails.”
I Corinthians Chapter 13

The synergy of Agile project management with my personal belief system is very cool. But please note that I am not saying that you have to subscribe to my personal belief system (Christianity) to be an effective Agile project manager. I work with a lot of wonderful people at ThoughtWorks whose belief system is very different than mine. But I would challenge anyone to make sure that there is synergy and consistency between their personal belief system and their approach to their work. If there isn’t, then either their work is not worth doing or their belief system falls short.

(OK – so the title for this posting has very little to do with the content. The title is one of my favorite quotes of all time, from the movie Elephant Man. So I extended it a little to try to get it to fit into the theme of this blog. Yeah, I know - big stretch.)

90% of the beer on the wall, 90% of the beer...

Andrew - you wouldn't think it but software development is a very emotional occupation. Just watch people reading Dilbert. They either laugh uncontrollably or get really angry because Scott Adams has beatifully portrayed the madness of my industry.

Nothing can get much more emotional in my business than the 90% status report. I have been on both sides of the 90% complete status. As a developer I was frustrated in having to give that status for a second and even third time in a row to a manager that I knew wouldn't understand why my status didn't change. Or I was embarrassed that I was so naive to believe that last week I thought I was 90% complete, and that there were so many things that I should have considered in my original estimates but didn't. Or worse, I was angered that my manager so easily forgot that the scope of my task had increased but I was not allowed to re-estimate the effort.

And I have been a PM that has had developers that have repeatedly given a 90% complete status for the same line item in my beautiful project plan. I felt completely un-empowered as the PM. I could not report status on my project with any confidence. I also felt a lack of integrity in passing on that status, rolled up into the overall project status along with all the other developer guesses, to my managers.

It was bad enough that I was ready to quit this business a few years ago and go back to teaching. But then I was introduced to Agile software development and in particular Extreme Programming. One of the most glorious things about Extreme Programming is the practice of breaking tasks down in size to stories that should be accomplished in a couple of days. So when status is reported on a story, it is either done or not done. Nothing in between is ever tracked or reported. No more 90% complete. Welcome back integrity.

Don't Let Your Strengths Become a Weakness

Good morning Andrew. I just got done reading a posting on ravi mohen's blog about his ideas for a criteria that can be used in judging project managers. One of the points that he makes is that each of the really good project managers he has known have had great skills in other areas besides project management. He gives examples of great athletes, musicians and writers that are also effective project managers. It made me think that if I am a good PM, what might be something else that I am good at that could translate into being a good project manager? Well, the first thing that came to my mind is that I have been (and still are) a successful teacher and coach.

Let me give you a little more background about my teaching and coaching. Last weekend your mom and I moved some furniture around. In moving the hope chest down into the guest room I came across an old trophy I have been holding on to. It is the team trophy for winning a high school midwest regional basketball tournament that qualified our team for a national tournament. I was the coach for the team. This trophy is very special to me because it reminds me of a great bunch of kids that I had the chance to work with. But this is not the trophy that I am most proud of. In that same tounament the team also won the sportsmanship award. We were winners and we were disciplined.

So, going back to the theme of this posting, what could be the weakness in my strength of being a good teacher and coach? If I am hired to be a teacher and coach there really isn't an issue with it. But as a PM there could be. Here's how: being a teacher, I believe that I can teach anybody anything (given enough time) and being a coach, I believe that I can motivate anyone to do great things. (I can't seem to motivate you to clean your room, though.) But, you might ask, isn't it my job as a PM to build a team, and to teach and motivate? Yes, it is part of my job but it is not The Goal. My goal as a teacher is to build character and instill wisdom and knowledge. My goal as a PM is to deliver projects.

My abilities as a teach and coach are effective tools in my PM toolbox but they can also get in the way of delivering projects. The problem is that I sometimes continue to try to teach or motivate an under performing team member longer than I should. This can become detrimental to the morale of the team and detrimental to the delivery of the project. In the past I have had to let developers go and intuitively I know that I have done what was best for the team and the project. But each time I am left with a sense of personal failure.

The point that I am trying to make here is that if I continue to play to my strengths of teaching and coaching it can become a weakness as a PM. I constantly need to remind myself to stay focused on the goal of delivering business value by delivering working software into production.

One last point I want to make for you, Andrew: In this posting I am talking about strengths of abilities, not strength of character. Strength of character will never be a weakness in anything that is worth doing well.

Some men are born to accountability...some have accountability thrust upon them

As a project manager, managing accountability is a cornerstone of my work. Because I am paid to assure that things get done there is an expectation that I will get things done. So, as the PM on projects, it becomes my responsibility to pass this expectation on to the developers, the people who actually get the work done.

In becoming an effective project manager of software development teams, I have learned that there are two sides to accountability. One side is empowering, the other is paralyzing. Knowing the difference between these two sides will help you effectively manage accountability and can ultimately affect the success or failure of your projects.

Tell me if you can see the difference in the following two statements regarding accountability:
- I will hold the development team accountable for getting thing done
- The development team takes accountability for getting things done

In each of the two statements above, where does the accountability originate? With the first, the accountibility is externally imposed on the team. With the second, it is internally imposed by the team on itself. Is this a significant difference? Let's look a little deeper into each.

Holding the Team Accountable
Often, holding a team accountable is not about assuring things get done but is about having someone to blame if things don't go well. This is the blame game and this is how it is often played out in project management:

1. Business envisions a project
   
2. Management estimates costs and dates for the project
   
3. Development team is given the project to complete without opportunity for input into the project estimates
   
4. Project scope creeps
   
5. Project delivery date slips
6. Management finds someone to blame, most likely the development team (they were the last ones doing anything on the project so they are fresh on people's minds)
   
7. Management puts the Big Bad Methodology in place on next project to hold people accountable
8. Management starts to measure project progress against the Big Bad Methodology
   
9. People start to focus their efforts only on their tasks in the methodology so they won't get blamed
10. The process becomes locally optimized and not globally optimized*
11. The delivery of projects gets worse
12. Good developers leave the company because they are being micro-managed
    
13. The remaining average and below average developers require micro-management
    
14. Management gets more serious about the Big Bad Methodology because it provides a way to get average and below average developers to accomplish something
    
15. Project delivery slows to a crawl (but nobody is getting blamed! They are all doing their part in the Big Bad Methodology.)
16. The organization cannot hire great developers to increase productivity because great developers don't want to be a part of a micro managed organization
    

*Here is an example of why local optimization is bad: in the Big Bad Methodology someone is responsible for gathering requirements. When they finish putting together their Big Bad Requirements document, they say "Whew! Thank goodness that is over with. I'm not gonna get blamed if this project is successfully!" as they throw the requirements document over the cubicle wall to the developers. But is the document sufficient to code against? Documents never are no matter how much time you spend on them. The requirements gatherers have finished their part of the methodology and are long gone to the next project and are not around to support the developers in getting working code into production. Therefore, the coding effort takes longer and is often missing the intent of the project vision because of poorly communicated/understood requirements. (See Theory of Constraints by Eli Goldratt or The Fifth Discipline by Peter Senge for discussions on Global Optimization.)

The Team Holds Itself Accountable
Being accountable should mean that you take responsibility for getting something done. You don't worry about blame but rather are committed to adding value to the organization. You are empowered and trusted to deliver.

So how to build a team that will take accountability? Here are some things to keep in mind as you build an accountability taking team:

• Hire great developers that are passionate about delivering value to an organization and not just passionate about writing cool algorithms
• Empower the team to self organize (see Artful Making: What Managers Need to Know About How Artists Work by Robert Austin)
• Empower the team to estimate projects (how can you possibly expect developers to commit to estimates if they had no part in deriving them)
• Make sure the team sees the vision of what is trying to be accomplished by the project
• Think globally, not locally, even within the development team's processes
• As a manager, be a Servant-Leader (see The Serving Leader: Five Powerful Actions the Will Transform Your Team, Your Business, and Your Community by Ken Jennings)
• Be adaptive - don't be rigid in establishing methodologies (see Agile Project Management: Creating Innovative Products by Jim Highsmith)
• Have a plan but be will to adapt as you learn
  

Tom on "Joel on Software" - BUFD Part 2: The Rest of the Story

It really pays to ask questions, to discuss ideas, to put yourself out-there. Learning starts to accelerate when you begin to articulate your thoughts and feel free to ask questions.

Case in point: in sharing this blog with Rob, a friend and colleague at work, he read my earlier posting on "Joel on Software" and he was able to answer a couple of the questions that I had posed to Joel. Of most interest, Rob was able to answer the question I have for Joel's project: Are your requirements stable? The answer was suprising (but if I had done a little more research I would have found the answer myself).

As it turns out, Joel is not only the architect for the system but he is also the customer! That means he is responsible for defining his own requirements. Well his requirements had better be stable then! Can you imagine how embarassing it would be for the customer and architect of the system to change requirements in the middle of development and have to do rework because of something he forgot or didn't consider?

So now that we understand the context of his argument a little better, let's ask Joel some more questions. If you had to work with a user/customer that was not able to articulate their requirements as well as he can, would you be able to do BUFD even if he wanted to? How many times have we as system developers worked with customers that, when we give them a demo of some working software, they essentially say "I don't know what I want but that is not it"?

Software requirements on most projects change, either because the user begins to understand the problem better as working software is delivered or the needs of the business changes during the project. At the heart of Agile is creating an environment where the project team can embrace change.

So I may agree with Joel that BUFD is appropriate for his project. I said I may agree - I still have a few more questions that I would ask of him. For example, what is the experience of his development team with the technology being used? Is there a need to do some exploritory / deep slice prototypes early in development that would give insight as to how the system architecture should evolve?

I am disappointed that Joel uses his project as support for his argument against Agile and for BUFD. His project is not representative of projects that should consider Agile. Let's focus the debate on this question: Would you prefer to use BUFD or Agile on a project where the requirements are likely to change late in the project?