Scrum does not have too many meetings

Each reform in society is confronted with a backlash.  The Protestant Reformation spawned the Inquisition.  It is natural that those threatened by it would oppose progress.  It is happening in businesses across the nation with the Agile reformation.  A common objection many have toward agile or scrum is there are too many meetings.  This week I want to discuss agile and meetings.

According to the scrum guide there are four events in scrum, they are:

• Sprint planning
• Daily Scrum or Stand-Up
• Sprint review 
• Sprint retrospective.

In the span of a work week, these meetings should be brief and informative.  A stand-up meeting should take approximately fifteen to thirty minutes.  If it takes longer, you should review how you are facilitating this meeting.  A sprint review is a demonstration to the business users and should take no longer than an hour.  Retrospectives allow a team to inspect and adapt their process.  Typically, this meeting is about sixty to ninety minutes in length.  Finally, there is sprint planning where the development team estimates stories and plans the next race.  Sprint planning can take as little as an hour and as much as six.

Based on this rough estimate we can determine how many hours the agile team is spending in meetings.  Based on a three-week sprint where is how it break down.

• Typical work week 40 x 3 = 120 hrs.
• Standup meeting – 0:15 x 15 = 3:45 hrs.
• Sprint Planning – 6 x 1 = 6 hrs.
• Sprint Review – 1 x 1 = 1 hrs.
• Retrospective – 1 x 1:30 = 1:30 hrs.
• Total Time budgeted in meetings = 12:15 hours of a 120 hrs. sprint.

Thus, a developer at worse case scenario spends just over ten percent of their time in meetings.  The remainder of the time is devoted to writing software and creating value for customers.  It is significantly less than in the world of waterfall project management with its numerous meetings to cover everything from architecture to problem-solving.

The scrum master and product owner spend their time in meetings, but it is to protect the team from being distracted from delivering value.  It is why I attend meetings about I.T. governance or architecture so that my team does not have to.  It is why the product owner is answering customer inquiries and meeting management.  We attend the meetings so the development team can concentrate on what is important which is shipping code.

It is why I find the argument that agile has too many meetings disingenuous.  People who are opposed to agile are not opposed to the meetings they are opposed to the routine nature of the meetings and the expectation to ship working code at the end of each sprint.  Transparency of this nature quickly exposes the unwilling, incompetent, or invisible people in an organization who do not deliver value.  When we discover these individuals, it creates a backlash in the organization.

So, scrum and agile does not spend too much time in meetings; it concentrated on what is essential.  An agile team’s first and foremost duty is to deliver value to the business; anything else is waste.  I am looking forward to hearing from you and knowing what you have to say.

Until next time.

Story Points for the Misinformed

It is all about planning poker.

Last week, I wrote a harsh critique of how project estimation is done at many organizations.  I do not like using the words farce and tragedy lightly, but in my experience, many projects devolve into these realms.  This week, I want to talk about story points and how they solve some of the problems I discussed how estimation is broken.

I have written two essential blog posts on story points.  The first was my reappraisal of story points as measurements of difficulty and ambiguity.  The other blog post illustrated how story points could be used to meet deadlines.  Reviewing those blogs, I think they are a clear explanation of the advanced uses of story points.  For those new, to story points, this blog is for you.

Last week I said traditional forms of project management rest on the mistaken notion that time and money equal the same thing.  It means when a project manager or developer gives an estimate and executive treats it like a quotation of work.  The experience is similar to going to an automotive mechanic receiving an estimate for $300 of work and getting a bill for $3,000.  As a consumer, you were expecting and budgeting for a $300 bill.  When confronted with an invoice ten times larger than expected, a person usually falls into a spiral of rage.

Story points defeat this situation.  First, the team members are playing planning poker and are collectively deciding how many points it takes to complete a unit of work.  It is not the opinion of one person be a consensus of numerous technical professionals.  Next, story points are the sum of ambiguity and difficulty of a unit of work.  There is no meaningful way to convert a story point into money or measure of time.  The only things that are certain is a team can complete a specific number of story points in a sprint time box.  The average number of story points completed over at least three sprints is called velocity.  I illustrated in an earlier blog velocity allows executives, scrum masters, and developers a means to forecast deadlines.  Finally, story points allow for severe discussions about scope, resources, and time without having to discuss dollars and cents.

My colleague, Steve Sether, points out story points are not a silver bullet for poorly managed projects.  Story points can be inflated to create the illusion of increasing velocity. Accountants attempt to put a dollar figure to story points and executives often ignore them to make promises without consulting the development teams.

For me, telling an executive, we have 213 story points in a software backlog is much more informative than claiming we can hit an arbitrary deadline.  We can take some action and make more informed decisions rather than rely on gut instincts.  Project estimation should not be farce or tragedy; with story points, a development team and a scrum master have a better way of estimating work and delivering to the business.

Until next time.

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.