Beware the Temptation of "Dark Scrum"

Avoid the temptations of "Dark Scrum"

I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum since 2013.  I even finished up my master’s degree studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is a 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, it is your duty to avoid this situation.  This week on the blog 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 on to 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 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 the social compact of agile, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked bad.

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, did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, and it would take over 24 hours to get them answered.  Product owners also complained that the team was not understanding the detailed requirements to get the work done.  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 provides 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 not secrets for all the parties involved.

We solved the next pathology by moving up the stand-up meeting by thirty minutes.  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 got better as product owners relied on the offshore QA professionals to streamline acceptance testing.  What was once a burden, became a win-win for the entire team.

The hard part about being a scrum master and agile coach is you are forced to come up with 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.  It is why the agile reformation is so important.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.