Tag Archives: Scrum

Right-sizing your agile process? Start in the Middle

Is your organization concerned with the cost and time required to adopt agile strategies?  Are you just starting out with agile and hoping to improve your chances of success by learning from the experiences of those who have gone before you?  Are you part way into your agile transformation but struggling to figure out how it all fits together?  If you answered yes to any of these questions please read on.

In this blog posting we discuss what it means to “right size” your software process to meet the needs of the unique situation that your team finds itself in.  We discuss two common anti-patterns: starting with a process framework that is much too large for your needs and starting with one that is far too small for your needs.  We argue that it’s much better to avoid these extremes and instead take a middle-ground approach by starting with a framework that is much closer to your actual needs.

Extreme #1: Large process repository

The first process right-sizing anti-pattern is to start with a large process repository, the classic example being IBM’s Rational Unified Process (RUP).  Although RUP is much maligned within the agile community the fact is that if you were to examine it with an open mind that there are many very good ideas promoted by RUP.  Be that as it may. The basic strategy with RUP is that you need to tailor down the process, often dramatically, to meet the unique needs of the situation your team finds itself in.  To do this requires significant process expertise, time, and money.
Right Sizing RUP
In practice, however, many organizations ran aground with RUP when they tailored it to be something similar to the waterfall-style processes from yesteryear that they were familiar with.  This is often referred to as RUPifall.  Another common mistake was to say to themselves “wow, there’s a lot of great ideas here, we need to do them all” and as a result they would create a process that was far too heavy to meet their needs.  In either case the problem was that they often didn’t have the process expertise required to right-size their process.  We also see this with organizations starting from frameworks such as ITIL, COBIT, and CMMI so this clearly isn’t just a RUP problem.

Extreme #2: Small methodology

At the other extreme is the right-sizing anti-pattern of starting with a small methodology, the classic example in this case being Scrum.  Although there is significant support for Scrum within the agile community, or at least among people who are new to agile, we’ve been seeing for a long time now that organizations are also running into trouble with this approach too.  With Scrum the idea is that you add in the techniques that Scrum doesn’t address to right-size your process.  Because Scrum proves to be only a very small part of the overall picture, to do this requires significant process expertise, time, and money.
Right Sizing Scrum
In practice organizations run aground with Scrum because they don’t have the process expertise to expand it to meet their needs.  One only has to count the number of “How does X fit into Scrum?” conversations occurring in agile discussion forums online, or at user group meetings or conferences, to see that this is true.  Step back for a moment and ask yourself how much time and effort has your organization invested in trying to adopt Scrum.  Could it not have been more streamlined?

A few years ago Forrester Research discovered that the majority of organizations “doing Scrum” had actually tailored it into what they called Water-Scrum-Fall (others call this Scrumifall).  As we describe in Going Beyond Scrum this occurs for several reasons.  First, Scrum doesn’t address the full delivery lifecycle, instead choosing to focus on the construction portion of it.  As a result organizations tend to stick with what they know, a heavy project initiation phase and a heavy solution deployment phase.  Second, Scrum only addresses only a small portion of what you need and explicitly leaves technical issues up to you.  These issues include topics such testing, programming, architecture, governance, documentation, deployment and many others.  As a result teams are left to piece together a process strategy that works for them, at the very same time that they’re struggling to understand the fundamentals of agile and lean software development.  They rarely have the process expertise to do that and as a result end up having to hire hordes of expensive Scrum coaches, few of whom seem to understand the enterprise-class realities that your teams actually face.  This is a risky and expensive proposition indeed.

The Effective Middle Ground

Both of these anti-patterns represent extremes: start with something large and cut it down to size, or start with something small and build it up to meet your needs.  Why not start with something much closer to what you actually need?  Doesn’t that make a lot more sense?  Why do you need to do all this process work?  Because someone wants to sell you tooling?  Because someone else wants to sell you expensive coaching and questionable certification strategies?  Isn’t it time to consider a more pragmatic strategy?

The Disciplined Agile Delivery (DAD) framework is a more effective middle ground.  It addresses the full delivery lifecycle, as does RUP (but not Scrum), and even gives you several choices from which to select.  Sometimes a Scrum-based lifecycle is appropriate, sometimes a Lean lifecycle is, other times a continuous delivery lifecycle is best, and sometimes an exploratory “lean start up” lifecycle is.  Different teams, different situations.  DAD starts with a lightweight approach, as does Scrum but not RUP, helping you to avoid the bloatware of RUP and filling in the numerous blanks left by Scrum.  DAD also gives you lightweight tailoring advice in the form of process goal diagrams, in many ways a cross between mind-maps and decision trees, that make your process choices explicit.  The RUP process tailoring advice, if you bother to read it at all, is rather heavy handed and the Scrum tailoring advice boils down to “you’re smart, you can figure it out and if your run into trouble hire a coach.”  Isn’t it time to abandon the extremes?

