Lessons learned being a scrum master

Failure is just part of being a good coach.

Being a scrum master is more than taking a test and receiving a certification.  There are plenty of hours of hard work and endless meetings.  As a rookie scrum master, I thought I understood the role.  Today, I know better.  This week some lessons learned.

When you discuss the term servant-leadership, many scrum masters see the developers they work with as servants.  This is backward.  A scrum master is a servant to the development team.  They provide help and guidance where they can they take care of the other team members before they take care of themselves. Most people see rank as having privileges; I disagree.  Rank is about responsibility for others, fulfilling those responsibilities and receiving only the privileges which benefit the entire team.

I am an extroverted person and according to the Myers-Briggs personality test I fit the model of charismatic leadership.  This is great for politics or giving presentations to a room full of fanboys but it is a handicap for a scrum master.  The reason is this leadership style means you talk more than you listen.  This is a recipe for failure for a scrum master.  To make change and coach others you need to listen and observer with the attention to detail of an anthropologist out in the field.  One of my early mentors, Andy LaChapelle said it best, “You have two ears and one mouth use them in that frequency.”

Finally, to be a scrum master is to let others do the work.  This has been the hardest lesson to internalize.  I have been a Type “A” person with plenty of nervous energy. When a task was incomplete, I would step in and finish it.  That is wrong and like an NFL coach going into a game to kick a field goal.  The scrum master is the coach and it is up to them to let the team members succeed and fail on their own terms.  It is maddening but so is coaching a team all week getting them in a position to win and have the kicker miss a field goal.

So experience has taught me that to be a successful scrum master you need to be a servant leader putting yourself above others.  A successful scrum master listens more than he speaks.  Finally, a successful scrum master lets the team do the work and self-organize.  I hope you take these lessons to heart so you don’t have to learn them the hard way like I did.

Until next time.

What Donald Rumsfield can tell us about being a Scrum Master

Donald Rumsfield back in the day.

Donald Rumsfield is going to be a controversial figure in history.  The Princeton graduate will be the center of plenty of scholarship about the Iraq war and the events surrounding the September 11th attacks.  Looking over his conduct of the Department of Defense and business career, I am not a big fan of his leadership style.  What I do acknowledge is his famous quotation about ambiguity and uncertainty.

“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.”

This week on the blog some things a scrum master can learn about ambiguity from the former Secretary of Defense.

Known-Knowns

Every scrum master confronts these each day of their career.  The coffee pot is broken.  Active Directory permissions are not correct for a developer and the compliance committee will not allow a production push for two weeks.  These are the known-knowns.  They are the daily challenges and impediments which crop up and are expected.  These issues are easily solvable, have been solved in the past, or can be ignored with little risk.  As a scrum master it is your job to sweep these kinds of issues out of the way to make your team successful.

Known-Unknowns

This is what traditional project managers call risk.  These are situation which can plan for but might not happen.  The most famous example is Eisenhower’s communique he was to send if the D-Day invasion failed.  As a scrum master, things can go horribly wrong and allowances for these things are necessary.

This situation also happens when developers are asked to do something they have not done before.  In my case, it is using modal forms with Bootstrap 3.  This known unknown is taking longer than I expected to implement.  If I have more serious time pressures, I would use a different approach on the website I am refactoring.  I am learning this new skill and taking the time to master it because it will transform into a known-known if I do the work.

Unknown-Unknown

These are the surprises, calamities and disasters that befall a development team.  The production server has not been upgraded to the latest version of the .Net framework.  The network administrator won the lottery and had tenured his resignation immediately.  Finally, the third party API the application relies on changes without notice.  An unknown-unknown quickly becomes a known-known because of the severity of its impact.

These land mines are silent and deadly traps which make the life miserable for a scrum master and technical professionals the serve.  It has been my experience that many of these unknown-unknowns are the product of technical debt.  So to reduce the amount of ugly surprises, reduce the amount of technical debt.

Unknown-Knowns

Salvoj Zizek, a philosopher and cultural critic mentioned there is a fourth category which Rumsfield neglects.  The is the world of the Unknown-Known.  This is a piece of knowledge you have which you chose to ignore.  An example of this could be a tech-lead who refuses to write unit tests because his “code does not have bugs.”  In my experience, the situation crops up because politics, prejudice, or human nature prevents us from acknowledging the evidence we are confronted.  You see this situation in co-dependent relationships and dysfunctional teams.  It is the duty of a scrum master to call this out and make sure that developers are aware of everything they need to be successful.

