Leadership Models and Books

As an Agile leader I find it useful to be reading books on leadership and models I can learn from.

Here are recommended reading if you are a leader working with people.

  • 7 Habits of Effective People
  • Primal Leadership or Emotional Intelligence ( Goleman)
  • The fifth Discipline  ( Senge)
  • Fierce Conversations (Scott)
  • Good TO Great ( Collins)
  • Difficult Conversations ( Harvard Negotiation Project )
  • Drive (Pink)
  • The Servant (Hunter)
  • The Power of TED ( Emerald)
  • The 5 Dysfunctions of a team ( Lencioni)
  • Focusing In Clinical Practice – The Essence to Change
  • Reinventing Organizations ( Frederic Laloux)
  • The 3rd Alternative (Steven Covey)
  • Leadership And Self Deception 
  • Quality Software Management, Vol. 1: Systems Thinking ­ Gerald Weinberg
  • Quality Software Management, Vol. 3: Congruent Action ­ Gerald Weinberg
  • First Break All the Rules
Advertisements

New ScrumMaster Checklist

This list is a place for new ScrumMasters for their very first ScrumMaster Job.

Welcome to your new ScrumMaster task. It is a tough one and sure is confusing. No Organization actually has a role like this. So where do you start.

Set up a meeting with  your manager and the manager of the team that you will be ScrumMaster of.

This meeting is important so you can expect what kinds of things they are expecting you to do. You should talk to them about things you are expecting to do

  1. Make impediments Visible.
  2. Facilitate the 4 core Scrum Meetings
  3. Remove Impediments

That is it. Make sure they are okay with these three things. If you hear no for all three of them, don’t take this job.There are many other things you can do but the above three arissues-board3e core to your job.

Make impediments Visible.

Next create a impediment board and make sure the managers know that you will put something here and if you cannot figure out how to solve it in a day or two, you will ask for their help. Also if possible make this a physical board.

Facilitate 4 Core Meetings.

Find out when the sprints are starting. If the team is not yet sprinting, just add the work they are each doing into one list and call that the product backlog for now.

Find our who the product owner. You have to make sure you have a Product Owner for Scrum to work.

In general all Scrum Meetings should follow the following principles

1) They need to be high energy

2) They need to start in time

3) Only the Team and PO are needed. Don’t invite anyone yet

4) They always end before time

A general agenda for all meeting

  1. Opening
  2. Purpose of the event
  3. Task-board for each event
  4.  Close with Action Items
  5.  Do a mini retro about the event itself.

Here is the  five items for each of the meetings.

{Work in Progress}

Are you failing with Agile, Here is a checklist to help you fail?

I had a very interesting coffee discussion yesterday with a senior product engineer at a very large cloud computing team. It was centered around the fact that in Scrum when we put the pressure of velocity and show the demo, teams start shipping crap to customers.

Many teams working in Scrum and Agile techniques take Agile as a way to do fast paced development. When you look at the net output after a few years, the product is a bunch of messed up code that is worth throwing out.

The agile manifesto is centered around – Working Software over comprehensive documentation –

I wish this was instead written as  – Delighting customer over comprehensive documentation. Writing a well done product takes a significant amount of discipline from a product team. The teams that focus on output of showing something fast end up in rotten software over time.

Here is a checklist that will tell you if you are going to failing with your product. These are in no priority order

1) More Velocity Syndrome – Your customer or management is focused on more velocity every sprint. Soon coaches are trying to optimize for waste removal , fast paced demos and a each day feels like a 100 meter race.

2) Agile or Scrum Become more important that the product itself .  Think  of any place that has ever succeded by putting focus on the techniques. No agile technique will help you if your organization cannot focus on less things and get them done in a systematic way

When you are doing agile well, you should not heard the word agile or Scrum in a organization.

3) Agile coaches rule the roost: There is a new wave of  people who were not there 10 years ago . These are called Agile coaches. Many are self proclaimed gurus with no actual complex product creating background. Choose your coaches wisely and don’t listen to them managers. Good teams choose coaches well. If your coach comes in and starts telling you do that everything you do is wrong, show them the way. Ask them to stay for a release cycle and show you how to do it all the way.

