A great team

For me agile is about many things but first and foremost it is about people and dynamics between people, you get the right recipe going and anything is possible. I work with what I think is a great team, but what makes them a great team? I’m not entirely sure but here are some of my ideas of traits of a great team (in no particular order):

  • There’s a good level of respect not only for each other as people, but in each other’s ability to do stuff.
  • They trust each other.
  • The team has built in redundancy so anyone can take time off at any time, no silo’d experts.
  • There’s lots of laughter and healthy tomfoolery, they know when to work, but they also know when to play (at work!).
  • They allow failure and learn from it,  focusing on the problem, not the person.
  • High levels of collaboration, both at work and at play. They help each other out constantly, no-one is ever “too busy” to help.
  • They’re cross functional, there’s a good mix of skills amongst the team, helping with redundancy.
  • Everyone feels they can talk openly about issues and problems.
  • There is no fear (of failure, of specific people), they take chances and enjoy challenges.
  • They self organize, there is no one leader, they all lead, they all follow.

There’s more I’m sure, but those are the ones I can think of right now. At the core of it I think people must feel like they belong, that they are respected for their skills and trusted with responsibility and above all treated like people, not resources.

Thoughts?

I’m not a child…

Dear Manager,

I am one of your developers, when you hired me you treated me with respect, you asked me about my skills and abilities and (I assume) hired me because of these. Please could you explain to me why, now, the respect is gone and I’m being treated like a mentally deficient child?

If you want me continue adding value please consider the following:

  1. I am not 6 years old, stop treating me like a child.
  2. Using fear, intimidation and sarcasm to control me does not work, the more you try the more I will resist. Try a little more collaboration and a little less intimidation…
  3. If you would like me to tell the truth, don’t force me to lie by shouting at me every time I tell you the truth.
  4. Stop rejecting reality and inserting your own version of it, this is a sign of insanity.
  5. If you force me into a corner, I will lie to get out (see point 3).
  6. If you want me to be responsible, give me ownership of the problem AND the solution and stop telling me what to do by when.
  7. Stop treating me like the “bad guy” and take responsibility for your bad management decisions.
  8. I’m not giving my opinion to irritate you, I’m giving it in an attempt to add value. After all, you hired me for my expertise, right?
  9. Respect that I am a person, not a robot or a number, and that I have a life outside of work.

regards,

A. Developer

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…

The chatty daily standup…

One of the “ceremonies” of Scrum (man that sounds so culty) is the “Daily Standup”, a daily planning meeting where teams realign and coordinate their efforts for the upcoming day. It’s a concise, no frills no fluff zero waste of time meeting that answers three questions: what have I done, what am I doing and what are my issues, and is generally over quite quickly…but what if it isn’t, what if it degenerates into a technical discussion about the implementation of widget-x or how the build script is not building something correctly or which framework to use to solve some problem…

I’ve found this to happen quite often and all too often I see people coming down on the team with statements like “cut the meeting off at 15 min” and “remind the team to stick to the 3 questions”… all good advice but you’re fixing the wrong problem. I believe this behavior to be an indicator of a dysfunction within the team itself. In a truly collaborative environment teams should be discussing and solving problems constantly and not just at certain points through the sprint (like the daily stand up). If they’re only collaborating around the daily stand up then something is wrong and the team has a dysfunction preventing constant collaboration…