Scrum Is the Means, Not the End

Here at Applied information Sciences, we use Yammer quite a bit to facilitate quick, transparent and open communication. For such a distributed team of smart individuals, it’s an invaluable tool to building camaraderie and cohesiveness. Yammer allows us to discuss hot industry technologies and opens the channel to shared experiences and knowledge.

I recently used Yammer to conduct a poll here at AIS:

This question comes from the Scrum.org Open Assessment, a quick 30-question assessment provided by Scrum.org. The objective is to make available a quick gauge of Scrum knowledge. With personal results in hand, the Scrum Guide becomes a more valuable reference.

In the Scrum Guide you will find descriptions of Scrum events, roles, and artifacts. What you will not find is Scrum described as an Agile methodology or a project management process.

“We’re Agile, We Do Scrum”

I hear the statement “We’re Agile” bandied about as frequently as SOA, REST, and the Cloud. It seems to be a conversational prerequisite. The question I often ask is, how so? What about Scrum has made you Agile? More often than not I’m quite disappointed to hear examples of Scrum events and procedural edicts put in place to mimic the hype.

With all the marketing, evangelism, products and rhetoric, it’s important to recall the simple statements that started the Agile movement (now in its second decade):

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

 

Individuals & interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Even with the 12 principles behind the Agile Manifesto, these value statements can be printed on a single 8.5×11 piece of paper. Impressive that such a simple thing could drive multinational conglomerates to move mountains (and millions) in a quest to achieve this state of being.

So if Agile is not a set of guidelines or activities and Scrum is not a methodology…what is everyone so excited about? What is Scrum?!

Scrum Is the Means, Not the End

Scrum is intended to be “full of holes,” so to speak. It does not provide definitive answers to the tricky situations your team and organization will and do face. While every team encounters similar situations and can learn from one another, few practices can be taken as gospel.

Rather than patronize the world with a shallow, vague one-size-fits-all answer to complex situations, Scrum provides a simple framework composed of tight feedback loops in which intelligent teams can discover the most appropriate process for their context.

Scrum is meant to embed a long-term, sustainable learning mechanism into your organization.

Standing on the legs of transparency, inspection and adaptation, Scrum is meant to embed a long-term, sustainable learning mechanism into your teams. Scrum asks that your team deliver “done” Software in 30 Days or less — a Sprint — and repeat the pattern until sufficient value is no longer being accrued. In doing so, a team can discover the true cost of simultaneously maintaining a backlog of features, delivering working software, and experimenting with the delivery process.

Scrum will help you create a momentum of delivery. Scrum is a framework within which you can achieve an Agile state of being.

Scrum at AIS

While the poll question may be a bit leading, I was incredibly happy to see that the results of the Yammer poll shows 91% of our team recognizes Scrum as a framework within which they can solve complex problems in smart, creative ways.  Something that our clients have come to expect from AIS.

About Ryan Cromwell

Ryan Cromwell is a coder by trade with over 10 years of experience delivering solutions ranging from real-time customer loyalty systems and elegant user experiences to streamlined statistical process control software. Having worked with passionate, high-performing Agile teams, Ryan ventured into the world of Scrum.org training and Agile coaching to replicate those amazing experiences. Ryan is co-founder of the Cincy & Dayton Clean Coders user groups, co-organizer of Southwest Ohio GiveCamp, and all around software community ally. Ryan has led presentations on effective team development, and various topics such as Agile, Scrum, Software Craftsmanship, WPF, Single Page Applications, Software Patterns and more. You can also find Ryan at http://cromwellhaus.com and on Twitter as @cromwellryan.

  • Scrum is not THE means, some might argue it’s not even A means. And, of course, being Agile is not the end, either.

    – Bob

    • cromwellryan

      Thanks for commenting Bob.  Can you give some background or elaborate a little more?

  • NateSoutherland

    Hmm…frankly, I’m not happy with any of the available options in the poll question.

    My Agile journey started in the XP camp, and for a while I was fairly dogmatic about my favorite methodology. When I heard about Scrum all I could see were those glaring holes to which you referred. Fortunately, I’ve matured a bit since then.

    To some extent I agree with Bob (although I’m not sure if we’re agreeing for the same reasons), neither Scrum, nor Agile are the end. I think the Agile Alliance signatories would all agree that working software – more specifically high-quality, functional software that satisfies the users’ needs – is the end.

    The question then becomes, “What is the best way to acheive our end?” Of all the various approaches to answering that question, I am convinced that the Agile family of approaches provide the philosophies, principles, and practices (3Ps) that ultimately provide the best – not the perfect – answer.

    My approach to agility and software delivery has become much more flexible as I have been exposed to more varieties of projects, customized to meet the specific needs of the customer, yet all of my methodologies remain founded on the Agile 3Ps as a bedrock layer that provide stability and strength to both the process and the end product. Scrum may be a large part of a customized methodology, but so might Lean and Kanban, XP, or some other hybrid. 

    • cromwellryan

      Do you think there is *an answer* Nate?  I’m not convinced there is for all teams, let alone organizations or industries.  I do think Scrum provides a good framework the industry to improve beyond it’s current situation.  The Scrum Guide continues to remove rules (like burndowns, etc), because they are no longer needed.  Ken is on record as saying he’d like Scrum to be unnecessary – that we’ll be a proper profession were high-quality, functional software that satisfies the users’ needs is the rule, not the exception.  

      I agree in thinking lean, kanban and future topics play an important role in keeping the focus on getting better.  I’m a little worried that those two put too much of the focus on cheaper, faster output than balancing clean, creative problems with sufficient feedback loops.  Then again, velocity did that too us already.

      • In short, no. I think we are hamstrung by our tendencies to look for a single, universal solution.

        We’re dealing with natural human tendencies – finding the shortcuts and the most efficient ways to accomplish a task. And perhaps more importantly we’re dealing with the need to answer the professional and existential question, “What do I do now?” Ultimately though, I think that desire to have a one-size-fits-all (or even fits-most) methodology is the root of the dogma and disillusionment that is pervasive in communities that spring up around methodologies. That dogma distracts us from meeting the needs of the moment with the best tools of the moment.

        In an environment where projects can be wildly different – in domain, in delivery platform, in team size, in business scope, in practically every other meaningful factor – how can we possibly expect a single methodology or methodology framework to do it all?