February 28, 2012

On Not Being Scrum Enough

A few months back I had dinner with a group of product managers
returning from Scrum training. The team had been struggling to find the
right process for their organization, and hoped the additional training
might identify their internal deficiencies. One of the product managers
confided to me in his disappointment that the instructor’s general
answer was that they were not being “Scrum enough” – and that their
success required adhering to all the principles of Scrum, not just
picking and choosing the ones they wanted to adopt.

When I started my career in software, I had the opportunity to work
with a small team of talented engineers at a company called Easel, which
I captured in 8 Lessons From the First Scrum Team.
In those days, we didn’t have the ability to appreciate the
cross-functional collaboration of Scrum, the simplicity of Kanban, the
commitment to code quality of XP, or the risk management of Lean.
Instead we adhered to a much simpler philosophy: collaborate as a team
and aspire to build software better, faster and more predictably. Post
Easel I went on to ship over a dozen commercial software products for
multiple startups, gaining exposure to a variety of methodologies and
techniques on how best to build software. I came to realize my inherent
belief in one absolute rule for developing software: there is no one right way.

Today we practice our profession with decades of experience from a
myriad of innovation in software methodologies and techniques. We stand
on the mulch pile of Waterfall, Spiral Model, Unified Process, XP,
Scrum, Adaptive Software Development, Feature Driven Development,
Dynamic Systems Development, and more. So when we hear someone is not
being “Scrum enough”, we should remind ourselves that successful
software does not start with prescriptive process, but rather good
people and empowerment. Dogma is the luxury of consultants not burdened
by ship dates.

So before deciding on a process for your organization, take a moment
to listen to your team and learn how different techniques can be
harnessed to work best for your needs. Some areas to understand include:

  • Needs of business – What is the release frequency and pace of innovation required for success in your industry?
  • Needs of customers – What are your customers and potential customers
    expectations around the pace of innovation, quality and release
  • Maturity of team – Has your team had success or failure with
    previous methodologies? Are your engineers more or less experienced?
  • Size & location of team - Is this a small team in a single locale? Or a large team distributed across multiple locations?
  • Organization - What other organizational constraints do you need to
    consider in how your team builds software? The constraints of a high
    tech startup are very different from those of a large enterprise
    representing a multi-billion dollar brand.
  • Automation – What is the maturity of the investment in automation
    and continuous integration? What is the depth/breadth of test coverage
    in CI? Automation is the pivot point for agility in a software team.

So instead of repeating the dogma of prescriptive process, take a
lesson from Easel and listen, learn, and adapt to find the right
processes for your team. Good process is a journey that if executed well
should never arrive at its destination.

Joe Kinsella is the VP of Engineering at Sonian.  You can find this post, as well as additional content on his blog called High Tech in the Hub.  You can also follow Joe on Twitter (@joekinsella) by clicking here.