4) Managers addicted to keeping people busy: Many managers are busy trying to keep people busy . Writing a good product requires focus, patience and a bit of love. If the manager is always trying to keep team members busy where is the time to innovate. When you hear someone saying i want 80 percent utilization, start looking for a new job. They clearly don’t know what they are doing.

 5) Product Backlog fiasco – Your backlog looks like a so messed that you feel like throwing up. A good backlog should be around 50 to 100 items and should be visual. The team should have a clear idea of what they are building.

6) Estimation Accuracy Epidemic ( Often called as Fibonacci Fever) – You will see teams trying to size work as 2 points, 3 points, 50 points. Management disagrees saying they want more accuracy of estimation.

Software is a empirical system the only way you know your product is right is when someone uses it. Follow a simple rule ship a few items to production every month or as needed.

7) The myth of the self organizing team – Putting five people together does not make anyone a team. A team needs a clear purpose, goal and a good coach to win. Some kinds of work may not need a team.

8) Bugs rate is going north – IF  you do Agile well you should see 0 defects. To do this you need to do a few simple things 

  1. Work in pairs in small teams
  2. Test your product well and don’t check-in code that does not have unit test
  3. When you find a bug, write a test first, check it in, and then fix it. This way you never have to see the same bug again.
  4. Keep Design simple but not Stupid. Many agile teams have gone to the extreme with Kiss principle. KISS – Keep it simple stupid does not mean – Do stupid things in code”.  Agile does not mean no design. Agile means you take the time to do necessary design.
  5. Always demo work only when completely done.Done means done . There is no half done fully done.

9) You feel like moving from Scrum to Kanban or vice versa. Note that the process is not the problem, people are. When you switch to scrum, if you dont follow the values of Scrum, Openness, honesty, transparency you will fail. No questions asked.

10) Feedback and failure  is not appreciated here.  – If you are worried about giving feeback to any one in the group or  your manager for lack of fear of losing job or being humiliated, you are already in the wrong kind of team. if your organization i not appreciating failure or feedback, they do not appreciate you.

Of all the things the difference in great product companies is the ability to listen to customer and employee feedack

Do let me know if you check at least more than five in the list above yes. If you checked none of these items above you are working for a fake organization.

Have a great time building awesome products. Focus less on Agile focus more on your customer experience.

How much to jump?

I was talking to a very senior exec of  US Corporation who was comparing his India Agile team with the Brazilian Agile team and I was really amazed the way he said it. That got me writing this article as I think he is right.

Here is what he said – I ask my teams in India to Jump they ask how high. I ask my teams in Brazil to jump, they ask why?

Is this really true?

1) Are teams in India allowed to ask Why ?

2) Is it a cultural thing that asking why is considered socially incorrect.

More on this thought soon? But I needed to pencil this down for now.

 

Request your contribution to Scrum Awareness In India

State of Scrum In India

Hello my name is Vibhu Srinivasan and some of you may know me. I am passionate about Agile practices and practice agile in everything I do from running  business to helping at home.  I am presenting on a topic called “Is Scrum For India” in the upcoming Scrum Gathering India to be held in Pune on the 26th and 27th of July 2013

In order to faciliate the session, I am trying to gather some data to really understand if scrum is working for teams in India. I feel you could help.

To do this, I  would need
1) To meet 25 scrum teams from Service and product companies alike.
2) To carry out a Survey from 200 independent practitioners in India on Scrum.

I would appreciate your response, if you are able to contribute some time of your team.

Based on your preference, I can visit your team for around 30 minutes in Hyderabad, Pune, Bangalore or Gurgaon to conduct the study. We could also do this through Skype or some other video channel.
The responses by the teams will be used only for our internal studies and the broadcast of the results will not carry your teams’ reference unless  we have your categorical permission for the same. If you so wish,  your teams’ video will be shown at the conference; if you don’t then we will not mention anything. As always I respect your organization’s privacy and will refrain from saying anything about you, your product or the customer if you choose to not expose that information

