Agile 2018

Agile 2018
Speaking at Agile 2018

Monday, June 11, 2018

No Estimates have a spot at the Campfire

Lots of debate around the campfire.
One of the best things about being a member of the Agile community is the smart and enthusiastic people you encounter online and in person.  It is refreshing and challenging to be around people who have a shared vision of making business faster, sustainable, and more intelligent.  The commitment to the goals of agile does not mean we are ideologically unified and dogmatic.  Like any healthy practice, we disagree with each other about basic principles, ways to spread adoption, and innovations.  The creative tension is essential.  I want to add my two cents to an on-going debate which a colleague Ryan Ripley brought to my attention from the sober and restrained convention floor of the #BetterSoftwareCon in Las Vegas. 

The #NoEstimates movement has become a very vocal camp in the agile reformation.  If you follow the debate, it is easy to see why.  The estimation process at many companies is farcical and corrupt.  Story points were created to provide the benefits of estimation without the obvious drawbacks.  The #NoEstimates crowd take this to a logical conclusion and say estimating is a waste of time and energy.

I do not feel very strongly about #NoEstimates.  What makes it interesting is it provides a different perspective to authoring software.  Neil Killick then posted a white paper this week showing some qualitative measurements which show a no estimates approach works just as well as a story point approach.  

I was skeptical but, I decided to give the article the benefit of the doubt.  Killick uses T-Shirt sizes to measure ambiguity and difficulty.  Using arithmetic and charts, he shows how he can forecast project completion.  The approach is well thought out and clear.  It is also story points dressed up to look like #NoEstimates.  It requires the product owners to spend time doing arithmetic instead of writing stories and working with customers and developers.  Personally, I struggle getting product owners to perform the basics of their duties.  Thus, using Killick’s approach may work for a different agile implementation but not for mine. 

I genuinely dislike debates which generate more heat than light.  Killick provides a good approach for a more mature agile team.  I am glad I had a chance to learn about it and will keep it in my chest of tools if I feel it worth trying.  The agile manifesto says, “Individuals and interactions over, processes and tools.” I believe that Killick’s approach is a process which might work with a particular set of individuals.  I also think that discussion of #NoEstimates is good for the agile movement.  People try out ideas, test them, and they are adopted or rejected over time.  It sounds mighty agile to me.

Until next time. 

Monday, June 4, 2018

Break out of your rut!

I have been thinking about my craft.  A scrum master is a coach, therapist, and advocate for their team.  We have emotional ups and downs in the profession.  We are also fortunate enough to make a difference in the organizations we work.  It is rewarding but filled with the trade-offs professionals are confronted.  This week wanted to discuss a constant force in the life of a scrum master continuous improvement.

As a professional, it is easy to get into a rut.  Decision fatigue sets in and so you order the same thing for lunch or manage how you deliver software.  Routine and inertia are comfortable because it provides a false sense of security in an uncertain world.  Your heart could stop from a simple blob of cholesterol of the company share price could crumble overnight, but thanks to the routine we ignore these catastrophes.  Inertia is safe and secure.  It is also the enemy of continuous improvement and agility.  It is why scrum requires retrospectives.  The feedback allows everyone evaluate how to improve. Development includes the product owners and the scrum master.

I was doing a product increment planning meeting for the product owners to coordinate releases and plan for the future.  On a whim, I decided to include a retrospective of the last quarter to get a sense of where we are and where we are going.  A tense hour later a few lessons were learned.  Using a four “L” retrospective, I wanted to understand how as a product development team we were doing.  The answer was unambiguous.  Some things which we could control had to change.  The retrospective included passive aggressive conduct, and a few choice criticisms pointed at me.  It was worth it.

Based on what I learned, I am going to conduct retrospectives differently with the development teams.  I am going to work with the product owners more closely to help them manage their work more closely.   Finally, I am going to try and break out of my decision fatigue.  Continuous improvement matters, and if you expect it of others, then you should expect it of yourself.

Until next time.


Tuesday, May 22, 2018

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.

Monday, May 14, 2018

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.

Monday, May 7, 2018

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.

Monday, April 30, 2018

Choose a Growth Mindset

Growth is not easy in this business.
One of the major features of agile is its emphasis on continuous improvement.  Teams, people, and processes can always get better.  If you do a 1% improvement each sprint and perform three-week sprints over the course of a year that equals a 17% improvement by the team.  Many times, small improvements are equivalent to significant increases over the long term.  What works with software development teams also works for scrum masters.  A scrum master should consider continuous growth to be a personal goal in their practice of agile.

