Beware the temptation of 'Dark Scrum'

I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum in 2013.  I even finished my master’s degree by studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is the disconnect between those of us doing the work and the business people who depend on us.  When this happens, it creates a situation Ron Jeffries calls “Dark Scrum.”  As a scrum master and agile coach, you must avoid this situation.  This week on the blog, we are avoiding the temptations of “dark scrum.”

In my formulation, "dark scrum" is when the business users of Scrum use the methodology to enforce control over software development rather than use it to improve quality and customer satisfaction.  Jefferies gives plenty of good examples on his blog, but I would like to provide two more.  I consider them to be pathologies of a dysfunctional organization.

Dark scrum pathology – shoehorning arbitrary deadlines onto sprints.  

One afternoon, I was in the office of a Vice President.  I had been raising concerns with him that a project was going poorly and that I would need his support and intervention.  The meeting did not go well.

“I promised the board that this project would be done by X date,” he said.

I told him that based on the stories we had and a three-week sprint cadence, we could deliver by a later date.

“You are agile; figure it out,” the VP said, “I need it by X date.”

The executive violated Agile's social compact, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked terrible.

Dark scrum pathology – why do I have to meet with the off-shore team?

Product owners write stories, but because of the time difference between the onshore and offshore components of the project, they did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, which would take over 24 hours to answer.  Product owners also complained that the team did not understand the detailed requirements to complete the work.  When prodded to attend the stand-up call with the off-shore team, a product owner indignantly said, “I am not waking up that early to talk with India!”

We were able to correct these pathologies.

To address the arbitrary deadline problem, bring in executives and product owners to level set expectations.  In the world of Scrum, the product owner is the person primarily responsible for the success or failure of a project.  The executives outside the team are responsible for funding and helping to remove organizational obstacles.  Knowing financing and deadline commitments gives the product owner a framework to write stories.  The scrum master can then use team velocity and the sprint cadence to let everyone know when a deadline is realistic and when it is not.  This way, the social compact of agile is respected, and there are no secrets for all the parties involved.

We solved the following pathology by moving up the thirty-minute stand-up meeting.  The product owner could take the call from home when they got out of bed but before they came into the office.  Product owners answered questions quickly, and user stories improved.  Also, automated testing improved as product owners relied on offshore QA professionals to streamline acceptance testing.  What was once a burden became a win-win for the entire team.

Final thoughts -

The hard part about being a scrum master and agile coach is you must devise solutions like this each day to prevent your organization from falling into “dark scrum.”  Any situation where those in power ignore the input of the people doing the work is going to add darkness to the organization. This is why the agile reformation is so essential.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.