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 frequency?
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.

“People trump process, and politics trump people.“