What You discover at a coaching retreat

Why teammates from the Agile Coaching retreat.

I have been offline for a few weeks.  The reason was I had to have some downtime as I was involved with a conversion of a TFS 2015 server over to an instance of VSTS.  Also, I was getting ready for a trip to London for the Scrum Coaches Retreat.  The pressure along with the time requirements forced me to set aside my writing.  Things have settled down, and so I can get back to writing about agile.

It has been a whirlwind three weeks.  Family functions, work, and this trip to London have been my focus.  When you have time out for yourself, you learn a few things.  The primary lesson came from a scrum master I met from England.  Dominic Kavanaugh who pulled me aside during a stressful moment and said, “This retreat isn’t about shipping anything; it is about learning.”  From that moment, I had an epiphany.

The agile manifesto says working software over comprehensive documentation.  The principles of agile stress shipping software in small increments.  What I realized is I have forgotten a fundamental lesson about continuous improvement.  Learning and growth are a vital goal of being agile.  Shipping software is not a hamster wheel where everyone goes around and round shipping software and not improving.  It was my big revelation.

The revelation came as my team of coaches came upon the idea of “Healthy Ownership.”  I was complaining about the abusive relationship developing between my product owners and developers.  Soon another joined my group and spoke about quality assurance not working well with developers.  Finally, Dominic entered the group and talked about technical debt.  What united all three of these themes was that the development teams did not have a shared sense of ownership to the work they were doing.

Together, the team of us set out on a journey to try and come up with a way to discuss dysfunctions and how to fix them using a coaching approach.  It was the first time I exposed to terms like “clean language,” follow-on questioning, and guided conversation.  It was positive to have ten strong personalities in the room who were all success focused.  One person was our enforcer of norms.  The other was making sure we covered the topic of quality assurance.  Another was our enthusiastic product owner.  All of us learned to work together in three short days, and we came up with a “Healthy Ownership” model of coaching.

I am pretty proud of the small part I had to play in the creation of this tool; I hope to use it for the remainder of my career.  First, it is a descriptive approach to solving problems.  Often as a coach or scrum master, you want to jump in with an answer to a technical question or process problem.  It may answer the question, but it impedes self-organization on the team.  Next, we approach issues like a doctor looking at symptoms.  We gather information, ask a few questions and provide the right nudge to a person.  Finally, we are just getting started.  All of us have committed to being ready to improve and flesh “Healthy Ownership,” out.

I was not sure what I expected at the coaching retreat, but now that I have attended one, I see it as a valuable and worthwhile experience.   I am looking forward to going the next time.  I am also looking forward to sharing with you my experiences.

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.

Product Owners Have the Hardest Job in Agile.

Listen to Ben, hang together or hang separately.

I have been kicking around as a scrum master for the last three years.  I have been developing software for eighteen.  Those jobs are difficult and challenging but they do not compare to challenges faced by product owners.  This week I want to talk about the hardest job in Agile – the product owner.

The Scrum Guide is pretty clear about the members of a scrum team.  They are the developers who do the work.  The scrum master is the servant leader of the team and helps remove obstacles.  Finally, there is the Product owner.  The product owner sets priorities writes stories, and acts as the liaison between the business and the development team.  What most product owners do not know is the job includes so much more than what the scrum guide says.

A product owner needs to understand the internal politics of the organization so they can work with in it and sometimes around it to get things done.  Product owners need to understand the customer.  Not only understand the customer but be able to differentiate what software improvements will add value and which ones will waste money.  The product owner is under constant pressure to write stories and to create stories which can be transformed into testable code.  It is a grind and they need to practice mindfulness to separate what is important from what is trivial.

It is not an easy job and as a scrum master or coach you need to help them succeed.  This means spending time showing them how to write user stories.  Take time out to explain the agile manifesto and what developers need to succeed.  Take time to listen about the operations of the business and the politics of the organization.

A scrum master and product owner are equal partners.  To paraphrase Ben Franklin, you will hang together or you will hang separately.  When things go wrong it is usually the product owner who receive the blame.  As a scrum master it is up to you to make sure things do not go wrong.

