Some Agile software developers say that a predefined development process like Scaled Agile Framework (SAFe) is a departure from, not an extension of, the Agile methodology. Agile, they say, is about adapting to change and letting processes emerge. That approach can work well in small Agile projects, said Agile consultant and practitioner Mike Bonamassa. When he has done large development projects, practicing the Agile methodology without structure hasn't worked well.
Bonamassa, president of Blue Agility Consulting, has many experiences with the Agile methodology and has overcome challenges when using it in large enterprise-software projects. He provides tips and advice on Agile's uses and values, as well as those of SAFe, a structured development format that defines roles, team creation and process, and best practices for enterprise Agile projects. Dean Leffingwell, an Agile consultant and author, created SAFe.
What was one of your first large Agile projects?
Mike Bonamassa: Back in 2005, a large program at Freddie Mac was failing. We started working with them and implemented Agile practices, like the daily stand-up?, time boxing, test-driven development, continuous integration and so on. We saw the benefits of nightly builds and having everyone working constantly on producing high-quality software on a predictable basis.
What is different about how you practice Agile today versus in 2005?
The community needs to separate Agile into small Agile and scaled or large Agile.
Bonamassa: We're focusing on scaling Agile up today, so that enterprises can move the big rocks that are in front of their application projects.
Right now, more Agile modification is happening than in the past, probably because the community and the scope of projects has expanded. People know that some key Agile practices work, such as self-organizing teams and empowerment. Then they have to scale Agile up inside a large enterprise, and it becomes difficult to support self-organizing teams. In that setting, people who are knowledgeable about Agile have to work with infrastructure teams who aren't. There is a skills, cultural and language barrier. In this setting, there's a need for well-defined transition points into other, non-Agile parts of the organization. The result is that Agile has to become more formal, with more predefined practices.
How have you seen Agile evolve since the Agile Manifesto was written in 2001?
Bonamassa: Agile has changed quite a bit since the manifesto came out. There continues to be a very vocal core that believes that Agile is the combination of the Agile Manifesto and Scrum; but others are quietly creating Agile blends. For example, we're starting to see more extreme programming (XP) practices being added, like test-driven development and paired programming. Those practices aren't really Agile per se, as they came out of XP; but XP has failed to catch on, probably because of the name. People tend to avoid 'extreme' practices in business.
Could you elaborate on your work with scaling Agile development using the SAFe framework?
Bonamassa: I think the community needs to separate Agile into, say, small Agile and scaled or large Agile. They are two very different things. In Agile on the small side, developers can just go along with the manifesto tenets, such as focusing more on working software than documentation.
More info on scaling Agile development
Blue Agility specializes in large-scale Agile deployments
Read more about Dean Leffingwell, SAFe creator
Learn more about scaling Agile requirements to enterprise level
Go in depth on SAFe
The challenge really comes in when you try to scale that up to a large organization, which requires a more prescriptive approach. When trying to get several hundred people working together and delivering value every two weeks, you have to put aside some small-Agile practices. It takes too long to set up, train and manage a large self-organizing team, for example. That process would entail so much churn and time that, somewhere along the line, the organization will lose faith in your ability do it.
So, why not start out with a program that prescribes the process? This is where the Scaled Agile Framework is valuable. The SAFe approach is doing Agile as a predefined instance.
How does SAFe help with development problems common to large projects?
Bonamassa: One of the problems with Agile is that the development team only has to commit to a backlog that looks two weeks out. How does the executive, the product owner, know when the whole project is going to be done? Knowing if a part of the product is done and when the whole project will be done is a big problem.
SAFe has an intermediate layer that can help with project roadmaps. It has the epics, which drive the overall value themes for the portfolio of investments that you're making. It has the stories down at the bottom, which are the fuel for the backlog to deliver functionality on the sprint. In the middle, there are features allocated into potentially shippable increments of every four-to-five sprints. The result is a roadmap of where the project will be every 10 to 12 weeks.
What is the key value of being able to roadmap a project?
Bonamassa: Having some ability to have a roadmap, even a partially committed one, can give an executive the confidence to put millions of dollars behind the project. That's what a more prescriptive approach, like SAFe, provides. This is more appealing to executives than the typical external Scrums, because external Scrums imply when functions are going to have this done but don't imply commitment. Scrum says, 'We're working on user stories related to a function, but those are the only things we're committing to now.' Who can expect an executive to put millions of dollars into a project without some commitments? I think that's the biggest issue in the large project market right now.
Does your organization use SAFe or some other approach to scaling Agile? With what results? The best response received by December 31, 2013 (email: editor@SearchSoftwareQuality.com) gets a free copy of Discover to Deliver: Agile Product Planning and Analysis by Ellen Gottesdiener and Mary Gorman.
This was first published in December 2013