Working in the industry, and having spoken to over a 100 people, we know Agile is used a lot. Every person knows what Agile is in one way or another. People keep talking about it, and the more we hear, the more it feels like a structure rather than a mindset. Everyone is so used to following conventions and rules that now we love building them and following them.
I remember joining a company some years back, and my first conversation with my agile coach was something like this. While the industry has adopted agility with open arms, we still lack people with an agile mindset, and that’s where companies should invest more and see how they can improve. Because often the Why part is more important than the what part.
In a true world scenario, I’ve seen a lot of Dev’s/QE’s being included in a project following scrum. They might be trained on Scrum/SAFe/Kanban or other framework’s – but a basic mistake is made where they are NOT being introduced to Agile Mindset first, which is where the problem starts. The same problem often occurs in many companies, even at the leadership level, where they often ask, “What needs to be done,” then the Why it needs to be done part, and so we have the company following a set of rules without knowing anything about the true agile mindset.
I remember being in a sprint retrospective once, and a scrum master was asked “Why is the retrospective needed,” and instead of answering the question to the team, they were just told that it’s part of the process. Losing such opportunities is what makes causes failure.
My memory takes me back to 2008 when I was in Bournemouth, UK, and I remember we were using Agile. I think that was the best introduction to Agile, where my Project Manager, Wayne Palmer, helped me understand the why part so much, as opposed to the what. He used to say, ‘you’ll understand the process and how it works because you’ll do it daily, but why we do it is more important.’ I saw one of the best implementations of Kanban back in 2008 which ran very successfully.
We used to go out to a bar where the whole team used to play planning poker. I used to see the real sense of each person there, with discussions on why something is bigger or smaller in a very respectful way. The first time I attended this, I was happy to see the most junior guys asking questions to architects and vice-versa, and it really felt like a family talking to each other. I used to see people thinking about the “we” more than the “I” and I could see mutual respect.
We had a board where we used to pick up stories and write their current state on cards. It had details like who was working, the start date, along with story points we had decided in the bar. It became a flow board, where people used to pick things, work, and really keep things moving. The items were broken as small as possible giving value to customers. And so, we could easily do frequent releases. The best part was that our project manager never used to ask us the status, he used to go to the board to see what’s happening, and used to draw charts as to how we were going, and they were literally hand drawn and put up next to the board.
Our stand-ups were very different from anything I’ve seen to date. We used to do a focused 1-2 lines on what’s needed in a stand-up, followed by improvements done if any, followed by something funny which happened in your life in the last day. Not everyone had a joke, but even one or two were enough to make people laugh. The focus on how to improve things was excellent, as that used to make people believe that change is good and welcome, and if you can talk to the group and everyone agrees, let’s just do it. Once the standup was done, we used to spend time discussing about some problems and who can help solve those problems too, which was great collaboration model.
I’ve seen a lot of teams following Agile in life, and many were good, but the story above was a team which I’ll never forget, as the trust, collaboration, binding between team members was at it’s best.
The above, in a way also touches upon the four pillars of the mindset: Respect for all team members, optimized and sustainable flow, encourage team innovation, and focus on relentless improvement.
Coming back to where we started, it’s more important to understand why you want to follow agile, rather than just following it. Sometimes the why part makes you understand things which the what part may not make you realize. I’ve seen enough certification classes where people ask questions a lot on the framework and how they function, but rarely on the mindset behind these frameworks, which needs to change.
I remember while doing my CAL-1,2 (certified Agile leadership) there was a section which was covered on Why Agile workshop (https://shift314.com/agile-is-not-the-goal-workshop/). I felt this is really needed in every organization, especially at the leadership level. Sometimes Agile starts from the bottom up, and we all know that it’s the HIPPO (Highest Paid Person’s opinion) which counts. So, the Why Agile workshop is good as it starts from the top, and get’s the questions answered like “Why Agile”.
Sometimes the process around agility might look strict in frameworks. Some people get uncomfortable with WIP limits, some with introducing scope inside sprints in scrum, some with bringing a new feature inside a PI in SAFe, but ideally all these tie back again to the why part. And that’s where we need to get our minds.
Sometimes we also tend to think of purist vs practicality in agile, and it’s tough sometimes to make a call on such things. I remember a coach and SM fighting over having retro every alternate sprint, rather than every sprint, and again it goes back to – what’s more important? Getting feedback regularly or having a meeting. I’m not replying to what’s right here 😊, all I’m trying to say is that we need to open our brains to why and think what aligns to the mindset. At the end of the day that’s what matters.