What is the difference between “being agile” and “doing Agile”?

…. And should you care?

I previously published an article titled “What qualifies as Agile anyways”? In summary, I’ve often wondered what qualifies as Agile (or not) especially as it relates to teams and organizations but even related to frameworks. A recent article caused me to recall my own personal agile journey and I shared my perspective on the primary test of whether something qualifies as Agile – i.e. does the (practice, method, framework, etc.) reveal better ways of developing software and help others to do the same? This test is grounded in the Manifesto for Agile Software Development (aka Agile Manifesto).

In this article, I want to address the subject of “being agile” vs. “doing Agile”. In doing so, I will expand beyond the primary test I discussed in my previous article to secondary tests as a measure for agility. 

On being agile…

You may recall from my prior post, that I led a Rapid Application Development (RAD) team, and after a while, I was asked my opinion on “Agile” and to develop a point of view for our organization. My initial research and understanding suggested that I needed to adopt a specific framework in order to be recognized as doing Agile. I quickly realized how wrong I was and that without even knowing it, my team was already agile.

How did I come to that determination, you may wonder? Very simply put, I evaluated my team in the context of the values espoused by the Agile Manifesto. It states:

“… we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Let’s look at a couple of these values in context from some past projects.

Value #1: Working software over comprehensive documentation

I recall my initial meeting with my (then) new client sponsor like it was yesterday, even though it was 10+ years ago. He wanted to observe how our team worked and so we gladly showed him to PowerPoint deck with 90+ slides we had produced to document all the planned changes to an application. It included detailed screen shots, user validation logic (e.g. error messages), system flows, the works. It was one of the artifacts that was required by the existing SDLC process to demonstrate that we had a complete understanding of the work that needed to be done before we began development. My client flipped through the document briefly, then commented on how it probably cost $10K to produce and was of little value and then tossed it in the trash! 

What a welcome relief! I’d wondered myself about the value of producing those documents especially since we were using a rapid prototyping tool that could have very easily created a better representation of the solution. Better yet, using the tool would allow us to identify potential constraints or pitfalls with the technology or business process much sooner. Going forward, we embraced rapid prototyping and short feedback cycles (2-3 days max) between joint application design (JAD) sessions with our customers and demonstrated working software. The productivity gain was immense as we were able to work through the details of design much quicker, sometimes in real-time during our JAD meetings.

And that documentation that was required? It was a lot easier for us to produce using information exported from our requirements repository and actual screenshots of the application as it was designed and implemented.

Value #2: Responding to change over following a plan

My project team didn’t have a plan for adopting agile. That’s not to say plans are not good (they can be when used properly). But in our case, we stumbled into Agile practices out of necessity. We had to demonstrate to our customers that we could be responsive to their changing mission needs.

Even though we'd had initial success, our team continued to refine and improve our methodology. For example, documentation, information security procedures and best practices were standardized so that the process became more efficient and repeatable. The roles and responsibilities of key stakeholders at all stages of the SDLC process were redefined to support the new process as well. Over time we incorporated additional Agile techniques including holding daily standup meetings, and maintaining a Kanban board to keep track of the multiple concurrent projects underway.

My team’s approach worked because an iterative approach better supported and enabled the dynamic nature of my client's mission objectives. The streamlined approach offered high return for low investment as it focused on reducing development time, eliminating bottlenecks, and automating static or manual processes. Its compressed timeline (weeks instead of months), consolidated documentation, and emphasis on reusable elements, allowed the customer to benefit from applications that were delivered faster and more often.

And all this was accomplished without a formal plan to do Agile!

On doing Agile …

There are some obvious anti-patterns based on what I've described so far. Here’s what doing Agile generally looks like.

1. My boss/client says we need to start doing Agile. So I’ve decided that all teams will start following <insert preferred Agile framework> effective immediately. Why this is bad:

• Focuses on process adoption/execution
• Doesn’t include the affected team in the discussion on preferred frameworks or approach
• Doesn’t answer the questions – Why are we adopting Agile? What value are we attempting to gain or what are we attempting to accomplish or improve?
• Values the plan over the changes required to be successful at adopting an Agile framework

2. My client states even though we have decided to start doing Agile, we still need to follow all the existing SDLC processes (e.g. participate in a linear process of approvals or produce copious amounts of documentation) so we can stay compliant with existing policy. Why this is bad:

• Existing processes become a barrier to successfully adopting an agile mindset because they are seen as fixed and cannot be changed/improved
• Minimizes the value of tangible progress (i.e. producing working software) in favor of process adherence and documentation

3. Agile is an “IT” thing so we don’t need to involve the business or think about how adopting a new implementation approach will affect them. We’ll collect requirements from the customer up front (waterfall process) but use an Agile process to implement those requirements (with minimal to no customer involvement). Then we’ll follow our normal (waterfall) process to get the application tested and deployed. Why this is bad:

• Customer collaboration is minimized. More interaction is required to truly understand client needs
• Even if the team produces working software regularly (and they typically don’t in this scenario), there is no guarantee that what’s been created is of the highest priority to the client or will actually work or be useful when the customer finally gets around to seeing and testing it

In these 3 scenarios, Agile is seen as a magic bullet.

The thinking is that the reason why my organization is unable to produce great software that meets client requirements in an agreed upon timeframe and budget is because of the process I’m following. This Agile thing sounds pretty cool so I will replace my existing process with some new process and follow this plan to the “T” and expect great results. 

Desired Outcomes

So the question is what outcome do you seek? Do you just want to check off a box? If so, then doing Agile should suffice for your needs. However, if you want to have real success with transforming the way you deliver projects, then I’d argue that being agile is the way to go.

Through my work, I have come to value:

Being agile over doing Agile

That is, while there is value in adopting an Agile process or framework,

there is more value in adopting an Agile mindset.

So if you’re tempted to just do Agile, go right ahead. But just understand it may be a waste of your time and effort. You may as well stick with your existing processes. You will likely have just as little chance of success with your existing process as you have with following an Agile process that hasn’t been fully thought out.

The Agile Manifesto states “We are uncovering better ways of developing software by doing it”. I believe that one line is the key difference between “being” and “doing” Agile. "Doing" treats Agile as a panacea that when followed precisely will automatically address all the ills preventing an organization from successfully delivering on their expectations. However, “being” recognizes that agile is more a journey than a destination – one of continuous learning and improvement. 

This concept is best captured by the term “Kaizen” which “simply means ‘change for better’“ and “refers to activities that continuously improve all functions and involve all employees” (Wikipedia).

In my next post, I’ll discuss how to transition from “doing Agile” to “being agile”. Until next time …

Azunna Anyanwu is a Certified Project Manager and Agile Practitioner (CSM, CSP, PMI-ACP, and SAFe Program Consultant) who leverages agile principles and practices to:

• Get to the heart of client business challenges and deliver technology solutions that address those challenges.
• Develop and mentor people and teams using a servant leader approach.