Agile & Harry Potter

What has Agile got to do with Harry Potter unless of course we are talking about how agile he is when he flies The Firebolt, the broomstick? That’s probably a discussion for another day. Let us now talk about Agile, the ways of working involving delivering value to business through Features, Epics and Stories.

Our Agile ways of working started predominantly during the work-from-home era due to pandemic. Since then, my kids have been exposed to quite a lot of Agile terminology. Two days back I was referring to User Stories in a conversation and Ryan, my ten-year-old promptly asked, ‘Appa, what are these Stories you are talking about. Is this something which you keep writing and publishing?’.

Now, how do you make a ten-year-old kid understand Scrum practices and Agile concepts such as breaking down of boulders, stones and pebbles. While kids these days are smarter than most adults, I still wanted to give an easier explanation. That’s when I noticed my son holding Harry Potter and the Order of the Phoenix, the fifth book in the series. A sudden spell came to my mind!

‘Here you go’, I said. ‘Imagine you have finished reading a chapter in this book. That is equivalent to a Story, the smallest piece of work that can be taken up and completed. Once you finish all the chapters in the book, that’s when you can say you are done with an Epic. When you finish all seven books in the Harry Potter series, you have completed a Feature. The catch is you do all these within a defined timeline which we call cadence.’

He seemed to be quite under my spell and I wasn’t finished yet!

I said, ‘Ryan, these Harry Potter books belong to your library which has quite a lot of other books as well. If you finish reading all of them, you have successfully delivered an Initiative, the topmost item in the Agile delivery chain which gets created based on the demand from your business unit’.

His face was beaming and I was quite convinced that I have simplified a complex model of Software Engineering as much as possible for my son. It was nothing short of magic! At least that’s what I thought till the time I heard another tiny voice from behind asking a question. It was Mia, Ryan’s younger sister.

‘But Appa’, she countered saying, ‘Amma had clearly told brother not to spend too much time with his story books. He needs to focus on his studies.’

I couldn’t help but smile, not just because of the seriousness of the argument, but being presented with an excellent opportunity to help them understand Agile better.

‘Yes darling, that is right, and it also is one of the most important principles of Agile which we call as prioritization. This is how you determine which piece of work is more important than the others. Just like studying well gives you good marks, reading other books gives you knowledge. This is the value that you deliver for yourself, just like how the User Stories deliver value to Appa’s business unit.’

I now have two budding Product Managers who are Agile ready, well almost!

Anatomy of Autonomy

It was the best hospital in the entire state run by a group of efficient, dedicated and extremely knowledgeable doctors. Dr Anatomy, Tommy as he was known, was the most admired among the lot. Years of practice and hundreds of critical and successful surgeries up his sleeve, Dr Tommy was revered by not just the medical team in the hospital, but by doctors’ fraternity across the state.

Dr Tommy led a group of proficient medical team, each one of them being the best in their respective fields. The anaesthetist, the surgical assistants, the nurses, and everyone else were simply the best. They all knew exactly what they were required to do and absolutely followed every instruction from Dr Tommy which ensured a hundred percent success rate for the team.

It didn’t stop there. Dr Tommy ensured that he gave enough room to learn to all his interns and assistants. They were trained so well that when an opportunity presented itself, they were allowed to perform surgeries independently with only a supervision from him. The story went on to the extent that most of the well-known surgeons across the state once worked with Dr Tommy. His legacy lived on.

One day everything changed. Dr Tommy had to pack his bags and move on. He was replaced by Dr Autonomy, Nommy as he came to be known later.

Dr Nommy was given a briefing of how the hospital functioned and especially the high-performance team. After learning everything, he introduced a new way of working for the hospital. He was a true believer in teams being autonomous. Hence, he suggested that they eliminate the concept of a team leader. Everyone was equal and played equally important roles.

He also brought in a dramatic change in terms of skills. Dr Nommy didn’t believe in specialists, instead he wanted the anaesthetist to assist in surgery, the interns to perform anaesthesia and the nurses even could handle a scalpel if need arises. Cross skilling was the order of the new world. What was even more clear was the fact that no one in the new team knew what exactly they were expected to do and when.

Surgeries continued to be performed, patients as earlier got admitted for surgery but unlike in the past, many of them didn’t leave the hospital by their own. They were all carried out in decorated caskets as the new team slowly but steadily helped the hospital to be in the record books for the greatest number of failed surgeries leading to partial or full loss of precious human lives!

The last update was that Dr Nommy lost his job and the hospital is searching desperately for Dr Tommy to bring him back.

Disclaimer: If this story has any resemblance to how agile ways of working was implemented in your organization, it is quite incidental.

How Agile is your Transformation?

 If you are a technology driven organization in existence for a decade or more, it is quite natural that you may have a mix of old and new IT applications. It becomes even more interesting when you have a bunch of in-house developed and vendor applications.

The third dimension to this blend, given the nature of operations is the fact that you have a combination of legacy applications that are running with minimum required support and new ones that are part delivered or the stars in the horizon for which development is in progress.

Frame the above picture in your mind and now think what will be your consideration when you are moving from the Waterfall way of delivery to Agile delivery. Before heading to the answer, we first need to look at some of the Agile considerations assuming we all are familiar with Waterfall.

With the risk of sounding like an Agile Coach, here are a few quick thoughts that come to my mind the moment we speak Agile. Sizeable chunks of work, Fail fast and Iterative development.

Sizeable chunks of work

This is probably one of the first questions that we need to ask the teams. Does the current status of a product allow us to break it down into sizeable chunks so that Agile development can logically apply? This could be possible for products that are already in production and for which a healthy enhancement pipeline exists. On the other hand you could face challenges with those products for which development is half way through with a pre-agreed delivery methodology. The scenario gets complex if we have a vendor in the mix.

Fail Fast

It is true that you could apply this fantastic concept for your products. This equally must apply for your transformation saga as well. You may try to pull off an Agile transformation for your identified products, but if any of them does not meet a criteria, it’ll be better to rethink the strategy. Probably having an Agile KPI is a good idea so that you have a measurable action based on which informed decisions can be made.

Iterative Development

This is a fundamental building block of Agile. Can you create your product in iterations? Can the releases be planned to add value to business incrementally? Can the product be pieced together to finally form a jigsaw? Are the stakeholders all aligned to meet this criteria? If the answer to any of these is ‘No’ you’ll need to revisit your transformation path for that product.

There are definitely many more factors that drive Agile transformation. The above three are probably some of the key ones. What is important is to remember the fact that while transformation could be essential for progress, it isn’t the panacea for an organization where a plethora of technology flavours co-exist.

You need to choose and choose wisely. Else your Agile transformation will end up being nothing but fragile!