What's your flavor of Agile?

When most people think of Agile as an approach to software development, they envision the team holding a daily 15-minutes standup to update the team as they complete tasks from the prioritized list of items. While this may be the classic form of Agile, it represents only one of the many methodologies that come under the Agile umbrella. 

I’m quite often asked this question that what is the difference between these various methodologies and how do we select one? So, I thought of sharing my knowledge and hands-on experience with different flavors of Agile.

As I believe in constant learning and self- improvement, I have invested a lot in gaining knowledge by taking formal training and doing professional certification courses so that I could coach my teams how to implement these methodologies in a right way. My journey started off with Scrum which is the most commonly used methodology in Agile and as my expertise has always been into Product Management, the first course that I did was Certified Scrum Product Owner (CSPO). Very soon I realized that this practice couldn’t be implemented on all the teams that I was working with back in 2016, so I decided to organize a Kanban Training for the team and completed the Team Kanban Practitioner (TKP) course along with the 22 other members on my team. 

While my three out of four teams were following scrum, one team decided to go Kanban. The decision was made on the nature of work this team was doing. It was very hard to time-box their work and to maintain any focus on the current tasks. So, we decided to limit our work in progress and deliver features as and when they were ready instead of following a 2 or 3 weeks sprint cadence. 

Within few months of training, all the four teams were working great independently but there was less synchronization or alignment amongst all of them. We had dependencies that were identified very late in the projects that resulted in the delay of completion of these projects. That was the time when I stepped up and did my SAFe (SA 4.5) certification. The goal was to scale agile from the teams’ level to a Program level and eventually to a Portfolio level. In late 2017, I was then introduced to the concept of Lean. Got so hooked to the concept that I ended up doing a white and then a green belt certification in Six Sigma.

Here’s what my knowledge and hands-on experience says about the different flavors. 

Scrum – This is the most commonly used practice in Agile. Scrum in a nutshell is a time-boxed iterative approach where team members pull from a list of requirements that have been prioritized. This work is relatively estimated, and the team delivers a shippable product at the end of each iteration. This shippable code is demonstrated in the Sprint Review meetings and the teams share the lessons learnt in the Sprint Retrospectives after each iteration. 

Kanban – Key characteristics of Kanban approach is to maintain focus on the task in hand and limit the work in progress (WIP). The entire backlog is ordered by priority and the stories are not assigned to any team members. As soon as a team member finishes his current task at hand, pulls up the first task from the backlog. Explicit limits are assigned to different workflow states to ensure continuous progress. As there’s no time-box, features are delivered as an when ready. As compared to Scrum, the cycle or the lead time is smaller and more predictable in Kanban. As we do continuous integration and continuous deployments, the cost of release is high in Kanban as you might end up releasing your code twice a week. Whereas, in scrum you only release at the end of each sprint which is usually a two-three weeks cycle. Kanban also doesn't have any Planning, Review or Retrospective meetings. It's the least structured methodology of all.

Scrumban – This is more of a hybrid approach and my favorite amongst all. Here you take all the best features of Scrum and Kanban to organize your work in short sprints and limit the amount of work-in-progress in each project stage. Here, we still have a fixed time-box approach and the team still does the sprint planning and other agile ceremonies, but the new work is pulled only when after the current tasks have been completed. 

Lean Software Development – This in a nutshell is about reducing the production cycle-time and eliminating tasks from the production cycle that are redundant or do not add any value in the value stream. I’ve used this methodology twice in my past. Where my first experience of using Lean was more unintentional, the second one was a more organized and a thorough approach where I was able to map 4 value-stream processes for my team and we were able to reduce the cycle time by more than 50%. The crux is, we have been doing Agile even when we didn’t even heard about it. I remember when I was working with Mobifusion back in the year 2006, our product cycle-time was around six months where we received the raw data from the vendors, converted that raw-data that came in word docs to xmls. Manually tested those xmls and then made them available to be integrated into the mobile app into various different platforms. The whole process was very boring and cumbersome.  One day I decided to automate this process and wrote small macros to run the scripts that would look for a certain pattern and do the find and replace for us. After automating the conversion process, I also automated the testing process. This helped me in reducing the cycle time from six months to six days! So earlier when we were releasing one product in six months were now able to deliver 3-4 products every month! What it meant to business? Better Quality products and higher revenues.

Extreme Programming – Extreme Programming (XP) is an engineering-based system that uses automation and an inwardly focused effort to increase productivity and minimize interim work products. It incorporates automated testing and integrates results on a daily basis, as team members pair together to review and rectify mistakes as they are generated.

Large Scale Scrum (LeSS) – This is another scaling Agile framework that works as a simpler alternative to SAFe. This framework uses the principles of Scrum where the teams are self-organized, empowered and T-shaped and the Product Backlog Refinement, Sprint Planning and Retrospectives into a multi-team environment even for huge products where multiple Product Owners are required with a Product Manager as an ultimate authority. LeSS synchronizes the teams’ actions and activities to achieve overall goals and objectives efficiently.

Scale Agile Framework – SAFe is popular framework when an organization decides to scale agile to an enterprise level. At the multiple-team Program and Large Solutions levels, SAFe helps Agile teams-of-teams to co-ordinate through a joint Planning sessions and Inspect & Adapt review cycles. This includes all the Product Management and Architectural functions to help agile teams stay aligned against an overall Product Roadmap, Backlog and Architectural Runway. This gives you the opportunity to identify inter-team dependencies early on and it also helps you to predict your work to an epic level. For larger organizations, with many large products, this framework provides an approach for managing the portfolio pipeline investments and large epic initiatives are assessed for the strategic fit and return on investment through a lean, lightweight Kanban process so that they can be initiated quickly and a smooth flow of delivery is maintained. 

As all teams are different, the nature of work that they do is different, and the skillset that all teams bring is very different, we cannot follow the one-strategy-fits-all approach for all the teams! Hence it is very important to choose the methodology that matches your requirements very wisely. While Scrum gives higher transparency and visibility of the projects, it allows greater flexibility to accommodate change as well. Scrum has a well-defined structure and clearly defined roles that promote better collaboration and can help to get a project completed much quicker. But sometimes, it becomes difficult to impossible to breakdown the complicated tasks into smaller bite-size chunks and this can increase the risk of scope-creep. Kanban lacks structure and is not focused on cross-functional teams. This methodology is better when the teams can work independently and don’t have any dependency or collaboration required with other teams. As there is no time-boxed approach, the team sometimes loses the sense of urgency and delivers works slower. It is not considered to be an excellent driver of increasing speed, which is important for any digital transformation. Hence, most of my team always preferred following Scrumban which is a more hybrid model. 

But whatever framework you end up choosing, just make sure that you are not only ‘doing Agile’ but also ‘being agile’! Because after all it’s all in the mindset!