Continuous Deployment over Sprint Reviews

Waterfall required a big leap of faith (and often, a suicide leap) for business stakeholders: Open your wallet, wait a couple years and pray that you find the results useful. In Scrum, we make things more tangible: Every couple weeks,  stakeholders and developers gather and look at working software, discussing the good, bad and the ugly. The best part? Everything that is "Done" is already an asset, even long before the project's delivery date.

The value of Reviews

Truth be told, stakeholders often don't know what they really need unless they have something they can look at and fiddle with. Let's humour for one second the thought that a comprehensive specification and UML diagrams exist. 

Once the first couple lines of code are written, maybe just a GUI without any functionality - maybe just a few algorithms without a database connection ... the relevant users can take a look and decide whether that's workable, where the weak spots are and what could be done to make the construct more useful.

None of this is possible by looking at complex specification documents, because everything a document review does is add more levels of detail, not innovating new, efficient ways of doing things better.

What happens when you don't have Reviews

Or, alternatively, "What happens when stakeholders don't attend reviews, don't give feedback during reviews - or developers show funny powerpoint slides instead of working software".

In the Review, developers and business stakeholders re-sync mutual expectations and understanding. The next sprint can be planned more efficiently with the knowledge where the most value lies - from here.

Not having frequent, good reviews means that developers continue working with assumptions rather than with users. It also means that the most powerful Inspect+Adapt mechanism is taken from the team. Obvious faults in concepts will not be discovered until someone fiddles with the software or validates the system against their understanding of business.

Why having Reviews is bad

There is nothing intrinsically bad about Reviews. But there is something bad about having a set date, maybe once every 2 weeks, where Reviews are conducted.

Slow Feedback

Reviews are definitely an improvement towards simply "throwing stuff over the fence" because they enable feedback. Unfortunately, they encourage developers to move stories into "Done" without checking whether users actually like the result. Just asking you personally: Are you proud to call something "done" without knowing whether the person you're doing it for will like it? Ideally, we receive feedback even while developing the feature, ideally so fast that we can actually respond to change. Maybe there's no need to continue developing after a certain point, maybe we need to do things completely differently than we initially assumed.

Batch processing

The biggest problem of Reviews is the batch processing. If you got 5 Stories are on the sprint, 4 will be done long before the Review, and stakeholders can't see them until the timebox is over. This turns sour when these stories build upon one another and the first story already had a fundamental flaw: The entire sprint may need to be discarded.

Induced waste

This means we have an interval of a couple days where developers already start forgetting the "Why" and "How" before they have to recoup everything to produce a demo. Sometimes, they counter this by writing presentation notes upfront, which do not provide any value to the customer.

Worse than this - if different stakeholders attend in order to review different stories, their time is wasted. Marketing doesn't care about this fancy new form for sales - and sales doesn't care about the new campaign algorithm. But both patiently sit through the non-value adding time.

Lost value

The first item in the sprint backlog is the most valuable item of the sprint. So, it gets done first. That's common sense. However, many teams don't deploy to Production until the PO accepted the sprint's "Done" items in the Review. 

This means that from the time the most valuable item is done until the Sprint Review is completed, we have the most valuable deliverable rotting in the repo, producing zero value!

Summary

It is definitely good to have Reviews and a serious improvement over not having them. Reserving (half) an hour every 2 weeks to ensure you deliver high value, remain on the right track and have happy stakeholders is definitely a good idea.

But it is better to receive instant feedback on every work item completed. 

Continuous Deployment is a rigorous, highly disciplined approach to move completed features directly to where you receive this feedback - to the real users. You won't need to wait for a specific future date, you will instantly know how users respond. And from a business perspective: you don't keep the dollars on the shelf, you reap them!

Continuous Improvement over Retrospectives

The Retrospective is Scrum's most powerful tool for sustaining and improving productivity. After each sprint, the team gathers the most critical pain points and agrees on a few specific ones that should be dealt with during the next sprint. Success is tracked from sprint to sprint.

The value of Retrospectives

