Scrum Lessons Learned – Part 1

If you’re using waterfall or some other non-agile methods, then transitioning to Agile principles and the Scrum process is a significant paradigm shift.  So it’s extremely likely that without professional Agile transformation guidance, you will encounter one or more of some common major Agile implementation mistakes.

In this article I’ll begin discussing some lessons learned through pain and triumph in the real world, and try to boil them down to some Do’s and Don’ts with some real world situations.

In this article I’ll start with:

• Don’t take shortcuts with Scrum

  Don’t mess with what works.
• Do support your Superheroes – ScrumMasters and Scrum Product Owners

  ScrumMasters and Scrum Product Owners are your leaders.  They need to be superheroes.
• Don’t micro manage

  The Scrum team needs to be a self managing entity to reach maximum productivity.

Don’t take shortcuts with Scrum

There are tremendous advantages to using a project management method as well known, as well established and as proven as Scrum.  So don’t mess with what works.

Thinking 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 much simpler than any breed of waterfall or project management method I’ve ever seen, and I’ve seen a bunch.  So don’t over complicate things with baggage from your past.  Let it go.  Leave it behind.  Because if you don’t, it WILL trip you up.

Another important thing to keep in mind is that if you stray from Scrum by adding your own bits, you’ll lose a major competitive advantage, that I covered in my Scrum as Competitive Advantage article.

Taking short cuts with Scrum principles and techniques and cherry picking parts of it to use will result in ScrumBut or Scrummerfall.  A highly compromised mess that is worse than a good waterfall process.

Here is a great definition of Scrummerfall and why you should not mess with Scrum, from Aaron Ericsson’s article Scrummerfall: World’s Worst Software Development Methodology.

“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 seen it over and 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 then the combined brain power, talent and expertise of the enormous world wide Scrum community.  And yes, you are not unique.  Not so much so that your process needs to be just your’s.  And that’s a good thing.  Because you can fully embrace a set of principles, processes and tools that have been proven to work for over a decade and there is a ton of expertise in the job market that can help you do it right.

Don’t let yourself get sucked into the “Not invented here” trap.  Standards of all kinds, technology and methodologies, 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 hundreds of thousands of other people.  So don’t make their mistakes.  Learn from their experience.  There’s a reason why Agile principles are so popular and 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 your organization’s culture, will make it easier – it won’t.  Natalie Warnert does a great job of summing up the reasons why you should not change 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 pain isn’t reason 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, likely very much more.  Cost you more money in more time to get things done, in failures that take too long to discover, in lost productivity and lost employees, in lower quality and more bugs that have to be fixed.

Do support your Superheroes – ScrumMasters and Scrum Product Owners

From an article on mobile app design that I wrote quite a while ago:

…”to create breakthroughs, you don’t need just great leaders and UX designers….  You need artists !!!  You need superheroes.”

ScrumMasters and Scrum Product Owners are your leaders.  And 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 dev, and other customer facing apps, one or both of them needs to also be able to provide the leadership and vision in UX design that these apps require, more than anything else.

ScrumMasters and Scrum Product Owners need the people leadership skills to bring together potentially competing interests.  For example, I did some work for a extremely large wireless cellular company, that everyone would know.  And being such a well known household brand, they had a long and deep relationship with a creative firm that developed their branding and advertising.  And our team brought the technology expertise.  Our common customer were business people.  Conflicts between tech versus creative is a fairly common issue in these types of situations and will certainly be in mobile and web apps.

In that project it fell to me to bridge the significant gaps between creative, technical and business worlds.  Language translation between the 3 worlds was a common need – translating jargon, requirements and intentions, handling diplomacy and negotiating common ground.

For background info see the following references that run from basic to more sophisticated:

• Description of Scrum roles in the The Scrum Team section of The Scrum Guide page at ScrumAlliance.
• Core Scrum Values at ScrumAlliance.
• Product Owner refined for enterprise scale at Scaled Agile Framework (SAFe).
• Check the book review article I wrote on 3 Agile Scrum Books You Must Own.
• The Scrum Guide at ScrumGuides.org by both creators of Scrum, Ken Schwaber and Jeff Sutherland.
• The Scrum Papers by one of the co-creators of Scrum, Jeff Sutherland, and other Scrum Resources at ScrumAlliance.

Don’t micro manage

The Scrum team needs to be a self managing entity to reach maximum productivity.  Put an experienced ScrumMaster and an experienced Scrum Product Owner in place.  Once 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, from everyone.  The change is very well managed through the Scrum artifacts and events like the Product Roadmap, Product Backlog and the Sprint Reviews.  So don’t let anyone micro manage the process or the team.