Sprint Planning Isn't Hard.

Sprint Planning can be easy. 

An agile development team is like a stool with three legs: each team has a scrum master, a product owner, and the development team.  The team practices the values of the agile manifesto and the principles of agile development.  The scrum guide outlines several rituals where the team plans and prepares for work on the next sprint.  Efficiently running sprint planning can set up the team for success, and this week I want to provide some tips on making your sprint planning sessions better. 

As a product owner, it helps to follow Roman Pichler D.E.E.P. framework for a product backlog.  Stories should be detailed, estimates, emergent, and prioritized.  Sprint planning depends on correct prioritization to be successful.  The product owner arranges the backlog from highest priority to lowest.  All the bugs, stories, and spikes in the sprint should have a preference.  The team takes those stories and adds them to an upcoming sprint.  It is an ideal time for the development team to ask the product owner additional questions.  

On a high-performing team, all of the backlog stories are estimated through a process I call backlog coaching and refinement.  At this point, the team adds as many stories as necessary to keep the team busy for the sprint's timebox.  If the team uses story points, you take the team's velocity and place that number of story points into the sprint.  If you use a no-estimates approach, then add the total number of stories completed into the sprint.  Either method will work depending on the team.  

Finally, sprint planning is the meeting facilitated by the product owner.  Since the product owner is responsible for the backlog's health and what the team does next, they must explain user stories to the team and justify the work's priorities.  It is also up to the product owner to respect the social compact of agile. They must accept developers' timelines in exchange for the developers receiving the priorities of the product owner.  

The sprint planning session should be a collaborative meeting facilitated by the product owner to plan the work which needs to get done.  Once finished, the team should have all the necessary information to have a successful sprint.  It takes practice and obeying the D.E.E.P. framework for the backlog, but the team's efficiency will improve, which makes the struggle worth it.  

Until next time.   

A sweet and sour career

The stuff of life.

It is the Christian holiday of Easter.  I am spending time with my family and friends.  I am also taking a look back at the start of the year.  It seems like only yesterday, I was counting down to midnight and wearing silly hats.  Now, I am wrapping up the first quarter.  I am unsure where the time goes.  This week, I would like to do a little reflection on the ebb and flow of being a scrum master.

I have repeatedly said on this blog being a scrum master is a calling.  It takes devotion and a touch of insanity to lead software developers and organizational change. I spend my days helping people ship software and then my evenings learning how to be better at my profession.  Someone I respect very much calls it the “sweet and sour” of a career.  Experiencing hardship makes accomplishment more meaningful.

This week I discovered I would be presenting at the Agile 2018 conference in San Diego.  I will be talking about the Cobra effect and how you can fight it.  It is a pretty significant accomplishment, and I am deeply grateful for the opportunity.  It also encourages me that I am not some voice in the wilderness.  I have spent nine years as an agilest, and it is profoundly satisfying that people are interested in the insights I have picked up along the way.  It is a lovely feeling.

The sour is the daily grind of putting out software.  I take calls from India each day.  I work with product owners to help them be successful.  I have created close bonds with my development partners because the pressures of shipping software are enormous.  It is early mornings and late nights.  It is cold coffee and petty arguments.  It is what must be done to create value for the business.

I accept the sour to appreciate the sweet.  Family, friends, and loved ones talk me through the sour times and help me celebrate the sweet.  It is not glamorous or pretty, but I have found meaning in the Agile reformation.  My life is a mixture of sweet and sour.

Until next time.

Learning to Manage time

Time should never be wasted

A software developer is a unique brand of employee.  The profession requires mental toughness and creativity.  The ability to create software also requires strong time management skills.  As a scrum master, you need to help your colleagues learn to manage time better.

If you work in technology, you confront a stark reality.  To keep the global economy moving there is a too much work chasing too few people.  Less than .05% of the world's population can build software and maintain the networks which run it.  Software engineers are under constant pressure to grind out code.  For those who do not understand, it feels like cramming for an exam every day of your working life.  This kind of pressure takes a mental and physical toll on the people doing the work.  Developer’s abuse alcohol, binge eat, take numerous prescription medications and engage in unhealthy behaviors to mitigate the stress.  It is an abusive cycle which leads to burnout and bad quality.

As a scrum master, we need to help others learn to manage time better.  First, create a routine for the development team and business owners.  The daily stand up should never state late, and everyone should attend.  Next developers need “quite time” to concentrate and do work.  People who are looking for favors, football pools, and making lunch plans are forbidden if they interrupt the developers.  Finally, headphones and other techniques to create a state of flow should be encouraged.
Business people divide their day in hour long chunks.  Software engineers think in thirds.  There are morning, afternoon and evening and each period is an opportunity to work and write software.  Another reason I have no meetings scheduled in the afternoon for the development team; I want the afternoons to be interruption free for the developers.

