Agile / Schmagile. Irrelevant. It’s about flow bro!

I have spent the best part of the last decade working on Digital Transformation Programs working in different forms of Waterfall, Agile (and derivatives of Agile) and “Wagile”. The common questions and comments in this context go something like this.

“Absolutely, we’re Agile!”

“What’s better Waterfall or Agile?”

“Kanban is way better than Scrum!”

The fact is no one approach is better than another. The real question is, which approach will enable me to build the right thing, and build the thing right? In fact, combining the best of Waterfall and Agile is often the best approach, especially in a publicly owned Bank that wants to be Agile and at the same time demands a level of certainty, as it is expected by their Board and Shareholders. At Avoka, now part of the Temenos family, I believe we have found a beautiful balance between speed to market, agility and certainty. More on that later.

Before you brave explorers commence down your journey of “doing Agile” it is worth ensuring you are set up for success by assessing Agile Suitability. I often find a great way to introduce a new client or delivery team to Agile is to watch a brilliant 16-minute YouTube clip “Agile Product Ownership in a nutshell” which was produced by Henrik Kniberg in Oct 2012. It distills a 1-day Agile Product Ownership course into 16 minutes. For me when I was getting my head around Agile and trying to explain it to my team members and stakeholders, I found it extremely helpful. Hats off to Henrik to be able to explain something so multifaceted in such a simple way. Genius!!

So now you have a sense of what Agile is if you didn’t already. Here is a useful Agile Readiness checklist;

1.   Do I know what a Product Owner is and do I have one?

2.   Is my Product Owner empowered to make decisions that will not be regularly re-litigated?

3.   Is the “Right Thing” or my Minimum Viable Product certain and clearly defined?

4.   Is my external and /or internal environment somewhat ambiguous which could result in changed requirements?

5.   Is getting chunks of value fast to market important to me or my sponsors?

6.   Are my team experienced in Agile Software Development and Delivery?

7. Do I have a good Agile Coach? If your answer to question 6 is "No", then you need one.

8.   Do I have Agile and Collaboration tools available to the full team? E.g. JIRA, Zoom, Confluence, Slack, or other Microsoft Equivalents like Skype, Teams etc.

9.   Do your Clients and Stakeholders have their “eyes wide open” on what Agile is and what it means for certainty, speed to market and Agility? If not, get them to read this article

10.   What level of experience do my cross-functional team have in Agile Software Development and Delivery?

That’s probably a useful first check on Agile Readiness.

If your answer to the majority of these questions was yes then adopting some Agile practices will certainly help your organization.

The inspiration for this article actually came from a conversation I had with Andrew Knevitt some months ago. Andrew is a thought leader in lean/agile delivery models and we worked together in 2014 on a Program called Rapid Digital Transformation with McKinsey. I was discussing with Andrew the merits between Scrum and Kanban and Andrew very wisely pointed out that it was less about the name or approach and much more about the flow of work and the culture and capability of the team. “So, its about Flow bro” I said. “Absolutely, its about flow!”

There is no better feeling than working in a Digital Team where everyone knows their role and contributes to flow or velocity to solve oftentimes very complex problems, building beautifully intuitive software. Building the Right Thing and Building the Thing Right! The key to velocity is ensuring the team are not taking on too much, not taking on too little, and the value and productivity of the team just “flows”. The team are in the zone!

Then you can dive down a rabbit warren on different types of Agile software development methodologies. At a high level we have;

·      Agile Scrum Methodology

·      Lean and Kanban Software Development

·      Extreme Programming (XP)

·      Crystal

·      Dynamic Systems Development Method (DSDM)

·      Feature Driven Development (FDD)

The good people at Blueprint provide an excellent summary of Agile Methodologies. If you want to know more visit their website.

If you are not a battle-scarred software or technology company or start up and you have lower Agile maturity and experience my suggestion would be to start with Agile Scrum Methodology and ensure you have an experienced Agile Coach. Great Agile Coaches are like great Human Centered Design specialists. There are a lot of them out there under different guises and labels but the good ones are few and far between. Make sure you get a good one and beware the Purists! What do I mean by the purists you ask? The Agile Coaches that do not have a healthy dose of pragmatism and business common sense that often comment that “This is not Agile”, “This is not the right way to do Scrum!” “Waterfall approaches have no place in an Agile Program”. Absolute poppycock! The reality is for most public companies a level of certainty is an absolute must. So how do you take, if the environment warrants it, a "Wagile" Approach to Delivery to balance speed to market, with agility and with the right level of certainty.

At Avoka / Temenos the majority of our clients are FSI’s (Financial Services Companies) and an extreme Agile approach for most is scary to say the least. An executive sponsor in an FSI has to front up to the Board and provide a clear commitment on what will be delivered when given they are investing significant amounts of shareholder capital. Often in the millions, tens of millions or hundreds of millions.

Our delivery approach which is reviewed and refined constantly based on team and client retro feedback blends the best of Waterfall and Agile to Build the Right Thing and Build the Thing Right. We spend time up front to understand how a solution hangs together from a Solution Design Perspective and then we ensure requirements are clearly articulated via Epics and Stories and base-lined in JIRA. Then we start cutting code.

What that allows us to do is provide the level of certainty that our clients need up front around requirements, estimated cost and estimated time and also provides agility along the way when things change and we need to pivot. By having our stories in JIRA, and leveraging tools like MS Teams, Confluence and Zoom we can enable a rapid cadence and real time decision making and collaboration. By having a cross functional team across Solution Architecture, DEV, BA, CX and Testing we have built a recipe for beautiful design and speed to market. 

I hope for those less familiar with Agile Software development this article was useful. For those seasoned pro’s I hope there was a nugget or two in this for you. Either way I would love you to share, feedback and challenge. Let’s start a conversation.