Estimating Sprints aka the problem with Scrum

Agile landscape assumes lots of quick churn  - requirements grow and shrink, product scope shifts, technologies are tried on for fit, even delivery platforms seem to be switching multiple times within project life cycle.

The time where the team has had a chance to learn enough about the tech, the requirements, the platform, etc. appears to not come until much later in the project. In the meantime, while the team figures out the tech and goes along with the experimentation of what the users will find most useful, every estimate is a wild guess.

Yet, every two (or one, or three) weeks, there’s the big Question: what do we pull into this Sprint?
On one hand, there are learnings from past Sprints – some things have gotten easier, other things were dropped because they could not be done, some architectural decisions have been made. One the other hand, past Sprint experience shows that unexpected things invariably come up and slow progress to a crawl.

Then there is reporting. Forward-looking reporting means it looks bad if the team has not completed everything it has pulled into each Sprint.  From this perspective, it is better to estimate conservatively.  Backward-counting from a deadline where currently-uncertain features are assumed to be required, and therefore must be packed into prior Sprints with no room to spare for dealing with the unexpected.  There is very real pressure to load up the Sprint with work that could possibly be all be delivered only under the best possible scenario.

A less-than-pure approach is flexibility: plan the Sprint conservatively, with the understanding that the Scrum Master together with Product Owner will prioritize backlog to pull work into the Sprint if there is time remaining.  This is less than ideal because having more on the plate leads to higher productivity overall – even if it’s not possible to complete everything.  Alternatively, a team can choose to plan the Spring aggressively, pulling more work in, and then reducing the Sprint load if necessary.   Unfortunately, this looks really bad from the outside.  Well-meaning teams can be penalized for under-delivering relative to an aggressive Sprint forecast - even when that Sprint forecast was deliberately set up to be unrealistic. 

Another option to deal with the planning question is to go back to the world where teams had a lot of scope-platform-design decisions made up-front, and could provide somewhat reasonable estimates 3-4 Sprints into the project.  While those estimates weren’t exactly right, there was predictability earlier in the project cycle.  But that would mean giving up the opportunity to learn and to benefit from new discover as the project is being worked. 

[ This post is a first part of a series. To be continued. ]

Achieving more by blaming less

Complex, consequential and time-sensitive problem-solving is best done in the atmosphere of full transparency. Alleviating fear of blame and sanctions is essential for having an honest conversation, taking social and technical risk, and otherwise focusing on doing valuable and creative work, rather than avoiding negative consequences. Not fearing consequences unleashes creativity and striving for better results, even if it involves risk, is correlated with great success in high-tech.

Sanction-less and blameless are both good, but not identical ideas.

Sanction-less means that those decided to be at fault are not going to be sanctioned – written up, demoted, fired, or otherwise punished. Sanction-less must come from the very top of the organization to be trustworthy, and is fairly clear-cut.  The promise of “no punishment” can still be broken at any time, but in many organization past history tends to be a reasonably good indicator of the future behavior.  If the management promises “sanction-less”, and has not levied sanctions for mistakes leading to serious and costly incidents in the past, it is likely that the next incident investigation will adhere to the same policy.

Blameless is more complicated.

Blame is a social construct, and involves interpersonal relationships, rather than company policy. Blame can be levied by any person involved in the situation, from the team members to stakeholders to users to bystanders. While blame can be accepted or not by the person who is being blamed, the blame is created by the person or people doing the blaming. It is easy to create blame – all it takes is one person, with any title, role or level of involvement. Once created, blame does not go away. It can slowly fade with time, it can also turn around on the people doing the blaming if it becomes known that the blame was created in error.  Blame often continues to affect relationships and interactions for a long time, even the relationships that were created after the blame first came into existence.

Blame is a natural human reaction in response to a negative situation.  While the goal of dealing with an incident is to recover and, if possible, to make up for lost value, people typically want to know what caused the problem, and who is at fault.  With wanting to know who is at fault comes the propensity to blame the negativity of the event on that person or people.

Is it possible to get away from the blame, and to create a blameless culture?

There are a couple of ways.  One is explicit and relentless focus on group responsibility, so that personal responsibility is forcibly completely disregarded. While actions are taken by specific people, it is possible to gather all accountability at the team level.  As causes of the problem are discovered, ignore the name or names attached to the action that created them to the best of your ability, to avoid blaming these people.  

The other way to avoid blame is to focus on the future rather than the past.  Do not look for the cause of the problem. Instead, look for a way to solve the problem going forward.  Work from the solution, rather than the cause, to make changes needed to avoid the same or similar problems in the future. The benefit of this approach is that all the effort goes into resolving the existing situation, rather than discovering and evaluating the past.

Blameless culture is not easy. Problems can be severe, emotions can run high, and searching for cause is deeply ingrained into our understanding of how work should get done. In addition, our tools are great at keeping logs on who did what and when.  

Knowing who caused the problem is synonymous with assigning blame. It is human nature to judge, to evaluate, to critique, and, yes, to blame. It is also human nature to guard against blame-inviting behavior, and not only we try to do well, we also try hard to hide what we did less well.  A lot of effort and cognitive strain goes into avoiding and escaping blame, however futile. 

Achieving blameless culture allows to avoid this waste, and more fully focus on other goals. Consciously working toward minimizing blame promotes healthier relationships, better emotional experience overall and specifically while dealing with severe incidents, and encourages more honesty and transparency.

Achieving success

When considering performance, there is typically more focus on failure than there is on success. Failures are often noticeable, well-remembered one-time events that generate high emotions and can affect many people.  There is the idea that teams learn from our mistakes and failures, and that in order to improve teams must fail publicly and painfully. It is believed that significant successes must somehow be rooted in overcoming past misfortunes and failures.

Success can be loud and come with a lot of fanfare as well, but the fanfare of success tends to fade faster.  New challenges pop up and emotions go away quickly because the team must get back to work, as success tends to bring in more work and generate additional challenges.  

As a result, success appears to play a smaller role in overall evaluation than failure.  That is both unfortunate and counter-productive.  

It is unfortunate, because failures are not necessarily what makes us learn and improve going forward. While occasionally there is learning that is an outcome of failure, the same learning can also happen without experiencing the fail.  A lot of failures are unavoidable, but nevertheless result in blame (or self-blame) and reduce motivation.

Focus on failures is also counter-productive, because failure is hardly ever the enemy. Failures come from experiments, from aspiring to reach farther, from ambition.  Statistically, it takes a number of failures to achieve significant success.  Without these failures, the success is either impossible, or a lot less likely.

Success is not the opposite of failure, rather, it is a significantly different happening.  Success often comes with more work and more responsibility, creates additional challenges, and pushes the team to work harder.  Success requires active learning and deliberate practice, and there is a need to learn still more to handle challenges brought on by the achievement.  Success encourages ambition and experimenting, and boosts motivation.

Success is the main driver of future success. It is time to focus more on success, and less on failure, when considering team performance.