Experience Matters in a Scrum Coach

Leadership experience is not pretty but necessary

Plenty of issues crop up in the day to day life of a scrum master.  Impediments need to be resolved and each day you are a living example of how Scrum is supposed to work.  As a fellow coach, Ryan Ripley remarked on how some individuals with little experience with agile are marketing themselves as coaches.  Ryan feels pretty strongly about the subject, and so do I.

There are two lines of thought about leadership.  The first school is called the “great man theory.”  This school firmly believes that great leaders are not made but are born.  This notion has been used for generations to support monarchs and other forms of tyranny.  For each leader born into greatness, there are numerous counterexamples of individuals who fall woefully short.  There is also an elitism and snobbishness associated with this school of leadership which says that only specific groups can aspire to leadership.  I also find this type of thinking has plenty of sexist and racist baggage associated with it.

The second school of thought is the notion that leadership can be taught just like any other skill.  I am a firm supporter of this idea.  When I was a teenager, I benefited from leadership training from Boy Scouts of America and Marine Corps Junior Reserve Officer Training Corps.  I had the Boy Scout Law ingrained into my personality at an early age.  The outdoor activities forced me to learn to help younger scouts cope with being alone and away from home for the first time.  Being caught in a rainstorm surrounded by wet and tired twelve-year-olds is a good measure of your leadership skills.

Marine Corps JROTC taught me self-discipline, my left form my right and that leadership is more about credibility than shouting at people.  I met some remarkable people.  David Ogle was a survivor of combat around the Chosin reservoir and a USMC boxing champion.  He served in Vietnam and became a Sergeant Major.  Richard Weidner was a company commander in Vietnam and taught me about the less than glamorous things leaders have to do.

Together, Boy Scouts and Marine JROTC gave me a good foundation from which to build.  I took that knowledge with me into the sales profession, the casino business, radio, and finally into technology.  I am entering the fifth year of being a scrum master.  The experience of shipping software at the end of each sprint changes a person and their style of leadership.  Working with offshore teams changes how you relate to others.  Those experiences make you a better scrum master and coach.

We can teach leadership, in my opinion.  I also feel experience acts as a multiplier of leadership skill.  A good leader does not ask someone to do something which they would not do themselves.  That means if you ask a developer to write a unit test you better be willing to write a few of your own.  An agile coach who has not led a retrospective or shipped code is not a coach because they lack the practical skills to make agile successful.  They are faux coaches, and you should steer clear of them.  An agile transformation is like performing a heart transplant on a person running a marathon; you would not trust that job to a first-year medical student.  Anyone can call themselves a coach, it takes time and experience to be a valuable coach

Until next time.

A Little Gratitude this Thanksgiving.

Mmmm Pie!

If you are working as an agile coach or scrum master you spend plenty of time working in negative situations.  Continuous improvement means finding things which are not working and helping others fix them.  It is an often a thankless process filled with personal and professional frustration.  This week I want to take a step back from my day to day struggles and reflect on the things which make me grateful.

I am grateful for the people who work with me.  I have developers spread over two continents, and they are smart and hardworking individuals who make my day easy.  The team accepts my faux cheerfulness in the early morning during stand-up calls.  The team also put up with my grumpy admonitions to follow good code practices.  The development teams I work with are a pleasure to work with, and any scrum master would be honored to work with them.

Next, I am deeply grateful to LSC Communications for allowing me to lead agile initiatives.  It has to be strange having an entrepreneurial person in your cubicles asking awkward questions and shaming individuals to do better work.  You embrace my enthusiasm and flakey nature to help make the organization better.  The world of business moves at the speed of the internet, and I am glad you allow me the opportunity to guide the firm in that direction.

I have an understanding group of friends.  I do not spend as much time with them as I should.  We play cards, board games and plenty of military simulations.  They keep me grounded.  They keep me clean and sober.  They have supported my professional decisions, and they have been there for me throughout the inevitable ups and downs of my career.

My family generates a fountain of gratitude.  As my parents have grown older, I have become close to them.  They show me the kindness and support that is sorely lacking in the other areas of my life.  In the aftermath of my divorce, they have prevented me from wallowing in loneliness and made sure I bought groceries.  I wish I were half as good as my parents.

In spite of all the difficulty of my career, I have a lot to be grateful; my colleagues, my company, my friends, and family make life worth living.

Happy Thanksgiving until next time.

The tribalism hurting your agile practice

My Agile Practice has changed over the years.

It has been a strange year.  Last year, I was talking about comfort food and sleeplessness.  Three hundred and sixty-five days later, I want to share a little wisdom I have gained along the way.  This week how disappointment can make you a better scrum master. 

I have deliberately not discussed politics on this blog.  The internet is filled with plenty of places on the political right and political left to discuss current events.  I have plenty of strong opinions myself but do not share them here because they are not germane to the discussion of Agile, Lean, and Scrum.  The world of business transformation is hard enough; injecting partisan political views seems counterproductive to me.

I come from the world of college debate and forensics.  It is a community centered in the “reality-based,” zones of academia, science, media, and government.  It is a skeptical community which relies on empiricism and rhetoric to persuade others. These same institutions are referred to by political conservatives as pillars of deceit.  A year ago, my smug self-assurance in my expertise took a severe beating. 

Over the last year, I have gotten much wiser.  I have rededicated myself to my profession.  I shut down my internet startup.  I even made an effort to listen to Nickelback to see if there was any merit to their music.  Suffice to say; it was the audio equivalent of eating chocolate frosting out of a tub with a spoon; including the stomach ache. 

