Get certified - Transform your world of work today


Scrum Lessons Learned

Some Scrum lessons learned in the field

30 October 2015

Kenneth Adams
Apple, IBM and more...

If you're using Waterfall or some other non-Agile method, then transitioning to Agile principles and the Scrum process is a significant paradigm shift. It's likely that without professional Agile transformation guidance, you will encounter one or more common Agile implementation mistakes.

This article discusses some lessons learned through pain and triumph and tries to boil them down to a few do's and don'ts with some real-world scenarios.

The article will focus on the following do's and don'ts:
  • Don't take shortcuts with Scrum. Don't mess with what works.
  • Do support your Superheroes. ScrumMasters and Scrum product owners (POs) are your leaders; they must apply themselves as superheroes.
  • Don't micromanage. To reach maximum productivity, the Scrum team must be a self-managing entity.

Don't take shortcuts with Scrum

Tremendous advantages are realized by using a project management method as well known, as well established, and as proven as Scrum. So don't mess with what works.

Thinking that you're smarter than the worldwide community of Scrum experts and trying to create your own flavor of it, or bending it to fit your old way of thinking, is a huge mistake. Resist the urge to choose a "best of breed" solution. It won't be a "best" of anything.

Scrum is more simple than any breed of Waterfall or project management method I've ever seen, and I've seen a bunch. Don't overcomplicate things with baggage from your past. Let it go. Leave it behind. Because if you don't, it will trip you up.

It's important to note that if you stray from Scrum by adding your own bits, you'll lose a major competitive advantage, which I covered in my "Adopt Scrum for Competitive Advantage" article. Taking shortcuts with Scrum principles and techniques and cherry-picking parts of it to use will result in Scrum-But or Scrummerfall -- a highly compromised mess that is worse than a good Waterfall process.

Aaron Ericsson's article "Scrummerfall: World's Worst Software Development Methodology" provides a great definition of Scrummerfall and why you should not mess with Scrum:

"Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone."

I've heard it over and over again: "We will use Scrum, but . . . we're different [read: unique, special, smarter than everyone else], so we need to change this and that and the other thing."

Don't take this the wrong way, but you're not special. You're not smarter, other than having capitalized on the combined brainpower, talent, and expertise of the enormous worldwide Scrum community. And you are not unique. Not so much so that your process needs to be just yours alone. That's a good thing, because you can fully embrace a set of principles, processes, and tools that has been proven to work for more than a decade. A ton of expertise in the job market can help you do it right.

Don't fall into the "not-invented-here" trap. Standards of all kinds, including technology and methods, improve products and make work better and more fun. Technology standards dramatically accelerate the development of products, just as methodology standards like Scrum dramatically accelerate product development, the happiness of your teams, and the competitive advantage of your organization.

Scrum has seen it all. The creators of Agile and Scrum have been where you are now, and so have thousands of other companies and other people. Don't make their mistakes, but learn from their experience. There's a reason that Agile principles are so popular and that Scrum is the leading Agile software development framework all over the world.

If you think that modifying Scrum to fit your way of doing things or fit your organization's culture will make it easier, it won't. Natalie Warnert does a great job of summing up the reasons for not changing Scrum in her article "Why making things 'easier' makes them harder: The argument against modifying Scrum":

"The [percentage that] Agile Scrum methods are modified is exponentially proportionate to the [percentage] of extra work, complexity, and team stress that results."

If avoiding hardships and challenges aren't reasons enough to convince you to not mess with Scrum, then how about money? If you change Scrum or do a lousy job implementing Agile principles, it will cost you more money. It will cost you more money in terms of more time to get things done, in failures that take too long to discover, in lost productivity, in employee attrition or turnover, in lower quality, and in more bugs that have to be fixed.


Support your superheroes — ScrumMasters and Product Owners

The following excerpt is from an article about a mobile app design that I wrote almost two years ago:

" . . . to create breakthroughs, you don't need just great leaders and UX designers . . . You need artists!!! You need superheroes."

ScrumMasters and POs are your leaders. Great responsibility requires great powers -- a useful inverse of this popular quote. They need to be superheroes.

In a nutshell: ScrumMasters are focused on the process and the team. Scrum product owners are focused on requirements and ROI. But in mobile and Web app development, and other customer-facing apps, one or both of them must also be able to provide the leadership and vision in UX design that these apps require, more than anything else.

ScrumMasters and POs need the people leadership skills to bring together potentially competing interests. For example, I did some work for a large, popular wireless cellular company. Being such a well-known household brand, they had a long and deep relationship with a creative firm that developed their branding and advertising, but our team brought the technology expertise. Our common customer was of the business type. Conflicts between technology versus creativity is a fairly common issue in these types of situations and will certainly be in mobile and Web apps.

In that project, the responsibility fell on me to bridge the significant gaps among the creative, technical, and business worlds. Language translation between the three worlds was a common need: translating jargon, requirements, and intentions; handling diplomacy; and negotiating common ground.

For background information on Scrum roles, see the following references, which run from basic to increasingly sophisticated:

Don't micromanage

To reach maximum productivity, the Scrum team must be a self-managing entity. Put an experienced ScrumMaster and an experienced PO in place. After you've built the team, get out of their way. Don't let people and agendas outside of the Scrum team interfere with the Scrum process.

The Scrum process provides more than enough opportunities for change -- change from customers, from executives, from end users, and from everyone. The change is well-managed through the Scrum artifacts and events like the product road map, product backlog, and the sprint reviews. So don't let anyone micromanage the process or the team.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.2 (5 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up