How To Control Chaos – 5 Important Scrum Lessons By Ken Schwaber

Who doesn’t want to control Chaos?

Like many other managers in IT, you’ve been working hard to improve software development processes in your team, department, or organisation.

You’re constantly experimenting with new methodologies and approaches to improve your team’s productivity, efficiency, delivery at pace. You’re trying to make life simple and peaceful for your team and yourself, and to help everyone be effective at their job.

Again, like everybody else, you’ve zeroed in on Scrum as your silver bullet. You’ve heard, read and in some cases, personally witnessed the positive transformation that Scrum can bring to its followers.

And so, you’ve dived headlong into the world of Agile and Scrum. No surprises here. You’re officially Scrum-bound as a team, department, organisation. You can sense the coming of the good tidings that Scrum brings over time.

Yet, you’re facing bumps along the ride.

Your team probably hates agile – and you’re learning to cope with that.

You’re doing everything you can to successfully transform your Waterfall organisation to Agile. Yet, there must be better ways to move to Agile and Scrum. Bringing Scrum into a Waterfall world has its challenges. You’re wondering what these are and how to overcome them.

And I’m here to help you make sense of the Chaos.

In this post, we will look at the top 5 Scrum Lessons I’ve learnt from following Ken Schwaber’s life and teachings, and from my attempts at Controlling Chaos everyday.

By being mindful of these lessons, you will be able to make sense of Scrum and take full advantage of the benefits Scrum has to offer. You will be able to Control the Chaos.

Let’s dive right in, shall we?

Who is Ken Schwaber?

Before we begin, however, I’d like to talk you through some history. History of Scrum.

More specifically, I’d like to dwell on the impact that Ken Schwaber, co-creator of Scrum, has had on propagating Scrum and its benefits to the Agile software development world. While we’re discussing his legacy, we’ll also review the top 5 Scrum lessons we can all learn from Ken Schwaber’s almost three decades’ experience in using Scrum to make teams better.

Why, you ask?

• So you can appreciate how Ken Schwaber thought, and thinks, about Scrum.
• So you can understand what you should and should NOT expect from Scrum.
• So you can imbibe and put to practice some of the best practices when deploying Scrum to your team.
• So you can do Scrum right.
• So you can enable your team to succeed.

You’d need to be a Scrum rookie to not know Ken Schwaber. Widely credited as one of the fathers of the Scrum framework for Agile software development, Ken Schwaber worked with Jeff Sutherland to develop the initial versions of the Scrum framework. Together with Sutherland, Schwaber has worked tirelessly to bring Scrum to the mainstream.

The journey began when Schwaber first presented Scrum as a formal development framework at the annual OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference in 1995. He then went on to ink his signature on the Agile Manifesto. Schwaber then formed the Agile Alliance and the Scrum Alliance. The rest, as they say, is history.

Nowadays, Schwaber runs Scrum.org, working with individuals and organisations to provide training, assessments and certification to support adoption of Scrum and Agile software development practices. Schwaber and Sutherland also co-wrote and published the definitive Scrum guide, which they make available to everyone for free.

It isn’t by chance that Scrum and Agile methodology have transformed software development practices. Ken Schwaber and Jeff Sutherland have worked tirelessly to ensure that the framework is simple yet effective in improving a project team’s work quality, productivity and efficiency. The effect of their work is there for all to see.

Controlling Chaos

This is the dream of every manager in IT.

We all want just one thing.

The ability to control what happens with our teams, projects, organisation.

To rein in the number of issues that constantly plague project delivery. To reduce the amount of delay and overspend that eat away at our ability to deliver high-quality, high-value software week-on-week, month-on-month, year-on-year.

Chaos is inevitable when you’re driving a large programme. Often, there are too many moving parts. Size breeds complexity and confusion.

Then again, there are too many players. A large team is difficult to organise and manage.

Despite your best efforts, Chaos is unavoidable. That is the nature of delivering large programmes of development work.

So, there remains just one challenge to overcome – how do you control the Chaos?

Ken Schwaber has worked with individuals, teams and organisations over the past two decades to help them Control the Chaos around them. Let’s look at the top 5 Scrum lessons you can learn from his extensive experience.

Lesson #1: Scrum is NOT a Silver Bullet

“When the strategy, a market-changing idea and Scrum come together, is when you see success.”

Scrum is a framework.

• It helps you deliver a high-quality software product.
• It helps you deliver faster.
• IT helps you deliver at a lower cost than Waterfall.

Note the keyword – deliver.

Scrum is an enabler – not the only ingredient you need for success. You also need a good, solid strategy. And a great product idea. When the strategy, a market-changing idea and Scrum come together, is when you see success.

Using Scrum to deliver a bad product idea will only help you deliver a bad product – even you are able to deliver faster and at a lower cost.

“Using Scrum to deliver a bad product idea will only help you deliver a bad product”

Lesson #2: Indispensable Scrum Tenets: Transparency, Inspection, Adaptation

If you do Scrum right, then the basic tenets of Transparency, Inspection and Adaptation form the core of how you manage your team.

