5 guidelines for adopting agile at scale

Twenty years after agile methodology emerged, there's still a lot of uncertainty about what agile is (and isn't), even as agile adoption continues rising. Therefore, I decided to take this agile discovery tour to help solution architects, automation consultants, cloud architects, engineering architects, and other technologists understand what agile is and is not.

The agile way

Briefly, agile is a set of software development principles that improves software by using continuous iterations. Several frameworks fulfill the Agile Manifesto, including scrum, kanban, and extreme programming.

The Agile Manifesto includes four values backed by 12 principles. The four values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Scrum encompasses five values and three pillars:

• Scrum's five values:
  • Courage
  • Commitment
  • Focus
  • Openness
  • Respect
• Scrum's three pillars:
  • Transparency
  • Inspection
  • Adaptation

As I mentioned, there's a lot of confusion about what it means to "be agile," which you can see in the following scenario.

Meet the Regulators

The Regulators are a fictitious team of young developers. They've never practiced scrum or agile but were asked to become a scrum team and mobilize. The team consists of:

• Four developers
• A quality assurance and business analysis (QA/BA) person
• Two product owners (who aren't truly product owners)
• An experienced senior agile coach

The organization is pretty new in its agile transformation. There is no real top-down buy-in of agile, and no leadership personnel received any formal agile training. The Regulators' only so-called "training" was a one-day offsite Jira workshop.

[ The role of an IT architect is drastically shifting with the times. Learn more about the role of an agile architect. ]

The Regulators began with a five-day mobilization carried out by the senior agile coach. They received some minor agile and scrum lessons along the way during their training. Although it wasn't deep enough for a brand-new scrum/agile team, the team managed to complete a Sprint 0, where (with the agile coach's help) they ordered a backlog and completed sprint planning to choose the Sprint 1 backlog items (SB1s).

The team came away from the mobilization with:

• Definition of done
• Definition of ready
• Scrum ceremony schedule
• Sprint duration
• Release cadence
• Risk data
• And other norms

The week after mobilization, the Regulators kicked off Sprint 1, and they were on their way to being agile. Or were they? Would they survive under the existing organizational fixed-mindset constructs?

The state of agile

Some organizations are going through large-scale agile transformations—trying to slap the scrum framework or other agile methodologies on top of deep-rooted cultural issues, and they are (more often than not) not getting anywhere. Some hire expensive agile consultants to "ensure" they can drive the efforts without participation from the top or additional education and training. Once the money runs out, the consultants go away, and the organization and its employees, stakeholders, and customers are no better off. It's frustrating seeing this play out over and over again. It seems like a big money grab, where big-box consulting firms slap a bunch of consultants and others into place and clear their bench. They don't do anything, and it just makes things more difficult.

[ Effective digital transformation requires innovation at the level of architecture, so learn how an open approach to digital transformation can help. ]

Working in new ways

How can companies skip all the turmoil with hiring these big-box consultancy firms and get to working in new ways? The first thing is to recognize that agile is an art and not a science. Agile is about people, and there is no science to working with people. It's all about living in the moment, understanding what's going on, reacting (and of course failing) but learning quickly, and then adjusting.

It's about how the teams and organizations build things to make their customers feel happy. It's about bringing a smile to your customers' faces because you changed their lives. Organizations and teams need to carry the customer with them every step of the way.

Forgetting where agile came from

Have teams lost their way? Have teams forgotten when and how agile was born? Agile did not start with scrum or kanban, but with something called Extreme programming (XP). XP, during its inception, took the best practices and just cranked it up as high as it could go. XP had a practice called customer in the room, where every team had a customer literally in the room that told them if they were going in the right direction.

[ Agile is but one of 5 ways to accelerate enterprise architecture implementation. ]

Do not forget the way it was. Remember where agile came from. You need to resurrect the whole idea of what agile was initially about. Agile is not about delivering more stuff faster. It's about delivering less but delivering what matters. It's about focusing on value. It's about iterating quickly. So next, I'll show you how I turn agile up to 11.

How to become agile

Most agile methodologies include five steps:

1. Define
2. Design
3. Build
4. Test
5. Release

That's well and good, but I'll offer five guidelines that your team or organization can use to start doing agile as it was initially intended. Overall, recognize that agile is a mindset. It really is about being agile as opposed to doing agile.

1. Agile is not limited to software, and it doesn't mean it has to be scaled at every level. Scaling has been taken out of context. Should you even be adopting agile? How tightly coupled are your architectures? Are they so coupled that no matter what framework, methodology, or practice you put into place, you cannot be successful? Your solutions' architecture may pull you back to pre-agile times. If you have a monolithic architecture, you will get pulled back to a monolithic, waterfall way of working.
2. There should be early discussions at every level regarding the why of agile transformation: Why the company is moving in this direction, and why it is better for everyone concerned? To figure this out, host agile dojos of sorts or agile hackathons. Get leadership involved at the very beginning, and ensure they have proper, formal agile training.
3. Break things down into small pieces—both your architecture and your teams.
4. Have an informal agile transformation complaint session to let everyone get out their feelings (good, bad, or indifferent) about the impending changes to the organization and its teams.
5. Don't forget the customer in the room. Every decision you make should include the customer. It's not about what you think is valuable to them. It's what they tell you is valuable to them.

Beware of big splashes that drown the entire organization

It's best if you don't look at agile as a large, monstrous endeavor. It helps if you approach agile with caution in a way that starts where you are—starting small and moving incrementally. Attempting to make a huge splash could end up drowning the entire organization.

[ Enage in digital transformation the open source way. ]

Determine where you are and, if you have huge monolithic architectures, determine how you can break them down into smaller pieces. If you have monolithic teams, break them down, turn them into squads of teams, and then talk about how you amplify your effectiveness.

According to Wikipedia, Conway's Law says:

"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."

Or, as technology writer Dan Woods wrote in How platforms are neutralizing Conway's Law:

"Essentially, what that means for the tech world is that the software produced by a team or organization and the underlying code used to create it will resemble the communication and organizational structure of the group or company that produced it."

The smaller the team, with less dysfunction and more cohesion, the greater these teams perform. Don't forget the history of agile; remember where it began and the intent behind it. As some say about scrum, it's lightweight, but it's difficult to master. Agile isn't about putting lipstick on a pig or a bandage on your issues. It's also not right for all things.

This thinking leads to newer, better ways of working. True agility cannot happen in a bubble, especially when that bubble predicates believing that one particular framework, when scaled, is the answer. Or if a specific tool is adopted, that is agile. An organization that is not nimble, lacks a growth mindset from the top-down, or advocates tools and processes over individuals and interactions, is not agile.