Are you transforming the world of work or confusing it?


Are you transforming the world of work or confusing it?  At a recent event, Scrum enthusiasts from around the world met to share ideas to achieve the Scrum Alliance vision of “Transforming the World of Work”.

With 700+ attending, many great ideas and success stories were shared.  Some same old Scrum and Agile dysfunctions were also shared.  Angela Johnson, Certified Scrum Trainer was concerned by the number of people calling themselves trainers and coaches who continue to perpetuate “bad Scrum” using constructs that do not exist in the framework.

Scrum is simple…but it is not easy.  This is because it means changing the way we do work.  And change is hard.  Old habits die hard and it’s a Coaches job to remind people why they wanted to change in the first place.

Many cite “speed to market” as the reason they want to adopt Agile or Scrum.  The sad reality for these organizations is they are not delivery anything of value faster than the old way of working because they truly have not transformed the way work is done.  In many cases, they are practicing traditional System Development Life Cycle (SDLC) or Waterfall approaches but have now placed Agile or Scrum vocabulary on top of this.  Then they say things like “Agile does not work” or “Scrum does not work” when they are behaving pretty far from anything “Agile-like” or “Scrum-like”.

The top 2 “trainer” and “coach” abuses recently experienced include:

  • Perpetuating the Myth of Sprint 0
  • Enabling Process over People through User Story Abuse

Dysfunction #1:  Sprint 0.  The Scrum Guide (scrumguides.org) defines a Sprint as:  the heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product increment is created.

When I ask trainers, coaches, clients, team members, etc. who have fallen into the Sprint 0 trap what their “so called Sprint 0” produces, answers range from design documents to architecture plans to requirements, etc.  No value has been created.  The reality is, that in these situations, work was performed in the same, old way.  The Product Owner in these situations, has largely not done their job.  Work is approached from “the system’s” point of view and not from the User’s perspective.  As one of Collaborative Leadership Team’s customers who did transform the way they do work so eloquently puts it “They must call it Sprint 0 because it delivers ZERO value”!

Solution:  Start thinking in vertical slices – not horizontal ones.  Think from the customer or users point of view – as every single Agile approach requires.  What can be simply delivered to realize the customer need?  We can evolve the product based on feedback from there.  Any technical needs are just tasks – work we have to do within the Sprint (timebox) to deliver this value.

Dysfunction #2:  User Story Abuse.  The Agile Manifesto (agilemanifesto.org) asks us to value “Individuals and Interactions over Processes and Tools”.  This means that we have traditional discouraged interaction by passing off documents to one another and assuming that all is understood, or agreed to.  The people who created Scrum, and subsequently Agile, wanted us to try something different.  That means NOT starting with a document.  But rather, starting with a conversation.  Scrum has us put a placeholder for the conversation, or the outcome of conversations held on an ordered list called a Product Backlog.  Let’s have the real human user just tell us a story.  Tell us who they are, what they want, why they want it.  A “cheat sheet” was created in eXtreme Programming, one of the Agile approaches, to get that conversation started.  Sadly, many are simply falling back into old habits of negating or replacing the conversation with a document.  Only now they have started the document with the User Story template of who, what and why.  The people who have to build the product are left with just as many questions as they had in the waterfall world because they have not been a part of the conversation.  Some intermediary has been asked to create this “user story document” rather than the real user telling their own story – which is what was intended.  In one case, there are people who are operating as traditional business analysts but the organization is referring to them as story authors.  What?!  They aren’t delivering value any faster than they were before they decided to “go Agile” and they are confusing people with a role not defined in any of the Agile approaches.

Solution:  Step away from the keyboard.  Engage with the real customer.  The real user.  Watch them do the job or perform the work.  Ask questions.  Have great conversations. Ask them what “done” looks like to them.  Write down the results of the conversation as necessary but don’t start with the document.  Start by talking to each other.

The solution:  start thinking in vertical slices – not horizontal ones.  Think from the customer or users point of view – as every single Agile approach requires.  What can be simply be delivered to realize the customer need?  We can evolve the product based on feedback from there.  Any technical needs are just tasks – work we have to do within the Sprint (timebox) to deliver this value.

Want to learn how to Transform the World of World and stop Confusing It?  Join us for our next Certified ScrumMaster course by checking out our upcoming courses.