Don't Estimate Spikes

One of the principal values of agile is individuals and interactions over processes and tools.  Each organization is different, so how they do agile is going to vary.  Coaches should be sensitive to this reality.  Unfortunately, as people learn how to practice agile at an organization, they often let old biases and ways of doing things obscure how they continuously improve.  It is at this point a coach steps in points out they are doing something wrong. So today, I am taking some time to correct a gross misunderstanding.  

Earlier this year, I wrote about a particular type of product backlog item known as a spike.  It is a helpful way to plan work where the team is uncertain of how to proceed.  A manager instructed a colleague and his team to provide estimates for spikes during sprint planning.  When I learned about this, my danger sense started throbbing like an infected paper cut.  A spike is not estimated.  People who ask for estimation on spikes are misunderstanding their purpose.  

A spike allows the development team to perform research and analysis.  If they do the job appropriately, at the end of the sprint, they will have a prototype, code which is proof of concept, or more user stories that they can correctly estimate.  The team is learning how to do something; to ask them when they are going to know it is foolish.  Imagine a high school teacher demanding a student estimate how long it will take to learn how to perform equations with two variables when they do not understand what they need. As a result, the student feels pressured and resistant to learning.  Software developers will do the same, or they will give the manage lip service to make them go away.  

I understand why some managers want estimates for everything.  These managers do not know any better and hate dealing with uncertainty.  It is a direct by-product of traditional project management training.  Waterfall project management depended on people knowing how long it would take to perform a task. For example, a concrete slab can be poured and cure in 72 hours.  If a project required four concrete slabs, then the math is four times 72 or 288 hours.  Thus, a project manager could estimate it would take twelve business days to get the concrete finished for the project.  

The approach does not work for creative activities like software development, marketing, or business processes.  All of these activities have too much ambiguity and lack easy answers.  Asking someone to guess how much it will take to do something they have never done before is insensitive. These managers desire to have control over a situation they have little understanding or influence over the outcome.  A manager is asking for believable fiction rather than the messy reality we exist.  

Let me repeat, do not estimate a spike.  It does not add value to the customer.  The development team does not know if they can solve the problem, and management will treat the estimate like a quotation instead of fiction.  

People wanting to find some predictability for the team can choose a different approach.  Instead of asking the team to estimate a spike, count the number of spikes in a sprint. For example, suppose a team completes forty story points in a sprint; when they spike the sprint, they only complete thirty points.  Thus, a manager can deduce the spike took up ten points of intellectual capacity from the team.  People who use a “no estimates” approach can subtract the number of spikes in a sprint from the number of stories attempted.  Both methods to spikes concentrate on problem-solving instead of providing estimates with dubious value.  

Leading a large project is challenging on the best days, so I understand why managers want to estimate spikes. Still, it is not going to provide value to the customer, and it is going to generated meaningless data, which is going to hurt decision making. Moreover, it is more painful than an infected paper cut. 

Until next time. 

 

Integrity and Agile make a difference.

Being a coach and scrum master is one of the most rewarding experiences of my life.  I have worked with many great people, and I had received plenty of support from total strangers when life at the office was painful.  We are a diverse and unruly bunch of misfits who think we can change the business world one project at a time.  The last eleven years since I discovered agile changed me for the better and helped me find a purpose.  We talk about plenty of topics in agile: from servant leadership, being authentic to how to write a good user story. Still, we don’t talk about personal integrity and why it is so essential for the success of the agile reformation.  I want to correct that oversight.  

The author C.S. Lewis said, “Integrity is doing the right thing when no one is watching. “  It is a strange concept in business because we judge people on how they impress their superiors or how much revenue they generate in an amoral world which is concerned about profit; notions like character and integrity get lost in the daily hustle.  

What gets missed in the conversation about business and amorality is that to lead others effectively, business people must have a type of personal integrity that makes others want to follow them.  Leaders do not lead because they have a title or authority.  A person becomes a leader because others connect with them and wish to follow.  The secret sauce to leadership is personal and professional integrity.  

Borrowing from C.S. Lewis, I define integrity as a code of conduct you follow in public and private spheres.  You treat others with respect at the office and home.  Someone with integrity will never ask someone to do something they would not do themselves.  When your staff is working late, you are with them, providing moral support.  It is not an easy way to conduct your life, but it is fulfilling.  

People with integrity win the respect of others and the hatred of those who are lacking.  A person with integrity acts as an example for others to follow.  When they make a promise, they keep it.  Those with integrity move through the world with a quiet poise that others will notice and does not require constant self-promotion.  

Having integrity saves careers.  After a business meeting, select scrum masters in the organization were not performing their duties and billing their hours to the firm.  Within a week, these scofflaws were gone, and the remaining people granted more influence in the organization.  People see who is doing the work and who is skating by on good looks and charm.  When times are tough, people with integrity are those others want around.  

Angela Dugan, the Chief People Officer at Polaris Solutions, said at an after-hours meeting, “Do your job the best you can and let them fire you if they have a problem with that.”  It is a bit of wisdom that has remained with me during my career and the best definition of Integrity I can find in the business.  Imagine if every business person conducted themselves in that manner and how much better it would be.  It is a lofty goal and one I hope others with integrity will pursue with me. 

Until next time. 

 

Remembering Larry Blankenship

I have been part of agile reformation since 2009.  I evolved from a voice in the wilderness to part of a growing cohort of professionals who make the world of work better. Unfortunately, this week our tribe got a little smaller.  Larry Blankenship died from a heart attack this week. I am feeling compelled to honor the man and his work.  

Larry, like many of us, came to the agile reformation as a frustrated technology professional.  Projects were long, painful slogs, which ran over budget and demanded superhuman efforts. So naturally, when someone suggested a better way, people like Larry gravitated toward it.  He preached a common-sense approach to agile and development.  He was mid-western friendly with deep insight into engineering and human nature.  You could count on him for some humor and a subtle jab if you started acting smug.  

