Be agile before you do agile

---

The agile way of working has been expanding its territory on the IT landscape. Conventional methodologies are being replaced with an intent of getting the results “faster”.

In an attempt to make Agile a mainstream methodology, organizations are acting proactively to prepare their workforce “Brace yourself. It’s here.” The multitude of agile training sessions is floating around. Teams are prepared to work in an agile mode with agile tools. Everyone is whispering nothing but agile. Work effectively gets started with a new model. Meetings, stories, demos, backlog, burndown, velocity, and many more new words find a place in teams' vocabularies. Checklists are scrutinized: Stories updated? Check; Demo did? Check; Burndown? Check; Velocity? Super-check. All seems well.

Is there something we forgot to “check”? Is there anything that should have got more emphasis in whole agile preparedness. To know this, ask this one question to your team members “Do you know why did we change from conventional method to agile in the first place?” Their answers would unveil the solidity and serviceableness of agile.

I keep talking with some of the agile delivery teams who have already transitioned (or transitioning) from traditional method to agile. I was awestruck by the fact that many of them viewed agile just another way of working imposed by the organization. Many failed to explain any benefit out of the new working model, at least at the ground level. 

Developers are mostly like “We were coding before…we are coding now. What’s the difference?” or “I like agile, but not the meetings…”, etc. Win no award to guess the most disgruntled resource in almost all the teams? The QA resource. I just mention the word “agile” and they appear as if I asked them to stand on a single foot on a hot pan. They go nonstop, “The defects never stop…they keep giving the requirements…they keep developing…we keep testing...it never ends…I was so happier before.” Well, I had to ask them back “Isn’t it what agile is...“it never stops” until a project is done.”

Being an ultimate advocate for agile, sensing such concerns makes me think hard that something deep down is missing although managing the agile tools and rituals seem cup of tea for all the team members. The root cause appeared to me, was that the very core “agile” itself was missing from them. Being good at creating stories or other work items and deciding their journey through various statuses - New to Close, flashing smooth burndown and robust velocities are not enough to be agile. To cultivate agile at the root level, there has to be a paradigm shift, a mindset change.

It is sometimes easier to see the ROI at the higher level (at program/portfolio level) with the help of numerous profit-telling metrics, but at the level of the core team (or the delivery team), the value or the profit of using agile should be explained in a different way.

To make sure each team member comes within the same frame of the project picture, infuse some foundation questions:

1) What is the objective?

To deliver the project successfully with 0 defect and countless delights.

[A customer is happy when they get what they want, and happier when they get it earlier. And a happier customer is all that we want.]

2) How can we achieve it?

Start delivering the working pieces in parts regularly (or incrementally), get customer feedback at the earliest, and make amendments in deliverables whenever necessary. Rinse and repeat.

3) Why should we do it this way?

Because agile will allow us to do _____ (fill in the blanks with the activities, for example, frequent releases, integration, or any other relevant engineering practices).

[Incremental delivery would require some changes in software engineering culture also. You need to prepare for frequent releases, builds, continuous delivery, continuous integration, continuous testing, automation, consideration of testing environment and prod environments model, and many more. CICD and DevOps should be on your list of considerations. Take time to examine and select your engineering practices. The aim should be to deliver (release/deploy) quicker without disturbing the active prod environment.]

The crux is that the team should view agile not only as a different way of working but also as a progressive and constructive way of working. Build the culture of sharing and learning from the success stories of agile adaptation. Retrospect not only the project but the agile health in your team, in your department, in your organization. Take care of agile health because agile is not just a process, it’s a mindset. It’s not just about new tools and way of working, it’s about a new way of thinking and delivering.