Agile for everyone. Yes, it can be done. As the Agile Manifesto methodology matures, the values it offers engineering teams remain, but its principles, including continuous and frequent delivery, harnessing change for mission delivery, efficient multi-team collaboration—and the resulting benefits of faster prioritization and production—have many program offices stymied about adapting Agile to their ways of working.
Like any professional process, Agile requires learning some new skills to gain the promised benefits. You can’t have engineers working Agile while the program office and project teams, and others responsible for overseeing planning and execution, are left behind.
Most often, Agile has only been embraced by the development team and the challenge is addressing how the rest of the organization will adapt to the new process.
We often hear questions like:
- What are we really building? What happens to the requirements?
- How do we keep everyone in the loop when we’re not in the same office for daily standup meetings?
- How do we control scope and manage change?
- How do we know what the development team will deliver at the end of the sprint?
This white paper addresses five of the major challenges that we’ve seen lead to Agile failure, as well as solutions to make Agile hum for your organization. We’ll use “Agile” as an umbrella term to represent all forms of iterative development whether it is SCRUM, SAFe, Lean Software Development or others. We also won’t get into the specific tactical challenges of running “retrospectives,” writing good “user stories,” or “grooming backlogs,” but we will target some of the root cause challenges with suggestions on how to be successful.
Let’s Start an Agile Team
To set the stage, let’s visualize an Agile team getting started. Your team has heard all about Agile and wants to gain from its benefits—faster turnaround of incremental features to the end user, more customer involvement, and reduced development costs. You, as the Agile evangelist, have been selected to lead this effort.
You also have a new project just getting started. The project is going to be a new office monitoring system that will cut down electric usage in the average office by 93%. You picture building your Agile development process and sharing your success with the rest of the agency until everyone is bathing in Agile goodness. We’ll further assume that your team is already using a collaborative requirements management tool and is skilled at writing good user stories and use cases, creating test cases, tracking bugs and all the other fundamentals of good development.
Now let’s look at the challenges and review them in about the same order as you, your team and those interacting with them might experience them. At the end, we’ll come back to our office monitoring system example and the possible results based on whether we were able to overcome these challenges.
Challenge One: Aligning Vision with Iterations
An early challenge you’ll experience is that an Agile team will want to self-organize and start writing code now… fast. They’ll want to define user stories, tasks and test cases “just enough” to create the first software iteration–a sprint in Agile terms– and deliver working code.
The Product Owner (which we’ll discuss next) might state, “We know that our customer (the agency) will want to monitor every outlet, appliance and computer in the office; let’s start with building a database schema that allows the agency’s facilities team to enter a list of these.”
While this is not inherently bad, getting started too quickly can be wasteful and set your team up for quick frustration, creating immediate conflict with other ideas about the major system attributes and how to get started on the
right path. Management, and even some internal technical leaders such as architects and product managers, will scream, “Wait! What are you building?” At which point the Agile development team might respond, “We’re just getting started… we’ll refine it along the way.” Unfortunately, this is little comfort for those that must communicate value models, release plans, project scope, schedules, business rules and resource plans.
Even the worst car drivers will have a general understanding of where they are going before making their first turn out of the driveway. There must be sufficient time and energy spent up front to gain a solid grounding in the product vision before distilling it into “just enough” requirements to provide direction.
Creating a vision, documenting a product plan and prioritizing use cases doesn’t need to take the months that a waterfall approach might take, but certainly several weeks of thoughtful customer interaction, preliminary designs and analysis is required before getting started.
The development team should participate of course in thinking about architecture, performance needs, user experience, platform needs, etc. However, even this frontend vision planning can apply Agile approaches using epics, fast prototyping (without writing code) and immediate customer feedback cycles to get clear, early guidance to kick off a new project. Documentation of this vision and clarity on your big picture roadmap will satisfy requirements for program deliverables during the early stages.
Want to read more?