He represents a common theme among the people I know online and in-person related to the agile reformation.  Each of us has a deep devotion to making work feel less like drudgery and more like a vocation.  We are intelligent people who have discovered that many problems in technology are not technology problems but human issues which need addressing.  

Larry epitomized that mindset with wisdom, kindness, and a wry sense of humor.  The agile community is going to be less interesting without him.  Fortunately, more people are coming to join and carry his memory forward.  

Goodbye Larry, we will miss you.

SAFe is More Agile Than You Think

People who work in the agile world have two common characteristics.  The first is we are deeply committed to making work more sustainable, satisfying, and sane.  We also have strong opinions about how to make work better.  Like any other growing movement, you have a few splits between various camps about multiple practices.  I have spoken about the gulf between the no-estimates crowd and other agilists.  I also pointed out that the agile community often ignores the agile manifesto's admonition to put individuals and interactions over processes and tools.  Today, I will step into the debate between those who hate Scaled Agile Framework or SAFe and those who are more nuanced. 

Background –

I was exposed to SAFe when I attended training with Andrew Keener in 2017.  Agile worked on small to medium-sized projects, but a big challenge was getting it to work on a considerable scale.  Projects with thousands of developers and collaboration between numerous specialties, including hardware, mainframe, and legacy data systems, did not fit neatly into either scrum or kanban.  SAFe provided the answer with two key innovations.  

The first was the concept of a release train which made it possible to take numerous agile teams and coordinate them. Groups part of the same "train" would inspect and adapt merging code and sanding off the rough edges to create working solutions.  The other innovation was called product increment planning or P.I planning.  P.I planning is a series of meetings where the product owners and scrum masters would collaborate to eliminate dependencies and plan.  To coordinate these activities, SAFe created three new positions; a release train engineer, a program manager, and a software architect.  SAFe also provided a means for executives, and the rest of the organization to collaborate with release trains without interfering with the work.  

Backlash –

As SAFe grew in popularity, it spawned a backlash in the agile community.  Soon, SAFe had a reputation in agile circles similar to Nickelback in rock music circles.  The cool kids did not think it was good that this music and agile scaling technique became popular.  It spawned a backlash.  The web contains plenty of blogs and Twitter threads filled with earnest and lazy criticism of SAFe.

The best article about the criticism came from Gianpaolo Baglione, who pointed out that most of the criticism of SAFe fell into ten familiar categories.  I recommend you give it a read.  Many of the lazy arguments against SAFe are personal attacks on its authors or pointing out that it creates unnecessary layers of bureaucracy.  I have heard many of these arguments firsthand, and I want to acknowledge the more credible criticisms versus the lazy ones.  

Nuance –

I believe SAFe is an imperfect solution to the real problem of scaling software projects.  Being unable to deliver large software solutions hampered the Affordable Care Act's implementation and had deadly consequences for Boeing.  It provides a valuable starting point for managing massive projects.  I believe SAFe has three principal shortcomings; customer focus, poor leadership, and the P.I. sprint.

The agile manifesto says that customer collaboration is superior to contract negotiation.  If you look at the infographic on the SAFe website, it is tough to find the customer and relate them to the release trains.  I also notice that many conversations on agile teams are focused on meeting the goals of the release train rather than the customer.  I think more emphasis should be on the customer instead of less.  We should adopt the same attitude toward the customer which NASA did during the Apollo program.  Everyone, including the janitor who cleaned the bathrooms, said they were working on putting people on the moon.  When they crop up, conflicts should center around how the customer would be affected instead of personal agendas.  Once the focus is back on the customer, most agendas fall away.  

Next, we need to expose poor leaders within organizations and hold them accountable.  Instead of credible action, people who provide lip service are corrupt in many institutions, and SAFe is just as susceptible.  I remember being told by a Vice President that I could not discuss our challenges with DevOps with other departments because he did not want the "dirty laundry" of I.T. exposed to other groups.  I took a vow of silence instead of being transparent with others.  I left the company, but the V.P. still has his job, and the company filed for bankruptcy and laid off half of its people.  I consider this poor leadership and lack of transparency to be a factor in the companies failure.  Agile and SAFe have numerous feedback loops to fight poor leadership, but it requires people to set aside the status quo and commit themselves to something greater than themselves.  SAFe is nominally part of the Agile reformation, and so it is necessary to inspect and adapt everything in the organization to make things better, especially leadership.  

Finally, SAFe has what is called a P.I. iteration.  While leadership, scrum masters, and product owners prepare for the next increment during product increment planning, the development team coordinates to make sure code is ready for release.  It is supposed to be a training and development period.  In reality, the P.I. iteration is a frantic rush to release with plenty of "crunch time" and late nights making sure everything works.  SAFe must recognize that the development cohort must embrace software artisanship and DevOps if hundreds and thousands of people work on a project.  Otherwise, P.I. week is nothing more than a glorified hardening sprint, a severe anti-pattern in agile.

Conclusion –

The use of SAFe as a scaling method in business is imperfect.  It is up to people like me to help make SAFe behave more responsive and agile.  Let us start from the agile manifesto to make sure everyone is practicing the values and principles of agile.  SAFe needs more customer focus, and poor leadership needs exposure as part of the inspection and adaption process.  Finally, SAFe needs to do a better job embracing DevOps and software artisanship.  

Even though I'm not too fond of Nickleback, I am still open enough to listen to a song when the situation requires.  Scaled Agile Framework is not Nickleback, and with the work of skilled coaches, it can be a better tool if we are honest about the framework's shortcomings.  

Until next time.