Last week, I had the opportunity to attend a Scrum Master training session facilitated by Mike Cohn. Because of this training, I gained insight into a number of practices that fuel our productivity at AVIO Consulting.  The following three gleanings are the ones that impacted me the most.   

Maybe You Can Win

We’ve all experienced a massive re-direction of team effort mid-sprint.  Let’s face it, it’s more normal than any of us would like to admit.  However, part of Agile methodology is being, well, agile.  

Unfortunately, sprints are time-boxed (it’s kind of endemic to the whole Scrum-Agile thing), so being flexible all the time doesn’t work.  How might a team meet the ever-changing needs of the client while keeping the development cycle under control and on schedule?   Scrum training offers some insight.

An example of traditional thinking might be best delineated in the illustration shown below.  If a product owner presents a new requirement and states that they want it “More better, more faster, and just plain more!” development teams typically parry with the qualigh-quantity-speed triangle (e.g. quality and speed of output [Agile-like], quality and quantity, or quantity and speed of output).  Asking the product owner to choose two of the three prompts higher-level thinking and lays the foundation for compromise, which is a good thing.  The problem with this approach, though, is that there’s no mechanism for estimating development time.  This has the potential to place a development team in a precarious situation.

Scrum approaches this problem by deferring to Agile in that quality and speed of output are more preferable attributes than simply producing a lot of stuff.  As for organizing a sprint, when a product owner shifts the team’s focus, story-point the new requirement and present it to the product owner in juxtaposition to the stories already contained in the current sprint.  Then, offer the product owner the choice of which stories they want in the sprint under the proviso that the team’s “Velocity Bucket” has a little room left over, but won’t hold everything.  Quality and speed of output never come into question, only the amount of work in a given timeframe does.  

Sometimes, it’s good for a product owner to be flexible, too.

The Line Between Academia and the Real World May Be Less Blurry Than You Think

Eager to prove my newly-acquired Scrum Master skills, I confidently waded into a discussion with two of my coworkers last week.  The topic was fairly innocuous, but some confusion was evident.  I shared an insight from Scrum Master training and was met with a puzzling response.  “That’s academic.  We’re talking about the real world.”  

While I admit no human-made methodology is without its gaps, no real-world scenario involving human beings is truly unsolvable, either.  The question is not whether the sometimes sticky and complex aspects of work life can fit into a rigid, academic framework devised by a marketing wizard in a far-away ivory tower.  It’s this: how can Scrum methodology flex to meet a dynamic environment?

While I prize the candid attitude of my coworkers, I would posit they haven’t given Scrum a fair shake.  The Agile Manifesto (of which Scrum is a part) makes no attempt to solve the world’s problems.  However, it does suggest that when one or more elements are in conflict, the elements in the blue rectangles (pictured left) should take priority over the elements on the right.  This doesn’t mean the elements on the right aren’t important, only that they are subordinated to the elements on the left.

No, Scrum isn’t attempting to promte an inflexible set of rules to govern all software development teams.  No, this will not always resolve conflict immediately; however, it will produce conversation.  Conversations can be mediated by the Scrum Master, allowing the human part of the equation to be validated.  From there, a resolution is attainable.  

That’s not academic, that’s Agile at work.

Scrum Doesn’t Solve Your Problems

Mike Cohn ended the first day of training with this quote:

“Scrum doesn’t solve your problems.  It reveals them so they can be solved.”

That’s a hard line to deliver halfway through a training, especially when the audience is expected to return the following morning!  Still, that’s the beauty of what’s at the core of Scrum. The Scrum Master is one who utilizes Scrum techniques within an Agile framework to (among other things) mediate disputes, coach team members, remove roadblocks, and ultimately facilitate team success.  

It’s far easier to walk away from conflict than it is to explore it with an open mind while devising an equitable solution for all. Scrum not only allows for this, I think it encourages it!  Note again that the Agile Manifesto (from which Scrum is derived) doesn’t supplant one set of values with another, it simply gives an edge to one side.  

Grey area is allowed to remain in Scrum because no one team, product, or development cycle will be exactly the same.  Scrum reveals problems so that they may be solved. 

Closing Questions:

• To what extent do you use Scrum in your workplace?
• How has Scrum benefited (or hindered) your organization?
• Why might Scrum training be (or not be) a future consideration for you or your organization?

Feel free to contact me with your replies.  Let’s keep the conversation going.  Until the next post, Mark Hearon out.