Please send an email to me with your preference for either a meeting with the team or  for the team to participate in a survey. My personal email is vibhu.srinivasan@gmail.com

Please note this is purely for benefit of the agile community and there is no commercial intent here.
There are no gifts or bribes associated with this. I am hoping you will do this because you care about the agile practices in the Indian context.

Agile India Conference – A wake up call for India

Here is a quick statistic for you. Here is a list of speakers in Agiel2013 India conference starting tomorrow as a much publicized expensive show. While it is an honor to have so many awesome speakers from across the world some of the best in the industry it is indeed sad that more than 90 percent of these speakers do not work closely with teams in India. This means there are absolutely no credible teams or speakers in India which I find hard to believe.

The most common argument i hear is that the quality of speakers from India is horrible and is not a crowd puller. Speakers from India often find it tough to get selected in agile conferences in US as most of the speakers who speak here also dominate the stage when you submit a paper in the US.

How would agile in India even succeed if there is hardly any local presence .Even if it sucks  ( which i find tough to believe) I would like to see the real problems in Indian software industry come out in open. The challenges that indian teams face are culturally very different .

I am really disapointed that the list is an all star show with lots of great speakers. Wake up speakers in Indian organizations. “You have just been told you suck”

But you should surely go ahead and listen to all these dignitaries and at least learn a bit more so that we do not have this fiasco in future agile conferences in India. A sad day for Indian Agile scene Indeed. Here is a list of speakers.  There are only four of five i see from India.

Craig Larman
Owen Rogers
Linda Rising
Dave Hoover
Henrik Kniberg
Fred George
Neal Ford
Laurent Bossavit
Karl Scotland
Steve Wolfe
Jeff Patton
Ram Srinivasan
Masa K Maeda
Evelyn Tian
David West, Rebecca Rikner
Mary Poppendieck
Kenji Hiranabe
Cara Turner
Fred George
Jez Humble
David West
Neal Ford
Thushara Wijewardena
Naresh jain
Aslam Khan
Kenji Hiranabe
Henrik Kniberg
Jeff Patton
Sherif Mansour
Ebin John Poovathany
Howard Deiner
Masa K Maeda
Linda Rising
Kevlin Henney
Tathagat Varma
Siddharta Govindaraj
Owen Rogers
Mary Poppendieck
Jenny Quillien
Jagadeesh B
Jez Humble, Badrinath J
Laurent Bossavit
Venkat Subramaniam
Tarang Baxi, Chirag Doshi
Assumption of Agile
Fred George
Dave West, Jenny Quillien
Nick Pellow
Kevlin Henney

I do really think though that this be a eye opener for Indian organizations and agile practitioners and coaches who have just been told that neither can you present in western conferences nor local ones in India itself

The affinity we have to listen to speakers from west surprises me.

 

What is velocity?

Velocity can be termed as the run rate of the team . Agile teams use this metric to measure how much work was done in a sprint , so that we know how much more is left to actually make the reason.

Let take a simple example .

The team has ten stories whose total story point is 140. They pulled around 30 points of work this sprint . They finished 25 points. This 25 is their run rate.

With this the team and product owner can product owner can project how many more sprints are needed to finish the work.

We are assuming that the team is using story pointing here.

Some myths about velocity
1. Teams velocity keeps increasing over time.
2. A team having a better run rate is a better team
3. Since some team last year delivered at a certain velocity, this new team will also deliver at the same velocity
4 Velocity can be a predictable measure sprint after sprint even if we keep moving team members in and out.
I have seen many team members mindlessly argue over the effectiveness of velocity and end up wasting valuable time.

In fact in the beginning in 2005 ,as a developer I would not see the point of such calculations. After a while I got used to this and stopped worrying about such metrics and just focused on writing clean code.

Also velocity as a measure only works well with teams that tend to practice Scrum and not as much with Kanban or XP teams.

Many scrummasters get into this coach mode with a single focus to help increase the velocity of the team. Instead I would encourage ScrumMasters to looking at completing the work they pulled min style as well as help team and team members identify waste in the system.

This metric is not as important as number of automated unit test or number of production bug in the system.

20130114-090532.jpg