It is time Agile crushes magical thinking in business.

Working in Technology is like taming a dragon.

In the contemporary business world, one of the things which surprised me the most is how divorced people are from the technology which their careers depend upon.  Arthur C. Clark, the author of “2001: A Space Odyssey,” said, “…and sufficiently advanced technology is indistinguishable from magic.”  Today, in a world moving at the speed of the internet, tens of millions of people are wandering the world behaving like magicians.  I want to talk about what this means for you the scrum master or agile coach. 

At the click of a smartphone, a human being can summon a ride, book restaurant reservations, order clothing, and find potential romantic partners.  News and gossip travel around the globe.  We can even live in virtual spaces reshaping our bodies ignoring concepts or gender and aging.  Thanks to the world of technology and algorithms we can live in a curated rich world where there are no opposing opinions and everything is quick and convenient.  It is a seductive world. 

The world I describe is the product of millions of hours of labor and the application of fifty years of merciless engineering to make systems better, faster and cheaper.  It is the application of silicon wafer technology, advanced mathematics, and smart people doing smart things.  It is the unwritten story of our time.

Now imagine people who live in the magical age who want to implement a new payroll system or create a better way to get products to customers.  Since they are accustomed to systems which are quick and compliant, they think it is possible to spin up systems which behave the same way with the speed of downloading a phone application.  These magicians take it for granted that the data will always be correct and they do not need to proofread the work. 

This is not the reality of technology.  Developers need to get involved, and they need to be managed, so the code is clean and scalable.  Data needs to be placed on Oracle or Microsoft SQL servers.  Network accounts need to be created, and all of this costs time and money.  It is not magic.  It is hard work.

As a former web developer, it always troubled me when people told me how they expected a website to look and behave without understanding a lick of HTML code.  It is my experience these individuals rise in organizations and get budget authority.  So you have the ignorant paying the bills while someone more ignorant is giving orders to the development team.  It falls to a technology lead or scrum master to transform ignorance and magical thinking into code.   It is just as disheartening as it sounds. 

It is also why so many technology projects fail because the people involved do not conceptually understand the labor it takes to get the job done.  A construction project is easy to understand compared to a software project because the people paying the bills realize what is happening.  A typical business person does not understand the difference between Java-script and JAVA; so how are they going to know what it takes to successfully construct a web application.

As a scrum master, it is your responsibility to crush magical thinking.  Tell the truth about how long it is going to take to get something done.  Show people work in progress and ship code periodically so if adjustments need to be made they can happen in a timelier manner.  You will have to say no, and you will have to create trust between the development team and business.  This means enforcing one of the central tenants of Agile; their business sets the project priorities, and the development team says how long it is going to take.  If this social compact is not upheld, then any agile implementation will collapse into dust. 

So in this magical world, it is up to the scrum master to create a much-needed dose of reality.  Otherwise, you are confronted with an evil magic act which does nothing but disappoint. 

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.

How do you fund these Agile projects?

Software professionals are not Lego bricks.

I had the good fortune to finish a training course by Benjamin Day about scrum master skills.  I highly recommend you visit Pluralsight and take his course.  One of the more interesting things about his training was the conversation about how to do annual budgeting with Agile and Scrum.  This week I want to discuss my observations on the subject.

Isaac Socalich wrote a blog post taking about “Legacy thinking” holding back agile adoption at organizations.  He cites the way projects are funded saying accounting practices lead organizations to fund and allocate resources only once around a product, project, or process improvement.  In short, a project has a start, middle, and end.  The people, funding and output of the project are cells in a spreadsheet which manages the project.

This legacy financing model is short sided, counterproductive and the antithesis of the agile movement.  The Agile manifesto stresses “Customer collaboration over contract negotiation,” with legacy financing of projects every activity is reduced to contract negotiation.  The project is conceived with unrealistic expectations.  The deadlines for completion do not reflect the opinions of those doing the work.  Customer considerations are ignored and the funding is at best a guess done by an accountant.  It is no wonder so many software projects fail.  

The most aggravating part of legacy thinking is that treats consultants and people who do the work as machine tools which can be replaced when they are no longer useful.  Teams are created and disbanded based on funding formulas rather than business needs.  This means technical professionals are being treated like mercenaries to build software.  This also creates technical professionals who have no personal investment in the products they are creating.  They are temporary workers billing hours and doing work with no real concern for quality.  

For example, an off-shore team is working on software and because of a lack of funding they are disbanded.  Four months later, the finance department restores funding and a new team is spun up.  The original developers are gone along with the two years of experience they had on the project.  The organization now has to spend the first six months of the project training the off shore team about the business and navigating the legacy code.  The remaining six months of funding is spend attempting to do a year’s worth of labor.  Quality suffers, deadlines are missed and the customer is dissatisfied but the project was correctly funded by the business.

Software teams should be professionals invested in the business and each other rather than disposable Lego bricks.  Projects should be spun up and spun down being given to these project teams.  These teams should remain constant while the projects come and go rather than the other way around.

This is why I like Benjamin Day’s approach so much.  Instead of setting arbitrary deadlines and features to be done by the development team which has no investment in the success of the project, the team is permanent with growing business knowledge and technical skills who take on projects as they are funded.  The business people also concentrate on setting priorities of what gets done.  The project is not thrown over the wall for IT to figure out or fail.  Finally, the business has the right to cancel the project if it is not working.  The team remains to take on the next challenge.  The business either discovers it has working software for the customer and does not need as much funding saving money or has been making a poor investment and can cut its losses.

Over the last fifteen years the Agile Reformation has made great strides in making software development better but it appears that business suites and finance teams are not changing their processes to accommodate this new approach. They do so at the risk to their own business.  Survival is not mandatory and these legacy finance issues will be a cancer in many businesses in the future.  It is up to us in the agile movement to try and help those worth saving.  Otherwise, technologists will be condemned to careers of temporary employment, failure and frustration.

Until next time.