I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile?

I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile?.

First break all the rules #Scrum Master

First break all the rules by Marcus Buckingham is one book which transformed me and thousands of managers worldwide into effective leaders ( servant leader)  by providing those 12 great questions, as a road map.. Introduction to the concepts of this research based book, which is written after interviewing more than 30,000 managers worldwide, gave me an actionable road map to transform my managerial style from autocratic to servant leadership.  I recommend this book to all managers, especially those who work as Scrum Masters, would be scrum masters. Movement from the traditional managerial  style of ‘leading from the front’ to the ‘leading from behind’ style that is required to be effective in self organizing teams, could be tricky and painful, till we understand the true spirit of servant leadership. That is where this book helps.  Life is easy, once you master the style which worked for great managers worldwide. Once you master that style, you can manage any good team in this world effectively and with much lesser effort. Get a copy for yourself as a reference book and try to score high on those 12 questions from your team. Once you start scoring between 3-5, see the difference you have made to the team and to yourself. Trust, this helps.

Application of ‘Theory U’ in agile transitions

Right now I am in the middle of a consulting assignment of transitioning a large team from ‘scrum but’ to right scrum. When I say right scrum, I refer to the scrum guide by Ken Schwaber and Jeff Sutherland which can be downloaded from http://www.scrum.org.

This team from a very large multi national product company came with the baggage of ‘I know scrum, and now you teach me scrum’ attitude, because they have been practising some sort of scrum. This attitude is not something new for me, as I have come across similar situations before as well.

Since agile is value based, like religions, a loss in faith is very difficult to be restored. No amount of talking would have convinced them. This is the biggest risk/challenge while dealing with teams with partial knowledge of s rum. At least that  is my judgment, based on my past experiences with teams with partial knowledge of scrum.

As a coincidence, this was the time I came across the theory ‘U’ which was advocating the postponement of the three fears of;

Fear of judgment
Fear of cynicism
Fear of change

for effective change management.

I decided to implement the concept of ‘postponement of these fears’ at every stakeholder level, me being the first one. All the coaching sessions started with the request to postpone these fears till the completion of the first sprint, and the results are very positive. After experiencing the right scrum, most of these fears are automatically addressed. So, make it explicit to postpone the fears of judgment, cynicism and change before implementing scrum..it will give you a smooth start.

Three questions to analyse the agility of the teams

Many claim that they have implemented agile, and very few have good implementations of agile. In order to understand the type of implementation one has, these three questions to help;

  • What is the velocity of the last sprint?
  • Do you have work allocation or work volunteering?
  • Can I see your sprint burn down chart?

What is the velocity of the last sprint?

Velocity is the productivity figure of the previous sprint, generally counted in story points. In order to calculate the story points, one need to have user stories, planning meeting and planning poker in place. In a sprint, the team is supposed to commit to the velocity (story points achieved in the previous sprint). The team may achieve slightly more, if their capability is better, and that becomes the basis for estimate for the next sprint. This is the continuous productivity improvement mechanism. If the team members do not know the velocity of the previous sprint, then I must say that it is a serious symptom of faking agility.

Do you have work allocation or work volunteering?

Agile teams are self organizing. The team has to decide how they are going to do the work. In true agile teams, it has to be work volunteering, not work allocation.

If the team has velocity calculations in place, and is thriving on work volunteering, then I respect their agility. They are doing things correctly, where as others are just claiming that they are agile.

Can I see the sprint burn down chart?

A burn down chart is more like a flight landing within the runway. Without it there is no transparency into the process and inspection based on empiricism is lacking. If the team is using the burn down chart to track their progress every day and make decisions based on it, that is a great positive sign of a good implementation.

If a team is doing very positively on the above three questions, then they have a respectable agile implementation. Others are just talking about it.

About the author of this post

Abrachan Pudussery (Aby) is a freelance agile coach, working closely with teams in improving their agility. He lives in Kochi and Bangalore cities of India. Phone 0091 9895372115 email : trueagilityconsulting@gmail.com 