A scrum master needs to understand and confront the known-knowns, the known-unknowns, the unknown-unknowns and the unknown-knowns facing his team.  Otherwise, the project might go as smoothly as the Invasion of Iraq.

Until next time.

Rethinking how I look at story points.

Story points are not like coffee cups

I have been an agilest since 2009 and that means that my knowledge of scrum and agile have grown over time.  Occasionally, I have to reconsider some ideas I took for granted.    This week would like to review the notion of story points.

My change of heart came about when one of my developers Larry Gasik came to me and confronted me about how we treat story points.  Many scrum masters and people in the agile community treat story points as measurements of volume like cups at a coffee shop.  If a developer works six hours a day on code then three story points’ holds up to 18 hours of work or (3*6).  By the same logic a five point story can hold (5*6) or thirty hours of work.

I have been doing it wrong.  A story point is more like a measure of distance rather than volume.  This blog from Mountain Goat Software does a better job explaining this better than I can.  To calculate the “distance” of a story point it is the sum of difficulty and ambiguity rounded up to the nearest number on a Fibonacci sequence.  If I were to write a formula for this it would look like this.

Story Point = Difficulty + Ambiguity
F_n = [Story Point]

Where F_n is a number in a Fibonacci sequence.

Here is where the math gets important.  An Olympic runner can run a mile in under four minutes.  A middle aged man like me can walk that distance in about thirty.  The size of the mile does not change just the ability of the person to cover the distance.  So two people will take a different amount of time to complete a three point story.  So two people will take a different amount of time to complete a three point story.  Now we can use ranges of time.  In the case of three story points, on the low side (3*1) for one hour to complete a story point to eighteen hours or (3*6) on the high side.

This accomplishes three goals.  First, story estimates deal with ambiguity better because the ranges of time get larger as the story point increases in size.  Second the story point allows for better forecasting because developers who concentrate on story points and velocity can plan how much work they can handle in a sustainable fashion.  Finally, saying a story point is a range of time prevents managers and other business folks packing more work into a story point because it is not a fixed volume of hours.

By treating story points like units of distance instead of volume you eliminate numerous distractions in your agile practice.  Managers will not treat sprint estimates like quotations because of ambiguous nature of the amount of time it will take to do the work.  This also prevents a manager from placing more work into a sprint saying, “It was five story points and it only took you 20 hours so I am going to add about ten more hours of work to keep you busy.”

This helped me come up with something I call Kedar’s computation after my technical lead.  Story points also help reduce risk in a project. For instance, say your developers spend six hours a day coding.  The range of hours inside a story point is between one and six.  Following this reasoning three story points could take as little as three hours of work or 18 hours of work.  Now, you have a sprint with 39 story point’s worth of work.  The product backlog items in the sprint could be divided in two ways.  The first way is 13 three point stories.  The other way is three 13 point stories.  Doing a little arithmetic on the back of a napkin this is what you discover.

Given:
13 three point stories.
(3*1)*13 = 39 || (3*6)*13 = 234

Given:
Three 13 point stories
(13*1)*3 = 39 || (13*6)*3 = 234

The amount of hours are the same!  It is pretty cool but here is where you as a scrum master and project manager can say that you have more confidence in getting the work done.  Thirteen point stores are more risky to complete than and three point story and here is why.   Say the developers get stuck on a thirteen point story and fail to deliver it during the sprint.  The math looks like this below.

26/39 which simplifies to 2/3

Now do the same thing for the sprint with 13 three point stories.  The team gets stuck on a three point story.

36/39 which simplifies to 12/13

The team is going to be more satisfied with the work when they deliver 12/13 of the work than 2/3.  Management and the people paying the bills are going to be more forgiving of the team when only 1/13 of the work is incomplete rather than 1/3.

This is Kedar’s computation, which shows that while the work is the same, the risk is much greater for fewer stories with larger story point totals.  To go back to our runner analogy, the runner is completing smaller chunks of the race at a time and is more likely to complete the entire race.  We have a better means of tracking how far along the runner is during the contest.  It may take them a longer or shorter period of time to finish the race but the distance traveled is the same.  The only difference is that it has been divided into smaller laps.

This is why I have changed my mind about story points.  They are more a measure of distance with ranges of time rather than fixed volumes of time.  Making this intellectual shift will make estimating with story points more helpful.

Until next time.