Right Sizing Disciplined Agile Delivery
This middle ground strategy isn’t without its faults.  A challenge with DAD is that it explicitly reveals that agile software development, or as we prefer to say agile solution delivery, is complex.  This is particularly true in enterprise-class situations where teams are often facing combinations of scaling factors such as larger team size, geographic distribution, and regulatory constraints.  DAD makes it explicit that teams need to invest a bit of time up front to perform initial scoping, initial architectural modeling, and initial planning (all in a lightweight manner of course).  This sort of pragmatic thinking can be inconvenient for less-experienced developers who just want to jump in and start coding.  Because DAD promotes the philosophy of enterprise awareness it purposely bakes in strategies for governance, DevOps, and working with IT-level groups such as your enterprise architects and data management team to name a few.  This can also prove to be inconvenient for developers who want to narrowly focus on doing what’s convenient for their team as opposed to what’s best for their organization.

In Summary

The following infographic summarizes the main points in this blog posting.
Right Sizing Your Agile Process
We hope that you’ve found this blog posting enlightening.  Even if you are well along the way of your Scrum adoption, or of evolving your RUP-based approach, you can still benefit from switching over to DAD.  Scrum teams will find that it addresses many of the issues that you’re still struggling with, and RUP teams will find that it shows how to work in a far more lightweight manner.  Organizations will find that it provides a much better foundation from which to scale agile strategies.

Successful Agile Software Development Requires a Hybrid Approach

Hybrid

Disciplined Agile Delivery (DAD) is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks.  The DAD framework adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

The DAD framework adopts strategies from the following sources:

  • Scrum.  The Scrum method focuses on team leadership and requirements change management during the construction portion of the delivery lifecycle.  Scrum captures some really great ideas that have become commonly adopted by agile teams.
  • Extreme Programming (XP). XP is an agile method that focuses primarily on construction-oriented practices such as continuous integration (CI), test-driven development (TDD), pair programming, sustainable pace, small releases, simple design, and many others.  Although XP’s practices appear straightforward on the surface, many of them require significant technical skill and discipline on the part of practitioners.
  • Lean software development.  Practitioners of agile development are increasing looking to adapt ideas from lean thinking.  Lean software development is based on seven principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.
  • Kanban.  Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is visualized and team members pull work from a queue or work item pool.
  • Unified Process (UP).  The UP is an iterative and incremental process framework for software development.  Although often instantiated as a heavy-weight approach, it has in fact been instantiated in a very light weight and agile manner, particularly in the form of Agile Unified Process (AUP) or OpenUP.  The DAD framework adopts and enhances several critical governance strategies from the UP.
  • Agile Modeling (AM).  AM is a practice-based methodology for effective modeling and documentation of software-based system. AM was purposely architected to be a source of strategies which can be tailored into other base processes, something the DAD framework takes explicit advantage of.   AM strategies adopted by DAD include initial requirements and architecture envisioning, just in time (JIT) model storming, continuous documentation, and several others.
  • Agile Data.  The Agile Data (AD) method defines a collection of strategies that IT professionals can apply in a wide variety of situations to work together effectively on the data aspects of software systems. Practices for evolutionary/agile database development include database refactoring, database regression testing, agile data modeling, and continuous database integration.
  • Enterprise methods. DAD is starting to adopt strategies from enterprise IT methods such as Scaled Agile Framework (SAFe) and Enterprise Unified Process (EUP).  These strategies address enterprise architecture, product management, portfolio management, operations and support, release management and other important IT disciplines. These strategies reflect the DAD philosophy of enterprise awareness.
  • Other methods.  DAD adopts techniques and practices from other methods such as Dynamic System Development Method (DSDM), Feature Driven Development (FDD), Evo, Outside-In Development (OID), and Crystal Clear.
  • Agile development practices.  There are many practices that are not specific to agile methods that have been developed within the agile community, and DAD leverages many of them.

One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you.  This is also one of its greatest challenges because without something like the DAD framework it’s difficult to know what to choose and how to fit them together.

Whitepaper: Going Beyond Scrum

Going Beyond Scrum

This paper describes, step-by-step, how to evolve from today’s Scrum vision of agile software development to a disciplined agile solution delivery.  It begins with a brief overview of the agile software development movement and its implications.  We then overview the Scrum method with its associated benefits and drawbacks, and then how to move beyond Scrum to a full delivery process framework called Disciplined Agile Delivery (DAD).  DAD is a governed, hybrid approach that provides a solid foundation from which to scale agile solution delivery within enterprise-class organizations.    The steps to do this are:

  1. Focus on consumable solutions, not just potentially shippable software
  2. Extend Scrum’s construction lifecycle to address the full delivery lifecycle
  3. Move beyond method branding
  4. Adopt explicit governance strategies
  5. Take a goal-based approach to enable tailoring and scaling

You can download the paper here.