I am currently working on becoming a Certified Team Coach.  It has been a time-consuming process with me logging hours and filling out forms.  I reviewed the five dysfunctions of a team and practiced SOLID code development.  I was about to file the first part of my two-part application when someone suggested that I get a pre-screen.  I was deeply disappointed by what happened next.  My screener said the first part of my application would be accepted, but I would ultimately be rejected in the second round because I did not have a “coaching mindset.”  I was disappointed.  It was as if the last five years of blogging, coding and being a scrum master were an empty exercise.  I was given a verbal pat on the head and sent on my way.

After doing some reflection, I went over my notes, and there were some suggestions for graduate-level courses in coaching.  I also spotted a class from the Harvard Business Review on coaching for leaders.  The pre-screener was even kind enough to recommend some graduate-level course in coaching which was local.

Maybe I was not ready.  During this time of reflection, I was exposed to the work of Stanford University professor Carol Dweck.  Her most influential idea is people to be successful need to move from a fixed mindset to a growth mindset.  This very positive idea is one which postulated that everyone is capable of growth and improvement.  Having a growth mindset means that development only happens if people actively seek improvement.  Traditional command and control methods of leadership are less effective than asking questions and having people find solutions rather than having them provided for them.  As I said, it is optimistic.  Professor Dweck can fail students who do not turn in the homework.  Me, I am stuck with product owners who will not write user stories.

I can see a few scrum masters and executives shaking their heads.  Authoring user stories is a fundamental part of being a product owner.  A leader with a fixed-mindset would take disciplinary action or try to teach that product owner to write stories promptly.  A growth mindset leader would ask questions, guide mindset, and follow up with the product owner to get them to improve on their own.  It is touchy-feely and genuinely optimistic.  It also runs counter to how I learned in the field of media and technology.

I was skeptical, but I decided to give it a try.  What happened next was a surprise.  A person responded positively.  They got better at what they did.  They did not improve as quickly as I would have liked, but they did enhance so after four weeks I noticed a difference.  Furthermore, when the person did things which usually triggered in the past, I saw a different motivation.  Now, instead of seeing them attempting to undermine my credibility or authority; I saw them checking for understanding and holding others accountable.  The situation is not entirely sunshine and rainbows, but it is improving.  I should embrace improvement over stagnation.

So here I am attempting to adopt a growth-mindset and continuously improve one small step at a time. Taking a growth-mindset is the next step in my agile journey.

Until next time.


Monday, April 23, 2018

Machiavelli knows agile.

Machiavelli, knows some things about agile.
The agile reformation is all about satisfying customer needs, improving product quality, moving quickly and maintaining a sustainable pace of work.  These differing prerogatives require changing the way we think about work and looking at problems differently.  It means for agile to be successful a scrum master or coach must lead change.

Many times, I feel like Don Quixote jousting at windmills around the office. During a down period, one of my product owners pointed out a quotation from Machiavelli.
“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things.” 
Leave it to the prince of political manipulation to provide me with some fodder for my blog.
Change is hard because people prefer to have routine and ritual in their lives.  Also, people who benefit from the way things are will resist change because they might lose authority, money or status.  It is easy for individuals to see reform as a zero-sum game with a gain for someone else equal to a personal loss.  It is a pathology which I see in both technical and business professionals.

On the business side, it is a huge culture shock to work side by side with technical professionals.  Now they discover the systems and technology they take for granted is not the result of magic.  They collaborate on the authoring of requirements, and they have “skin in the game,” when it comes to the success or failure of an initiative.  No longer will the alibi of, “…it is technology’s fault,” work in an organization behaving in an agile fashion.

The rapid feedback is a benefit to both the business people and technology staff.  It avoids “death march” projects.  The days of building software which does not drive value to the business disappear with each iteration.  A software project can quickly pivot to new regulatory or market needs.  Finally, the CFO will see a reduction in cost overruns and failing projects.

Agile not only changes the business professionals who practice it; agile changes technology professional who follow it.  Developers begin to understand the challenges the business faces.  An engineer sees business partners as equals and worthy of respect. Writing unit test and performing automated deployments build trust with business partners as bugs and defects decrease.  The arrogance of software professionals being the smartest people in the room gives way to the humility of helping others succeed.  The hacker ethos of development gives way to a more professional perspective.

Agile is not perfect.  The reformation is only eighteen years old, but it is growing and improving.  It is starting to become the de-facto technique of doing new software development, and it is spreading to other areas of business.  Change is perilous.  Getting knocked off your horse is not fun, but nothing worth doing is easy.  The reformation is not going to stop and you either lead, follow or get out of its way.

Until next time.