Keys to Successful Agile Maturity-EN

As an analyst, it’s always good to enhance your agile maturity by looking back and assessing what you’ve learned in your experience: the good and the bad. Recently, I was fortunate enough to take such a trip down memory lane, courtesy of my annual email clean-up. As I was going through some older folders, I discovered a slide deck that I had presented at the 2008 Agile Alliance Conference titled Lessons Learned of a BA on an Agile Project. My interest was immediately piqued, and the analyst in me couldn’t help but want to gauge my own agile maturity and do a retrospect on what I had presented, almost 9 years later.

It’s funny how the brain works. As soon as I got a peek of my title slide, I was back…back to June of 2008. I was just 4 years old, if you’re only counting my years of agile experience at that time. My first agile project kicked off in 2004, and 4 years later, I was using that experience to present a case study based on my involvement as a business analyst on an agile project. (And yes – from the very beginning of agile implementations, not everyone was buying into the idea that business analysts were unnecessary on agile projects…so I had a seat at the table of agile history in the making.)

Well, I am pleased to say that I stand by my content and lessons learned that I captured in my presentation. The original concepts and values at the heart of the agile approach are still true to their original form. Very few things in IT stay the same so that’s quite impressive. However, in the 13 years since I started working in agile, there has been a lot of room for interpretation. Hence why today we have Scrum, Kanban, SAFe, Lean Agile, and every possible combination thereof – Scrumban, Wagile, Lean-ban, and let’s not forget Fragile. The good news is, though, that if a team’s practices can be earnestly reconciled to the agile values, I think the creators of the manifesto would say you are operating within the “little a” and “big a” continuum. It’s those who claim to have reached the perfect agile implementation that are missing the point; agile is predicated on continuous process improvement.

Some Things Haven’t Changed

During my stroll down memory lane, another aspect that I noticed which hasn’t changed is the reason(s) people think agile won’t work. Many of these reasons that I still hear today are included on the slide which lists the challenges that my team had to overcome:

• Our project was driven by a mandatory regulation that had a hard deadline.
• We were not all co-located (half of our developers and testers were offshore in a different time zone).
• It was an existing legacy application with technical debt to consider.
• It had multiple business owners and even two different executive sponsors.
• We were working within a change management framework that was still based on the waterfall methodology.

When I look back at this slide, I have to laugh out loud because my team from 2004 is still using agile. Once they converted, they never looked back…even with these hurdles, it did work, and still does.

In the beginning, we felt like pioneers, and we frankly didn’t know any better. For us, failure was not an option. What didn’t kill us made us stronger. It was almost better that we couldn’t use Google to find how everyone else was doing agile. Writings on agile were few and far between. Our scrum master and coaches were taking notes to see how we got over each hurdle because they were relatively new to agile as well. As a team, we were able to overcome the challenges we were up against. We wore our battle scars proudly, and from this we created a true bond.

Keys to Our Agile Maturity Success

Reflecting back and now having seen many teams attempt and struggle at agile, the two things that I can say greatly contributed to our success (more so than agile ceremonies and tools) were the trust of our upper management and the attitude of the people on our team.

Organization Commitment and Support

I can’t say enough about our organization’s culture and environment. They made a major investment in the implementation. All team members were vetted and handpicked. There were even several existing employees who didn’t make the cut. Their positions were back filled by contractors with the right mindset. Once finalized, the team was sent to a week-long course and returned to find a new open cubicle configuration (for those located domestically), a video conference room, and war room. Any form of status reporting and updates were curtailed. All project and resource management was relocated and not allowed in the team space. We had agile coaches monitoring our actions who moved swiftly when they saw behaviors that were deemed “counter-intuitive to -Agile.”

As a team, we felt we were empowered and respected; we were allowed to make mistakes, speak out, be honest, and correct our mistakes in the way we saw fit. I’m actually still connected to the people I worked with on this team. In the Agile Analysis Boot Camp that I teach, I always say that a healthy agile team is one that you would want to work with again…and I would without a doubt choose this team again.

I won’t say that we didn’t experience any pain points, but no real and lasting change comes without some discomfort. My role as an instructor is to help clients differentiate between using or fearing some of these the same characteristics.

There are many reasons for the maturity gaps that our customers are experiencing, but one area that I think companies are slow to catch on to is accepting that agile is a culture change. Not just in IT, but for the whole business. Since systems and technology support much of the business infrastructure, implementing an approach like agile has a company-wide impact. Everyone needs to be bought in on why it’s good for the business. Embracing the agile approach as an organization helps companies stay ahead and stay in business in this digital world.

Agile Teams Include a Business Analyst

I also think it is no coincidence that having a business analyst on our team was a key part of our success. The value of the BA was understood by the entire team. When projects are straight-forward and several team members have analytical instincts or experience, there is a greater chance of creating the right value-based minimum viable product. However, as with my case study project, real life is never this simple. My students are faced with dozens of scenarios that make up a recipe for disaster, including resources constraints, deadline constraints, varying degrees of agile maturity, dysfunctional carryover team behaviors…just to name a few.

If you’ve read any of my blog posts or been in a class that I’ve taught, you’ll hear me emphasize the importance of two things: a healthy empowered, collaborative team and having an organization that embraces the agile mindset. Having a business analyst on your agile team is essential for bridging the gaps in an environment where documentation is lean and relying on good collaboration and communication is critical. An agile business analyst is your facilitator for both of those components.

For more on developing a successful cross-functional team, see my blog post on implementing t-shaped skills.

As delighted as I am to pull out these little pearls of wisdom from my early experience, I’m also excited to think about how agile has and continues to evolve and mature. Some aspects of our work that weren’t yet formalized are now part of the mainstream conversation…terms like scaled agile (i.e. SAFe), scrum of scrum, agile portfolio/program, minimum viable product, healthy agile team, agile fatigue, analyst pairing, agile management approach, agile enterprise, and team approach to product ownership.

We have plenty to talk about in the new year as we to continue in our agile maturity within the various agile practices and at the same time safeguard the original agile values. I look forward to being a part of the discussion!

Thank you,

Jacqueline