Harnessing the power of retrospectives, the organization gains transparency on why developers are impedited and through the improvement activity, productivity is brought to whole new levels. 

In organizations strongly embracing change, it is not rare for newly formed Scrum teams to see a productivity boost of well over 200% within a couple of months.

Yes, you read right: Retrospectives are the key to hyperproductivity.

What happens when you don't have Retrospectives?

Well, that one is easy to answer. The team gets into a treadmill of delivering feature after feature, sprint after sprint, release after release, year after year. The same old problems linger, get persistently ignored and nothing changes until someone and disrupts the process.

The most common kind of disruption here is that developers simply get fed up and leave. The next type of disruption is that the next "powerful methodology" comes up and because it promises so much better results, Scrum gets abandoned. Those are still okay. But what if the disruption is that a competitor throws out a much better product, delivering much faster and cheaper - and takes over your customers?

In Waterfall projects, people conducted either "Lessons Learned" after each major Release - or "Post Mortem" after each failed project (to the point that Post Mortem became the Standard project closure process). But hardly ever was anything done about it.

Retrospectives try to change this behaviour by frequently inspecting and adapting the process. You fix what's broken rather than cleaning up the shambles.

So - why should ne not have can anyone say Retrospectives are bad? Well, they are not "bad". But they are a suboptimal state. Consider the following a stimulation of thought rather than bashing.

Why having Retrospectives is bad

Deferral of thought

Oftentimes, team members purposefully do not think about improvement until the Retro, because the Retro is the time to bring up issues. This is not an inherent problem of Retros, but of mindset. It is absolutely false to consider that we should not think about Continuous Improvement when we are outside the Retro meeting.

Deferral of solution

In each Retrospective, the team will agree on the most pressing 1-3 issues, so that productivity is not replaced with internal improvement. Unfortunately, this kind of thinking is absurd: If the team has too many issues, it may simply be better to solve them all at once before loading up yet more technical debt.

If there are pressing issues that damage productivity more than their resolution costs, why should you defer the solution for a couple sprints?

Absolution for suboptimal work

One of the major outcomes of Retrospectives are adjustments to the Definition of Done. On the flip side, the DoD is immutable for the duration of a sprint. However, if team members are already aware that their DoD is suboptimal, they should not adhere to inefficient standards but rather do what common sense dictates: Huddle, resolve, continue efficiently.

Thinking within the box

Retrospectives are team-centered. Purposefully, external stakeholders are NOT invited, as the Scrum Primer states. Is it right to consider all problems to be local when everyone knows they are not? Maybe, the team can't even see a problem until an external stakeholder escalates and then there's an emergency: Sprint termination, crisis meetings and general panic. Is this necessary?

Why would you give the team a forum to speak their entire mind - but not to the customer? Is their opinion worth less than that of the developers? Especially if they could help with the solution! So - how will the team harness the improvement potential that others could offer?

Problem thinking

A key element of Continuous Improvement is problem solving. But it isn't the only element. This is not intrinsic to Retros, but to the practice implemented in many teams. When do they have time to think about mastering their expertise, turning Good to Great? As long as there are pressing issues, solving a problem may defer the strife for excellence. However, it may be better at becoming exceptional in one area than becoming okay in all areas.

Summary

It is good to have Retrospectives. If your reason for not conducting Retrospectives is that "We don't find anything to improve" or "We can't accomplish anything anyways" - that's your #1 pressing problem and reason to call an emergency Retrospective.

On the other hand, Retrospectives are on the same line as any other Scrum event: It is good to have them, but it is better to work in flow: As soon as something comes up, harness it. Do not batch up, do not defer. Involve stakeholders, engage customers. 

Everyone should be on a continuous watch for improvement potential and should jump at every opportunity to produce a positive bottom line for the team, the company, the product - and the customer.

Taking Initiative over dedicated Scrum Masters

The second value of the Post-Scrum Manifesto states "Taking Initiative over dedicated Scrum Masters".

To understand what this means, we must briefly glance at why we even have Scrum Masters in Scrum.

 

The role of the Scrum Master

