Can We Do Better?

On several of the Scrum & Agile boards that I frequent and regularly post, there has been some pretty lengthy discussion about team optimization and how organizationally, we can be certain we are pushing at our maximum level of efficiency.

I had a recent encounter with someone who provided this scenario: “Within our organization, we manage large scale projects. I have multiple teams that each contain offshore resources. I have a clear understanding that agile practices and principles teach that the team should be recognized as a whole for work they complete or do not complete. Where I am beginning to struggle is that upper management feels this team could be doing more with their time. I have now been tasked with finding those individuals who are not pulling their weight on the team and helping them make needed adjustments. How do I begin capturing individual metrics without disrupting the overall team productivity which is for the most part very good?”

Before I even attempted to tackle this scenario, I thought back on all of the books I have read, classes I have attended, conference sessions I have hosted or attended, and none of the book knowledge out there could adequately address this issue. This is not to say there are not hundreds of publications that have addressed a similar topic. I truly believe that each team is different as is the team composition. The only practical solution was to give advice based on real-world scenarios I have seen in the past. It was time for me to play the role of doctor.

I remember early on in my relationship with scrum I had a conversation with one of the thought leaders and the counsel I received went something like this. Being a good scrum master or project manager is a lot like being a doctor. When the team comes in and says they do not feel good, it becomes your responsibility to ask the right questions and make a diagnosis. Just because someone has a bad cough, it does not mean the have full blown pneumonia. Most of all remember, just like every person is different when it comes to health related issues, so is every team! Each may have a pre-disposition to cause us to think that the ailment could stem from a certain root cause, but it is not fair to assess one against another as their composition and surroundings could be very different.

This could have been the best advice I have ever received as a scrum master, agile coach, or mentor. Now all I needed to do was provide an eloquent answer that combined my real-world solutions with this nugget of pure knowledge.

With this, I turned to the individual account above and offered the following advice. It is the responsibility of a good scrum master, project manager, or team leader to effectively use the daily meetings, team burndowns, and in rare cases individual burndowns to give clear visibility into the team’s progress over the course of an iteration. It is the team’s responsibility to take ownership of their work and be accountable for what they commit to. It is each person on the team’s responsibility to take the agile oath and ask them self, “Can We Do Better?”. The answer will come and the team will feel gratification when they feel they have provided a voice and their voice was heard.

The key to increasing the success and efficiency of any team is contained in three short meetings:

  1. Have a 15 minute daily meeting with each team. This serves as a great pulse check and makes teams feel accountable for their daily activities.
  2. Hold a demo at he end of each iteration. Allow the team to take pride in what they have created and give them the forum to showcase their work. This instills teamwork, increased collaboration, and team empowerment.
  3. Conduct a meaningful retrospective at the end of each iteration. This meeting should be short and be a recap of the team health. This in essence is the equivalent of a yearly well health exam at the doctor. In an agile environment we do it more frequently.

Now that I have provided each of you with the tools you need to get the team on track and motivated, stop reading and go get some work done.

This entry was posted in Agile Project Management, Agile Teams, Distributed Agile, Scrum Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>