10 key reasons to be truly agile – by an Agile coach, witness

  1. Faster return on investment (ROI) to the customer through iterative and incremental deliveries, than the traditional big bang deliveries. This gives an opportunity to the customers to start using the key features early.
  2. Better transparency to the customer – The customer gets absolute visibility into the development process. In account where we were associated with agile roll out, their customer was asking their supplier (my customer) to recruit more people, because of the better transparency into the manpower loading pattern and the work to be completed.
  3. Better risk management (financial, technical, people) –  The risks could be both positive and negative.  In one large team I got associated with, they built a product for three years to realize that nobody wanted it. A fast failure would have helped them to save millions. That was the reason why they embraced agile. A fast failure of a sprint due to architectural issues will always help to avoid lot of rework. Early sprint failures due to technical deficit of the team stops the development of a substandard product. Is it not good. If you appreciate it, you have the right agile mindset.
  4. Better predictability – In agile planning, the target set for a sprint is always based on the historical data of the team’s productivity. This increases the probability of the teams delivering what is committed, and very often little more than committed.
  5. Better transparency to the development team – In one organization the development head was highly skeptical about scrum initially, because he felt he is going to loose visibility into the development process. Luckily he sat through the agile training along with the team and towards the end he became the biggest supporter for agile. After understanding the agile framework, he realized that the transparency is much better than the traditional models.
  6. Better productivity by eliminating non contributing members– Yes, I meant productivity. Not from day one. If we go to the gym, first we get body pain, then only the benefits follow. Same is the case here. When we embrace agility, initially it hurts, especially the non contributing members to the deliverable. They can either become contributing members, or they do not have a role in the agile world. That is a reality one has to face. Over a period of time (not years, I am talking about a couple of months), you will have a team of contributing members only.
  7. Better productivity through positive peer pressure – One of the key aspects of agile teams is their self organizing nature. The decides how they are going to operate. It thrives on work volunteering than allocation. This brings in better ownership and productivity.
  8. Better work life balance – Agile talks about 8 hour working days. We are not talking about spending 8 hours in the office. We are talking about doing 8 hours productive work in the office within 8 – 9 office hours. This leads to better motivation and energy levels.
  9. Sense of urgency – Every sprint end is more like a project end. The pressure is always on the team. This speeds up work. When we conducted a survey for a team of 100, after experiencing scrum for almost 10 months, they unanimously said that they are under pressure with pleasure. It is a constant self imposed pressure, not the last minute pressures.
  10. Ability to enjoy work – When did you miss your office last, when you took a leave?. Is this an Utopian question?. On many occasions, the agile team members call their colleagues to find out the status and to know about what happened in the daily stand ups and the burn downs. Many occasions I have seen scrum masters reminding their team members to have lunch breaks. These are happening again and again. I am witness to it.

This post is motivated by my past one decades agile training and coaching experience. There are many cases where teams tried to be agile and then failed due to several reasons, which I will discuss sometime later. The term ‘ teams truly agile’ is significant while reading this post. 

Agile transition, team level, our recommendation

Here is what worked for us in the past to transition a new team  into a confident, self sustaining agile team.

T1 – The process starts with a one or two days (depending on the number of participants) workshop titled ‘Agile project management using Scrum’.

C1 – The coach works along with the team during the 1st sprint planning meeting

C2 – The coach works along with the team during the day#1 of the sprint

C3 – The coach works along with the team during the sprint review and the sprint retrospective

C4 – The coach works along with the team during the sprint planning meeting of the second sprint

20150424-131430.jpg

The whole process gets over during the course of the sprint (as per the sprint duration)

The coach will be available to the team for any doubt clarification (online) up to three months after the completion date of this assignment.

Let us start a dialogue. Call 0091 9895372115  email: trueagilityconsulting@gmail.com