“Moving towards Agile world is a revolutionary change as it requires changes in the organization culture and the way organization has worked so far.”
– ShriKant Vashishtha
Q.Welcome ShriKant, thanks for taking the time to run this interview. Let’s start with a short introduction about yourself (your role, how long you’ve been working with agile and the current company, etc)?
Thank you. As of now I work as an Agile consultant focused towards enterprise Agile transformation, coaching and training teams. I come from the development background and worked as Solution Architect in SDLC projects before moving to Agile. I got associated with Agile 10 years back. I specialize in distributed Agile and Extreme Programming. I am a blog writer and publish my posts on www.agilebuddha.com and on some well-known publication platforms.
Q.You are very passionate about Agile Coaching. Please tell us about it.
My passion has been problem solving throughout these years. If you look at IT challenges in their entirety, you may not want to look at software development in isolation. That’s the reason why I helped solving HR challenges, worked with sales and helped projects to come out from crisis with my techno-process inputs. I used to counsel colleagues. So coaching became a natural progression of my career which I thoroughly enjoy by helping teams on day to day basis.
Q.What does it mean for you personally “to be agile”?
Before moving to Agile we all have some or lots of apprehensions. Even if you find logical answers, it may be difficult to explain the real benefits unless you experience them.
For instance, irrespective of how many times I explain the awesome benefits of pair-programming to teams, they remain hesitant to experiment with it. At the same time, teams which started using it never looked back.
That’s why in order to experience the real benefits of Agile, it’s important to start doing it (“do Agile”), in a similar way we try and experience meditation.
As you do it, you get to understand the reasoning behind the Agile concepts. Moving forward, as you mature, you start experimenting with new Agile ideas for your project/context. That’s when you get into the process of being Agile.
Though it has become fashionable to ask teams to be Agile from the day 1 of Agile transformation, it’s not practical and doesn’t work as well.
So in summary, one has to start doing Agile before moving towards being Agile.
Q.Scrum is the most popular framework nowadays and that’s where most companies start. Once teams gain maturity, they move to or add other practices and frameworks. What methods, frameworks and practices are you using?
I personally feel whenever someone asks which methods, frameworks or practices to follow, that is really dependent on the project/context or problem statement.
Different Agile methods, frameworks or practices are essentially “tools” to solve your software development challenges. Tool usage is always context dependent. So you may not want to use hammer where you need needle instead.
Last week, I had my very first meeting with a team which is following waterfall methods and plans to move towards Agile. As I entered in the meeting room, the Project Manager asked whether I’ll be giving some presentation and should he call entire team to join that presentation?
I was perplexed and told that it’s impossible to tell if and where Agile may help without knowing what you are up to and what you want to achieve from the project. Only after understanding the problem statement, you get into details of which “tool” to use from your Agile “toolbox” (methods, frameworks, practices etc).
That’s exactly why, you may just want to use Scrum/Kanban if the problem statement is of non-technical nature. If it’s about software development, you may want to use combination of Scrum/Kanban and XP. If you are dealing with scaling challenges, you may want to look at SAFe, LeSS or Spotify approach individually or in combination. If you are dealing with startups, you definitely want to look at Lean Startup approach.
Q.We would love to get insight into understanding your journey with Agile Development?
I had around 8 years of experience working with SDLC based software projects when I started thinking about better ways to do our job as software consultants. At that time, we were doing a very large software project in which after every few months of coding, we used to create a build for testing. The build creation activity itself used to take days just because of compilation errors, functional errors etc as part of integration activity.
That’s when I started looking at better alternatives and found Cruise Control as a good Continuous Integration tool. Similarly we started experimenting with the idea of daily standup to fix our day to day issues instead of sitting on the problems for months.
I was fascinated with the outcome and thought of embracing Agile methodology whole heartedly and moved to a company called Xebia. For me, it was a big mindset change as every project over there was in distributed Agile mode. Indian and Dutch team-members were working in different time-zones.
Xebia used to follow Agile methodology and practices to the core in projects along with all available engineering practices like pair programming, Continuous Integration, Test Driven Development etc.
After working with few projects, we were in a state where we could move towards being Agile and could start thinking independently on what all is required for what context. We started experimenting with new ideas/practices specific to distributed Agile and published them as blog posts. Some ideas even moved to Agile conferences.
That’s when, I started focusing on multiple Agile projects as an Agile Coach and also started helping teams to move out of crisis as and when that happened.
In 2011 I joined a bank in Australia as a coach and became a part of enterprise Agile transformation team. At that time, the ideas on scaling Agile were taking shape and we implemented the combination of SAFe, LeSS and Spotify approach for our context. It was an awesome learning to help the bank in moving towards Agile, enterprise wide.
In 2013, I moved back to India and started working at GlobalLogic as a coach. Towards the end of 2016 I decided to start working as independent consultant.
During all these years, I published posts on distributed Agile, enterprise Agile transformation on my blog agilebuddha.com and presented in many Agile conferences.
Q.Where are Agile teams currently going wrong usually?
To me Agile values and principles are much more important than any specific frameworks or ceremonies. Some teams continue to work as development and QA teams while working in Agile. Some teams even estimate separately as dev and test teams. People continue to work as individuals instead of as team-members. In my opinion, the default mantra of each Agile team should be, “How can I help you?” and people should collaborate with each other towards achieving sprint goal. If team works as One Team together and collaborate, rest of the things fall into place anyways.
Q.One thing we often notice is that it is hard to develop a ‘sense of ownership’. What things do you believe contribute to that sense?
In my opinion there are multiple reasons behind that.
First, even after moving towards Agile culture, somehow we don’t want to trust our team-members. We continue to assign tasks to them instead of team-members pulling tasks based on the priority and their skill-sets.
Team-lead continues to represent the team and implicitly authorised to speak on team’s behalf. Team-members speak only when they are asked to.
If you don’t trust the team, you can’t expect ownership from them.
Second, many teams are still activity focused rather than outcome focused. The way we do the daily standup by answering questions like, “what did I do yesterday, what I am going to do today and any impediments”, helps focusing towards activities only.
Everyone shows how busy they are by answering these questions in daily standup. But that doesn’t really help teams in knowing where we are with respect to sprint goal. Instead of individual update focused, standup should revolve around finishing user-stories/tasks together to move towards sprint goal faster.
This way, team owns the sprint goal and not just their individual goals.
Q.If a company wants to start adopting agile, what are some of your recommendations on how to start?
I think the basic premise of Agile, Lean or Lean Startup is to help solving business problems. So it’s important to understand that the focus is to solve business problems, e.g. ability to go to the market faster and take feedback, ability to change based on business scenarios etc.
In order to help companies adopt Agile, it’s very important to hire an experienced Agile coach who could focus on the organizational challenges rather than just implementing Agile. While looking for solutions, there may be various “tools” in Agile “toolbox” which could be applied individually or together. Based on the holistic approach to solve business problems in hand, Agile coach can help in defining a roadmap which works for the organization.
Second, Agile adoption can’t be done in isolation. Moving towards Agile world is a revolutionary change as it requires changes in the organization culture and the way organization has worked so far. The individual KPIs of employees may change, sometimes it requires structural changes etc. So organization has to be ready in moving towards Agile mindset and culture. Otherwise Agile adoption may be shallow.
Q.One of the biggest project management challenges is dealing with risk. How do you handle this?
Risk becomes difficult to handle when it’s too much to handle and very late in the game. Some examples are, doing UAT, performance testing, security testing at the very end of the release instead of working on them on incremental basis.
I personally am a big believer of the principle “If it’s hard to do something, you are not doing it often enough! If delta is small so is the risk.” This principle can be applied almost anywhere to mitigate risk.
For instance, if you’re moving to an unknown path (functionally or technically), instead of going with “big bang” approach, you may first want to do Spike to gain the knowledge necessary to reduce the risk of a technical approach and then go ahead with implementing the story.
Continuous Delivery also works on the same principle. Instead of developing for longer period, pushing lots of code in production and as a result getting into trouble from any corner, what about having a small delivery cycle. That way first, as the delta is small, you have less probability of getting into trouble, second, you deliver features faster to market.
I can go on and on proving examples of this awesome principle.
Q.Can you give us some suggestions on how agile team should plan their tasks better?
I personally am a great believer of the Lean principle “Stop Starting, Start Finishing”. It’s more important to finish tasks faster than taking multiple tasks in progress and looking very busy. I believe in taking smaller tasks so that they could be developed faster and moved to testing faster as well, consequently move to Done faster.
So the most important thing is to take have small vertical slices, have minimal tasks in WIP and collaboratively work together to move them to Done faster. If for some reason, you are not able to slice some tasks small enough, nobody stops multiple people to work on them so that they could finish early.
Q.A great Agile coach helps others become great at what they do. Your thoughts?
An Agile coach continuously work towards making himself redundant for the teams. The same applies to Scrum Master as well. If teams continuously need a coach to help them, something is wrong. The ultimate goal is to have self-organized teams which may not need even Scrum Master sometimes to organize Scrum. In some of the teams I have seen, it was pretty usual for teams to be motivated and conduct daily Scrums without Scrum Master. If Scrum Master was on leave, planning or retro for instance didn’t stop. Someone else in the team used to take over that role.
I personally like to see such teams and help them becoming so.
Q.If you were to leave us with some advice, what advice would you leave us with for the Agile coaches who’re not anywhere near where we’d like to be? Or for the aspiring Agile coaches? What should we do?
Agile is simple to understand but difficult to implement. Teams learn it through introductory trainings but real-life challenges are way different. Teams face real challenges which sometimes are not even discussed in introductory Scrum courses.
As I mentioned before as well, it has become fashionable to talk about being Agile from the day 1 but practically that’s doesn’t work. . In a similar way, it’s equally easy to ask teams to become self-organized but then it’s not so simple to become self-organized in couple of days or weeks.
So my advice to budding Agile coaches is to spend time with teams and help them solving real-world challenges. Some people still continue to coach teams by living in ivory towers but that doesn’t help anybody and they struggle to get respect from the teams.