Business today is not easy but a successful product owner can smooth off many of the rough edges to a software development team.  That is why it is the hardest job in Agile.

Until next time.

Getting DEEP with the Backlog Part 3

Riddle me this?
What is an emergent backlog?

This is part three of our four part series about how to make your backlog better using DEEP principles.  This week I want to talk with you about the third practice of getting a better backlog.  Together, we have covered how the backlog needs to be both detailed appropriately and estimated.  Today, I want you to cover how the backlog should be emergent.

The word emergent has become code in the agile world for “we have not figured this out yet.”  The truth is that when you are a product owner or a business you have vague ideas about what you are looking for but you don’t know the specifics of how to get there.  In the spirit of the age, we should talk about super-hero movies and the character Batman as an example.  Batman in the 1960’s had been around thirty years, so when ABC wanted to adapt it for television they could have taken numerous directions with the character.  They decided to make the series “campy” and appeal to children.

Today, the character of Batman is very different with a dark and grim edge based on the origin story of the 1930.  I happen to be a particular fan of Michael Keaton and his portrayal of the character in the late 1980’s.  That Batman is a different character from the one which Adam West made famous.  This is because the writers and producers made numerous choices along the way so that they reached a different narrative point.  As a product owner you will do the same thing.

What this means is that you will not have a finished software product which will emerge from your requirements like the great American novel.  Instead, you are going to have many small chapters in a long story and you will be able to inspect and adapt the story based on the situation.  This is why a backlog in the words of Roman Picher is emergent.  You are not sure how the project is going to end until you are finished.

This does not mean you don’t have a plan.  It means that instead of one great big product you have numerous small products which together make up a unified whole.  The product emerges from the individual stories and from the sprints.  So for your backlog to be successful it needs to be detailed, appropriately, estimated and emergent.  Next time we will talk about the final principle of DEEP.

Until Next time.

Getting DEEP with your backlog Part 2

Estimation is not rocket science

Last week, I began my discussion about how to be a better product owner.  I am using Roman Pichler’s DEEP approach to making the product backlog more useful.  Last week, I discussed how a backlog should be detailed appropriately.  This week I am covering estimation.

Estimation has gotten to be a dirty word among many technical professionals.  They are treated as quotes by business owners.  Estimates are often lies we tell ourselves and employers about how difficult a task can be.  So as a product owner, when you ask a development team to estimate you will often receive eye rolls and sarcasm.

The reality is, if estimation is done correctly, it can be a useful tool in planning work.  Each time a story is authored and placed in the backlog, the development team should attempt to estimate the story.  If the story is not detailed appropriately, the story is stent back to the product owner to be further refined.

If a story has enough detail them team should estimate it with story points.  Story points are a function of difficulty of a task and the uncertainty surrounding it.  Don’t consider it a measure of time but treat it like a measure of distance.  An Olympic runner can run a mile in under four minutes.  A man like me can walk it in about thirty minutes.  Considering the wide range of skills on many development teams, I may take one developer eight hours to complete a story point and it will take a different developer four.  Time is not the issue because complexity and uncertainty are the key factors.

Once a team begins estimating stories, you can experiment with team velocity.  If your team can do between 30 to 40 story points a sprint with a little simple arithmetic you can project out how long it is going to take you to finish.  For instance, if you have a 150 story point in your backlog in a worse case scenario you know it will take five sprints to complete the work while it will take four sprints in the best circumstances.

It may not be realistic for the team to have each story estimated so the rule of thumb I have discovered is you should have two sprints of work estimated.  You will have a good flow through the project.  You will also be able to answer the question your business partners care about most; when will the team finish and how much is it going to cost.

So that is why a product backlog should be estimated because it makes it easier for a team to budget its work.  An estimated product backlog also allows you some ability to forecast when the team is going to finish its work.  Finally, estimates are not hours treated as a quote but rather points which are a function of complexity and uncertainty.

So by having a backlog detailed appropriately and estimate you are going to be more successful as a product owner.

Until next time.