Transparency implies everyone in the team understands what’s happening, and has visibility of artefacts, plans, roles.

Using the formal Scrum events such as Sprint Planning, Daily Scrum, Sprint Reviews and Retrospectives to Inspect progress against plan and Adapt to changing dynamics, will help you steer your team clear of troubled waters and on to calmer surrounds.

Your projects/teams are only really Scrum-compliant when they follow the three tenets in both letter and spirit.

Case in Point

I know teams and organisations that adopted the Scrum ceremonies on their ‘Agile’ projects with zest and vigour, but failed to imbibe the tenets. There were Daily Scrums, Scrum of Scrums, Sprint planning sessions and Sprint demos and Sprint Retrospectives. Yet, the project plan was managed in Excel (which in itself wasn’t wrong).

Sprints were four weeks long (again, with the right justification, I can digest this). There were Requirements Sprints, Development Sprints, Test Sprints (this I cannot digest – no matter the justification). The team didn’t decide their capacity or scope for a sprint – they were told to deliver a scope. Velocity, burndown, story points, burnup were all Latin and Greek to the team.

This isn’t Scrum – this is a wolf in Scrum garb. Ken Schwaber surely wouldn’t stand for it.

Lesson #3: Risk Avoidance is Fool’s Gold

Identify and Manage risks – don’t try to entirely avoid them.

Understand the difference between Risk Mitigation and Risk Avoidance. Identifying risks up front and early on in a project shows good management skill. Planning to avoid risks altogether does not.

Every product idea involves an element of risk.

“Manage the risk – don’t avoid it. Don’t let risk aversion paralyse you from moving forward.”

For example, if you’re launching a website redesign to catch up to standard market practices like mobile optimised web pages, the risk for this particular project is that it isn’t delivering innovation. And that the redesign might be too little too late – your customers may already have migrated to competitors who offer a better experience and might be reluctant to come back. A mitigant might be to launch a separate project that brings mobile-friendly features that put you ahead of competition. You shouldn’t peg the mobile optimisation effort to the new and cool features and slow down delivery for both feature sets. Allow the optimisation project to go live, with marketing efforts to hail the improved look and feel. And in all your comms, tout the upcoming cool features that will deliver more value and better customer experience.

Manage the risk – don’t avoid it. Don’t let risk aversion paralyse you from moving forward. Scrum and its principles help you avoid such paralysis by advocating and enabling frequent product releases. Frequent releases help you constantly improve your product, keeping your customers interested, while also boosting your team’s confidence in their own abilities to deliver at pace in a risk-prone environment.

Lesson #4: Scrum is Scrum only when it is implemented in its entirety

As Ken Schwaber notes in some of his writings, while some Scrum components can be absorbed individually, the benefits of Scrum can only be enjoyed wholly when you deploy Scrum completely.

“Don’t skimp on Scrum. Deploy Scrum firmly, and diligently. No shortcuts.”

Waterfall organisations looking to please senior management and customers, tend to re-christen Waterfall development phases to sound ‘like’ Scrum. Development sprints, test sprints, requirement sprints – sound familiar?

It is called Waterfall – with a sprint added to each waterfall phase. This Waterfall-in-Scrum’s-clothing practice inevitably only leads to failure. I can vouch for that.

Too often, I’ve seen large Waterfall projects and organisations use Scrum terminology to paper over their inability to deliver simpler, faster, better. Such teams and organisations have never succeeded – they just postponed the inevitable failure, and exacerbated the issues with poor process migration.

Don’t skimp on Scrum. Deploy Scrum firmly, and diligently. No shortcuts.

If there is a need to stay Waterfall, then do that. Don’t please your bosses in the short term only to suffer over the long-term.

Lesson #5: Truly adopting Scrum is Transformative, Disruptive, Hard

This goes hand in hand with the previous lesson. While Schwaber notes that Scrum is NOT Scrum IF it’s NOT completely Scrum, Ken also observes how challenging it can be to deploy Scrum. Especially if you aren’t a start-up or a fairly lean small-sized firm, transforming a primarily Waterfall organisation to Scrum and Agile software development practices can take years and heavy investment. It also means significant overhaul of how your organisation is run, and the organisational structure. The ramifications on people and what they do will be unprecedentedly brutal.

Transformation to Scrum is going to be extremely painful, disruptive and hard to achieve. There is no doubt, however, that the fruit of your labour will be sweet. Yet, you need to be mindful of how you want to get there – incrementally or go big bang. If you’d like further reading, I have covered Transforming your organisation to Agile and Scrum extensively in the past.

---

Bringing it all together

Ken Schwaber is a standing example of the principles of Scrum that he propagates. With his life and his body of work, Ken has demonstrated how to succeed with Scrum.

His lessons from almost three decades’ experience with Scrum show us how to function effectively amidst the chaos that surrounds us every day. You too can make the most of your Scrum initiatives and steer your team towards a more effective work environment.

Do Scrum. Do it right. The results will come. Soon enough.

Did you find this article helpful? Share your key takeaway in the comments section below, and let’s discuss.