The most significant notion revealing itself to me was the concept of epistemic-tribalism.  I felt that if you are “reality-based,” and gave people the facts of the situation, they would eventually come around to your point of view.  If this formulation was good enough for Socrates, then it was good enough for my agile practice.  I now realize this was naive.  People have deep emotional and political biases.  Stating the facts is not good enough.  When confronted with facts that contradict their worldview or place in the world, some people will reject those facts.  It is similar to the ideas of Wittgenstein who explained language was a construct and subject to games.  Furthermore, two people can look at the same object and see two different things.  The neat and tidy world based on objective reality and evidence fell away replaced by an effete world of conjecture resembling a postmodern literary theory class.  It was disorienting. 

If epistemic tribalism can happen in the realm of national politics, it is not too far of a stretch to see it manifest itself the cubical of an office.  Personal relationships are more important than sales.  Countless Quid Pro Quo agreements bind the office together and harm customer service.  Tenure with the organization is more important than accomplishment.  Finally, being likable is more important than getting work done.  It became clear to me that these things were happening.  I counted on the better angles of others instead of understanding the tangled webs of motivations.  To be a successful scrum master or agile coach, I had to accept office professionals could be nasty and brutish. 

So this last year for me, the political became professional.  Reason and empiricism are less useful tools for change compared with understanding the motivations and prejudices of my colleagues.  Epistemic-tribalism is a real thing, and you need to understand it in your organization.  Finally, it takes disappointment for you to set aside your prejudices and view your surrounding differently.

Until next time.

Agile is about Deadlines

I have nothing on Martin Luther
but I know a little about software development.

Five hundred years ago a German monk named Martin Luther hammered 95 theses to a church door.  He was calling attention to corruption inside the Catholic Church and started the events which created the protestant reformation.  The agile manifesto is only sixteen years old, but it has produced a transformation in the business world.  I consider myself one of the evangelists spreading the word.  With every reformation, there is a counter-reformation, and today I would like to discuss one of the principle objections used by opponents of agile.

There is an excellent blog post written by the Wall Street Journal called “9 Myths About Agile.”  I strongly recommend it.  One of the most durable myths about Agile is the preconception that deadlines do not matter. Work gets completed, and deadlines are not necessary.  I wish to argue that deadlines are an essential part of the agile process and provide an example of how it works.

The most central feature of Agile and Scrum is the time box of the sprint.  For two to four weeks, the development team completes goals.  If they do not finish the stories in that period, then the sprint is considered a failure.  Failure is not a bad thing it is a learning opportunity for the team can to do better next time. Scrum relies on deadlines to focus effort and drive improvement.

Skeptics would then argue that sprints are well and good, but there are not firm due dates to communicate to upper management or the people paying for the work.  My reply is that with a sprint backlog following Roman Pichler’s DEEP model, it is easy to forecast when work will get completed.  The backlog is detailed to show the volume of work.   The backlog is estimated because it allows the product owner and the business to predict when work will get done.  The backlog is emergent so it can adjust to changing conditions as a project moves forward.  Finally, prioritization allows the firm to say what matters and what does not.

I am now going to provide a simple example.  The marketing department needs to incorporate social media into its website.   The works need to be accomplished by November 1st. The product owner gets to work, and come up with a list of features.  It should look like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
  • Feature: Google+
  • Feature: Twitter
  • Feature: Pinterest

Now it is up to the Product Owner and development team to write stories.  After a week or two of effort the backlog looks like the following:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account.
    • Create Hooks into Facebook API.
    • UI for Social media on the page.
    • Create log internally when pages are shared.
  • Feature: Google+
    • Set up Google+ corporate account.
    • User Google tools to allow sharing of stories from the website.
    • UI for Social media on the Page.
    • Create log internally when pages and shared.
  • Feature: Twitter
    • Set up a corporate Twitter account.
    • Use Twitter API to post content.
    • UI for Social media.
    • Create log internally when pages are shared.
  • Feature: Pinterest
    • Set up corporate Pinterest account.
    • UI for Social media.
    • [Spike] prototype how to use Pinterest API.
    • Create a log when pages are shared.

The backlog looks typical to a scrum master or anyone on a development team.  The Vice President might understand what the group plans to do. The group estimates with story points because business people treat hours estimates as quotations of work.

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
    • Create log internally when pages and shared. - 13
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8
    • Create a log when pages are shared. - 13

The estimates from the team point out severe risk and ambiguity.  Also, the team has not worked with Pinterest, so they are going to do some experiments to understand how it works.  The sponsor of the product might get frustrated at this point and ask, “When will it be done? Can I have it by November 1st?”

The scrum master should be able to answer that question.  According to the backlog, there are roughly 91 story points of work.  The team can do 21 story points a sprint and each sprint is three weeks long.  It will take roughly twelve weeks to do the job. It is good news if it is June but bad news if it is September.

So a process of negotiation begins where stories get prioritized, and others ignored.  If the company sells food products, Pinterest may be more critical than Google+.  A media company which relies on breaking news might ignore Pinterest and focus on Twitter.  The product owner might notice that each social media site has its analytics suite and that an internal log is not necessary.  Fifty-two story points fall off the board.  We have 39 story points of work which we can get done in two sprints or six weeks.  If we begin in August, we will hit our due date.  The final board looks like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8

So in this brief and simple example, I have shown there is a quantitative and drama free fashion to discuss projects where deliverables get negotiated, and deadlines get met.   Agile and Scrum can help people make educated decisions about what work can get done and when it will get done.  All that is required is a conscientious product owner, a dedicated development team, and a scrum master who will speak the truth to decision makers.

Agile is about deadlines, and I am willing to put my career at risk to prove it; just like that German Monk from five centuries ago.

Until next time.