I also use it as a time management tool for product owners.  After lunch, I have a one-hour sprint refinement meeting.  We discuss stories for an hour and then adjourn for the day.  The time after sprint refinement is a perfect opportunity to write user stories.  Developers get into the routine of meetings in the morning and open afternoons of coding.  Product owners understand that the time after the sprint refinement meeting is for writing stories.

So a helpful way to help others better manage their time is to give them clear routines so they can set aside time to do the work.  It is not perfect, but it beats flailing around the office in a panic.

Until next time.

Complexity is not cool

Complexity does not help.

One of my biggest frustrations as an agile coach, scrum master, and software developer is how blithely business people think complexity is a good thing.  I do not refute that contemporary society is complicated and that living and working in global economy is challenging.  That does not mean that business people have a right to make this situation more complicated because complexity hides inefficiency, corruption, and stupidity better than any conspiracy theory could imagine.  This week I want to talk about simplicity and why it is important in agile and business.

This week the Harvard Business Review came out with a great article about the bank crisis of 2008 and how eight years later we still haven’t recovered from it.  At the heart of the article was the thesis that career specialists in an industry don’t make good decisions.  Worse, career specialists suffer from three characteristics which hurt their industry: hubris, blinkered vision, and lack of foresight.  With these three traits it was only a matter of time that these experts created a situation which nearly ruined the global economy.

I run into these situations all the time.  I remember having a discussion with an executive which sold medical supplies to nursing homes.  We were talking about how we set prices for our customers and how we do the accounting.  I was given a lecture about how our business was different from a traditional “retail” business because the products were going to nursing homes.  I remarked that the rules of accounting have not changed in 100 years and that everyone learned accounting from the same textbooks in college.  I was told that I had a bad attitude and that I should adjust the accounting system to meet the needs of the business.  Shortly, I left the company.  It was clear it was the kind of culture which used complexity hide misconduct.

Another instance was a company president who could not purchase an MSDN licenses to make sure all of his software was upgraded.  They would rather pay for a license here and there.  This meant the office had versions of office ranging from 1995 to 2003 and applications could not communicate with each other.  It was a nightmare that could have been solved if someone picked up the phone and purchased a license for the entire office.  Instead, it was easier for someone to go to the office supply store and pick up another shrink wrapped box of software which they would have to integrate with the rest of the office.  A complicated problem could be solved with a simple phone call but leadership choose complexity over simplicity.

According to the principles of the Agile Manifesto, simplicity is the art of maximizing the amount of work not done.  This means as the agile coach and as a scrum master, I spend a great deal of time asking if we really need to do something.  I spend plenty of time trying to find the simplest path to a solution.  I also say no to plenty of requests.  It isn’t easy but if you are going to reduce complexity at the office someone needs to be smart enough to say, “I don’t understand this, and because I don’t understand it, I can’t make it work.”

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.

Keeping it simple.

The light switch should be our inspiration

One of the most important principles in Agile is simplicity.  I work with plenty of clever people which means we come up with plenty of complicated ways of doing things.  True innovation and progress happens when we find simple ways of doing complicated things.  This week we are covering the virtues of simplicity.

When we talk about simplicity, we are not talking about something which is simple.  We are talking about something which is simple to use, simple to work with and simple to understand.  The example I like to use most, is the electrical power grid.  When we need to put a light in a room we plug in a lamp and turn on the switch.  The technology and work that goes into getting electricity to that lamp is very complex to but to us it is simple.

Technology like smart phones, web sites and accounting software should be like the electrical power grid.  Sadly, it is not.  Microsoft technologies are great for PC’s but in order to write web applications for a phone you need Xamarin or understand HTML5 to write Windows 10 applications.  Those applications do not work on Android and iOS devices.  This is just a sample of some of the technologies which do not play nice with each other for either market or technical reasons.

The blame for this trend is very smart people who, instead of working together to create simple and elegant solutions, have split into warring tribes.  It would take an entire book to discuss the history of why this has happened.  So to the average consumer we have a layer of complexity to everything we do and it needs to stop.  Even Apple has made music players a colossal mess making it impossible for people to manage the thousands of songs in their music libraries.

I do not have any magic bullets to fix this but is up to everyone in the agile community to try and reduce this kind of complexity.  It will not be easy but neither was setting up the national power grid.
Until next time.