Who is the Scrum Master anyways and what do they do? A small (yet in Scrum trainings, most emphasized) portion of their responsibility is keeping the rigour of Scrum, reminding stakeholders and team members of their role, facilitating the events and getting impediments solved.

Probably the biggest responsibility is moulding the developers into a team, creating a powerful workforce able to cooperatively turn user stories into valuable, working software - by any means necessary.

And with that, the Scrum Master's main responsibility is: to become superfluous.

What happens when you don't have a Scrum Master

For example, teams who are not aware of the Tuckman model may never reach a superior performance: Being busy fighting fires day-in, day-out may prevent progression. A Scrum Master should be aware of this situation and free the team to pass through the Storm.

Initial teams often abandon "pure Scrum" very quickly: Daily Standups turn into detail discussions or get skipped altogether, Review Meetings become Tech Talks, Retrospectives become venting sessions. The Scrum Master guides teams to be more effective, but also coaches members on why these events are important and what their intended outcome is - and when they are missing the mark.

For many organizations transitioning to Scrum this statement is (should be) applicable: The Scrum Master is empowered to resolve impediments outside the team's sphere of control. They may freely move beyond team boundaries to make the team more effective. Most of all, not being a developer, they have time to do this.

And, let's not forget the most important aspect of becoming agile: It does not suffice - or, to put it more bluntly: It does not work - to have "a bunch of nerds in IT doing Scrum". It may help a bit when things are in utter chaos. To be effective, the organization must embrace agility. The Scrum Master should evangelize management, stakeholders on the benefits and responsibilities of working in an agile context and win other developers who are currently working in less effective structures for the new, improved approach.

Why having a Scrum Master on the team is bad

Let us start with the most important responsibility of the Scrum Master:

Orchestrated Agile transformation

Disclaimer: There is nothing, absolutely nothing wrong with bringing experience on board.  When everybody looks to one person "So, how should we do Scrum?" - that's a terminal disease: Failure and success of Scrum would hinge on one person. However, Scrum is a team discipline, so that's counterproductive. Deming realized a good 30 years ago in his 14 Principles that "the transformation is everybody's job!".  As such, everybody should be leading the Agile transformation.

Lack of impediment resolution

It is good if there is someone on the team who can assist developers in removing their impediments. However, there is already an organizational issue when people are impedited and unable to resolve this by themselves. Having a mindset of "I can not resolve this by myself" is a killer to motivation and productivity. As such, every team member should feel both responsible and empowered to remove their own impediments.

Ineffective Events

Events, such as the standup are not for Scrum. Much less are they for the Scrum Master. As long as team members rely on the Scrum Master to facilitate events - at worst: reporting to the SM -  they do not reap the full benefit. Each event serves a team purpose, so it should not even be necessary for the SM to organize or attend these: The team should drive every events that is valuable to them! 

For this, every team member should understand the value they obtain from a event - the SM can't do that for them!

Fixing symptoms, not causes

Each time the SM intervenes against outside interference to keep the team uninterrupted, that is a fix to the symptom. The root cause is that someone doesn't understand what they are doing. It is good to have a pitbull biting anyone who unknowingly damages productivity. It is better if there is nobody who does that.

Wrong source of improvement

The team members may justified have trust in the SM's ability to improve, but every activity introduced by the SM does not originate from the team, which means that they did not have the mindset to identify the problem or come up with the solution. The very fact that the SM adds value to the team is a shortcoming of the team. In a truly self-sufficient team, an SM can not add value.

Driven evangelization

It is good when the SM can evangelize others in the agile agenda. It would be better if the team's results would inspire others to participate. As the old adage goes "Preach by any means necessary. If inevitable, use words." - the SM can assist as an information radiator, ideally the team is already a shining beacon. The SM can (should) not be busy establishing disciplines like software craftsmanship, refining backlogs etc. in stead of the team. The more they involve in these activities, the less mature the team is.

Summary

Anything that the SM does for the team indicates a dysfunction in the team. There is no excuse for anyone on the team to not be doing what the SM does. A good SM is the key ingredient of a highly successful team. A great SM will make themselves superfluous.