vege - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Johanna Rothman rethinks what it means to be an Agile enterprise

Agile kind of has a bad rap and is also being eclipsed by DevOps. Consultant Johanna Rothman makes the case for why Agile needs a fresh start and how to get there.

The Agile enterprise has troubles that are well-told. The 16-year-old development approach is too focused on process. It's too formal. It's tough to make it work across time zones. It's taken a back seat to DevOps.

Johanna Rothman has a fresh take on what's wrong with the Agile enterprise. "People get stuck on what the name is," and that leads to some decidedly un-Agile ways of working, said the well-known Agile management consultant and author. "They use Agile words, but they don't use Agile approaches." They use a Kanban board, but their process is pure Waterfall. They say they're doing Scrum, but their iterations are a month long. The Agile enterprise opts for disciplined agile delivery or Scaled Agile Framework, even though the Agile frameworks aren't a good fit their process, she continued.

In short, the need to name things has given Agile a bad rap. Projects fail at the Agile enterprise not because they are Agile, but because they are not. "You need to work in a way that helps the team live the Agile mindset and values," Rothman said. That can take many forms, often without names. "The team uses a cadence of planning. They make their stories small. They do daily planning sessions at noon," she said. "It's an Agile approach, but it doesn't have a freaking name."

I asked Rothman, author of the upcoming book Create Your Successful Agile Project, what it means for a team to "live the Agile mindset and values" -- and what to make of the current emphasis on DevOps. Here's what she said that can help the Agile enterprise.

Making Agile agile again

Instead of finding a named process to focus on, Rothman zeroed in on approaches that help the team live out the Agile methodology. Successful teams work in an Agile way. Here's how she defined that.

  • Teams that work in an Agile way deliver value all the time. That means, among other things, that stories must be small. If they're too large to deliver results quickly, break them down into smaller, more manageable chunks. It sounds counterintuitive, but teams in an Agile enterprise that limit work in progress get more work done, Rothman said.
  • Agile teams are cross-functional. When problems arise, as they inevitably do, the whole team -- not an individual member -- devises a solution. For example, the team gets together to brainstorm its approach to automated acceptance tests, Rothman said. "The testers say, 'I wrote these automated tests. I found something else we need to pay attention to.' And the developers say, 'Yes, I found some stuff, too.'" That is an Agile approach to problem solving in a truly Agile enterprise, she said.
  • Agile teams seek early feedback and integrate what they learn into their work. "The faster we deliver value, the faster we get feedback," Rothman said. "Software is not a manufacturing process. We are not making widgets. It's a learning process." When teams work in an Agile way, they expect to make changes to work in progress. This way of working differs radically from a more rigid approach that aims to define all requirements upfront. "People who think we can define all requirements upfront are smoking something," Rothman said. "We learn about the product and process as we go."

DevOps is Agile

Agile's so-called "demise" comes at a time when even the Agile enterprise has turned its attention to DevOps. That has added to the perception that Agile is somehow obsolete. I asked Rothman for her take on this. "DevOps is an Agile approach. People don't understand this," she said. "DevOps brings the deployment people into the development team. That is where they should be."

Despite the attention it gets, DevOps as a practice remains in its early stages. "People are calling it DevOps, and what they are doing is helpful," Rothman said. "I do see tighter integration of deployment with the [development] team. I am excited about that." But most teams have taken only small steps toward deploying software at the push of a button. That's a step in the right direction, she said. "They're no longer running arcane scripts that only Joe in Florida understands."

So, that's Rothman's prescription for successful software projects in an Agile enterprise: Reinvigorate your practice by focusing on the Agile mindset and values, and begin to integrate deployment into your development process.

Next Steps

What Agile insiders are saying

Why Agile needs to take the next steps

Why Agile 2.0 might be BizDevOps

This was last published in November 2017

Dig Deeper on Agile DevOps

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you keep your Agile organization agile?
Cancel
I would suggest Scrum and DevOps together. Check out this white paper on the subject.
Cancel
IMO, Scrum is a big part of what ruined Agile. Its focus on process, without any mention of technical practices, coupled with the Scrum certifications, led to a large community of Scrum process coaches who don't know anything about building software.

Also, so many large organizations that wanted to adopt Agile thought that Agile is the same as Scrum, and so they brought in Scrum process coaches, and stood up Scrum teams, and then wondered why that did not work.

Scrum is a premature answer: Agile should start with a question: "How do we make our software solution process work better?" Even better, "How do we use technology to help business initiatives?" The premature introduction of Scrum kills the chance to ask those questions.

Scrum itself is ok: but its existence, and the certifications, which led to the Scrum process coach community, are a big part of what ruined Agile.
Cancel
One more thing that is important to consider: The Agile community, in love with Scrum and the Agile practices, really only understand Web app development. Those practices do not all apply well to, say, embedded software, or high reliability systems, or real time systems (which most mobile software is). So when you try to just insert Scrum even at a team level, in, say, an IoT company, it does not work well. That's why so much IoT software is riddled with security bugs, the the entire IoT industry is in jeopardy, because most of those products are not trustworthy.

When helping a team to introduce Agile, one really needs to start with what they are currently doing, and their constraints, and not blindly introduce Scrum.
Cancel
Agile is two different things: (1) a philosophy, defined well by the Agile Manifesto, and (2) a set of practices, including Scrum (defined roles, practices), team rooms, Kanban boards, stories, a style of group facilitation (including dot voting, and the "dumb" facilitator who never offers ideas), and many other things. These two ways of defining Agile have very little to do with each other. It is the second set of things that killed Agile.

The Agile community came to be dominated by process coaches, most of whom had never written software, and so it is no surprise that the highly important technical side of Agile fell by the wayside. That left an huge gap, and is what led to DevOps.

Also, the Agile community got stuck in its practices, enshrining them. Thus, to be Agile to _had_ to have a team room, and you _had_ to do standups, and you _had_ to have a dumb facilitator ("Scrum master) as your team lead - otherwise, you were not truly Agile. As a result, the Agile community failed to provide good answers for things like, "How do we include risk management?", and "How do we manage large programs?"

The Agile community killed itself: it is now irrelevant. DevOps is the new model: it puts the focus back on technology, where it belongs (we are building software and products), and it opens the door to larger ecosystem models such as SAFe, which provides much more scalable ideas for how to address things like large program coordination, portfolio balancing, and integration of specialists. Of course, the Agile community derided SAFe, because it dared to step outside of the Agile practice box; they can't deride DevOps because it has the credibility of addressing technology, it is was spawned by companies that know what they are doing - Netflix, Google, and so on.

But Johanna is right, that Agile, as defined by the Agile Manifesto - not the Agile community's enshrined practices - is still very relevant. As Dave Thomas has said many times, we need to go back to the Manifesto and throw out all those practices.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchHRSoftware

SearchHealthIT

DevOpsAgenda

Close