Month: February 2010

Trust…

Forcing impossible deadlines, ordering people to be at work during certain hours, denying leave, bringing in consultants and hinting at using them as a yardstick for productivity… I often wonder what makes people resort to these tactics and if they know the net effect of them? Decreased morale, lowered productivity, lack of any desire to do anything, “stick it to the manager” mentality, tiredness, increased stress, fear of job loss…I can go on but you get the point.

What brings this on? Not entirely sure but I can speculate…people react differently to varying degrees of stress and who can say what goes through someones mind when faced with pressure from above from someone who does not fully understand the given situation and lacks (or has incorrect) facts. I would say though, having worked with various managers under varying degrees of stress, that this is indeed the role of middle management, to absorb, explain, clarify and defend the team in which they trust, assuming the trust relationship is there.

Trust, that’s perhaps the key factor here and I think the core of where these decisions come from. Trust is the difference between saying “all leave has been denied until project X is done” and “as a team you guys decide whether you can absorb the impact of this leave but whatever you decide, I will back you”. Trust is not telling your team “you will be at work between the following hours…” but rather saying “there’s an incorrect perception linking the current level of productivity to peoples hours of work, how would you guys think we should approach correcting this perception?”.

Patrick Lencioni, in his book “Overcoming the Five Dysfunctions of a Team”, lists Trust as the foundation of any good team:

“…members of great teams trust one another on a fundamental, emotional level, and they are comfortable being vulnerable with each other about their weaknesses, mistakes, fears and behaviors…”

“Team”, in this case, includes everyone trying to achieve a given goal…everyone. Often I see management reeling under the pressure from above and, instead of approaching their team, bringing them into their “world of pain” and trying to collaboratively find a solution, they will resort to giving orders and clamping down. Inevitably though, the harder they squeeze, the more they lose control, forcing them to squeeze harder…a vicious circle from where the only thing that results is broken trust, something that’s almost impossible to fix.

Change is good

I’m often amazed at the number of dogmatic “prophets” out there when it comes to the latest fad’s of agile development. I myself am about getting productive and like to take the best of ALL worlds; change is not only inevitable but necessary, even changing of a process BUT, only if the change leads to improvement! I believe a process of continual introspection and change by a team, combined with a good way of measuring the effect of that change,  is essential for good team performance.

That in mind we made the following changes to the way we practice scrum:

  1. We added a default story to cover recovering technical debt (or refactoring if you will) in that story. Essentially we assign a “story point cap” to this story (say 5 points) that’s based on our current velocity and duration of sprint. We then assign “technical debt recovery” tasks to this story until the team feels there are enough tasks to fill the story points. I know, sounds like the wagon pushing the horse but it’s something we’re trying that other teams have used effectively.
  2. We’ve started estimating (wait for it…) HOURS on tasks. Stories are still broken into story points but the tasks are estimated in “hour blocks” (2, 4, 8, 16) as they are put up. The purpose of this is to act as a type of “sanity check” for story point estimation. An added benefit I found was that the team members seemed to think a lot more about a task when they had to assign time to it.
  3. We’ve started using a round table instead of the tradition square meeting tables. I found this very effective in encouraging participation and collaboration.
  4. Story point estimation was done using a technique I learned on training that speeds up the estimation incredibly (works well with lots of stories). This is how it works (well, how we did it anyway):
    1. All the stories are explained to the team and placed in a pile on the table.
    2. A wall/board is divided into sections, each representing a story amount (we used 1, 3, 5, 8, 13, 20, 40, 100).
    3. Each team member takes a pile of cards and sticks them in the column(s) they believe it belongs, no-one talks or interacts other than with the product owner to understand the story further.
    4. If a team member disagrees with where a card is, he/she simply moves it to where he believes it SHOULD be.
    5. This carries on until all the tasks are done. Remember, the key is NO COMMUNICATION between team members during this process, this has the effect of forcing people to think about why someone made a decision to place something in a particular column, or why they’re moving it.
  5. We’ve started experimenting with TDD and Paired Programming, which seems to be going well.

One additional thing I’m toying with is moving to a more Kanban based board, the team has problems with taking on too much work and I think creating a way of limiting the pulling of work will work.

Finally on how to measure if these changes are effective, well, to be honest I’m not entirely sure. I think the best way is simply to see if the team becomes better at actually doing what they predict they can do while maintaining a sustainable pace and having fun; other than that I guess we wait and see…

I’d be interested to know what kind of changes you brought about in your team and the effect of them (both good and bad), let me know…