I am an Agile Coach

 

I don't always

If you throw a stone at a congregation of software people, chances are you will hit an Agile Coach. Being an Agile Coach is almost becoming a fashion these days. “I am an Agile Coach”. I get to hear this quite a lot these days. It’s like ScrumMasters of yesteryears have now graduated to become Agile Coaches.

Not to condescend all Agile Coaches out there (well, I am one of them), I see lot of asses in lions’ skins (ass means donkey here, not what you think!). Yes, some of these Agile Coaches have truly risen from the ranks, worked their way through the trenches, and have earned their stripes (I come from a family with a long tradition of serving in defence forces). Such coaches have reached the Ri stage of Shuhari paradigm. They really know their stuff and are making significant impact with the teams/ organisations they are working with. However, there are others who picked up a ScrumMaster certification after two-days of training and became Agile Coaches overnight. Some of them even flaunt certifications across methodologies – Six-Sigma whatever belt, PMP (seriously?), etc.

Being an Agile Coach is not very different from being a sports coach. To begin with, you can’t be one just by passing a theoretical exam and having worked very little in the field. You need to have years of experience in the field and should have mastered some aspect of it. Like a sports coach, you should know that not all methods apply the same way everywhere – different teams have different training needs because of their own strength/weakness combinations. There is no one-size-fits-all approach. Yes, the basic principles remain the same but you still need to customise the treatment for each team.

And to make matters worse, such Agile Coaches are being hired by organisations (as employees on payrolls or as consultants) eager to get on the Agile bandwagon. And when their methods don’t work in such organisations, Agile gets bad name. People think, “maybe Agile is not for me”. Well, that could be true with some teams/ organisations but a bad implementation of Agile by a worse “Agile Coach” should not be considered a representation of what Agile truly has to offer.

I would just end this rant hoping that professional astuteness would trump fancy titles.

Innovation

Kmart

Image source: Wikipedia

Innovation and claiming to be innovative is becoming a fashion as product development markets become more and more competitive. However, while some product companies are innovating truly and are at the bleeding edge of their space, others are paying only a lip service to it. It is expected for companies in the tech space to be innovating because technology, by its very nature, not just allows but even encourages innovation. However, it is really impressive to see a retail organisation innovating and consequently faring better than its competitors in the wake of a slow market.

I recently had the opportunity to listen to Michael Fagan, GM – Store Renewal at Kmart Australia. It was interesting to learn how Kmart was fostering a culture of innovation and some of the indirect benefits it had reaped as a result of the same. 5 years ago, Kmart was close to bankruptcy and making virtually no profit. It’s an entirely different picture today. First quarter results for 2015 showed a 12.5% increase in sales for Kmart that helped it breach the billion dollar mark to hit $1.1 billion. While its competitors Myers and David Jones struggled to grow, Kmart recorded an impressive growth to increase its lead over them. Here’s a quick summary of points as mentioned by Michael that are helping Kmart thrive in this heavily competitive space:

  • When innovating, you have to do things differently from others. Get off the trend line.
  • Have high tolerance for ambiguity, risk, failure.
  • Fail faster, fail often. If you aren’t failing, you aren’t trying things differently.
  • Act fast, fail fast, learn fast.
  • Flat structures ensure bad news travels fast.
  • Don’t smack people down when they fail, especially in a high pressure environment.
  • Don’t be afraid to cannibalise yourself. It’s better to be cannibalised by yourself rather than someone else.

As I continued to hear Michael talk about how the culture at Kmart was transformed, I couldn’t help but realise that new principles fostering innovation were the basic tenets of Agile. When Agile came into being, or should I say “was formalised into a methodology”, the basic principle was to get real – accept that changes would happen, early and fast failures are preferred over the illusion of success, people need to be trusted so they can work at the their maximum potential – be more agile than more prepared.

While all of the above sounds like common sense, it still requires diligence and courage to implement it at an organisation with over 200 stores and 31000 employees. Kmart pulled it off. And not only did it help itself, it also helped its customers and vendors alike in the process.

Kano Model and Release Planning

I am a regular attendee at the various meet-ups organised by different groups on meetup.com. All my groups revolve around technology, particularly Agile and product development. At one of these meet-ups, the speaker briefly mentioned the Kano model. My interest was aroused as I recalled having studied about it during MBA (and eventually forgotten). The speaker mentioned how the Kano model can be helpful in backlog prioritisation and release planning. That was enough for me to decide to learn more about it. This blog post is the result of that research.

I will briefly describe the model for those who are new to it. The Kano model is a technique developed by Prof. Noriaki Kano to identify customer needs and ways to satisfy them. While this model is studied with great interest by marketers in the making, it is equally important to product managers who would like to see their product grow in the market.

Kano Model

Image source: Wikipedia

The model plots the level of functionality provided on the X-axis and the customer satisfaction on the Y-axis. Customer needs (and the features developed to meet them) are divided as follows based on their position in the graph:

Basic Needs/ Dissatisfiers/ Must-be Quality/ Expected Needs/ Thresholds
All these terms are used to describe the needs (or features satisfying these needs) that fall in this category. This is the minimum level that must be met in order to enter the market. Even though they cannot satisfy a customer all by themselves, their lack may cause significant dissatisfaction or, possibly, abandonment of the product. For example the ability to send text messages from a phone. These needs correspond to “hygiene factors” in Herzberg’s Two-factor theory. When entering a market, even a small increment in functionality increases satisfaction by a significant amount. However, once a basic level of satisfaction has been achieved, the needle on satisfaction hardly moves by subsequent increments. On the positive side, once you reach the threshold, you don’t need significant investment to sustain it.

Performance Needs/ Satisfiers/ One-dimensional Quality/ Normal Needs
Needs that have a direct correlation of satisfaction with the increment of change in functionality fall in this category. The more a product has of these, the more is the satisfaction. An example for this is the battery life of a phone (even though most of us usually change our phones before the battery’s life comes to an end). Based on the cash position of the company and its marketing strategy, it can continue to pour money into these type of needs and keep increasing its customers satisfaction proportionally.

Exciting Needs/ Delighters/ Attractive Quality
These needs are those that the customer is not necessarily aware of and is not expecting. But, they provide the “wow-factor” to customer experience and increase the likelihood of repeat purchase. Their absence does not decrease customer satisfaction but presence greatly increases it. These needs correspond to “motivators” in Herzberg’s Two-factor theory. For example, a free extended warranty plan with your phone. Over time, as competition matches your delighters, they could turn into basic needs. An example could be the front camera on a phone which was an exciting need a few years back but a phone without one would barely be able to make a sale today.

Indifferent Quality
The customers are indifferent to the presence or absence of these qualities and they do not affect his satisfaction. For example, (under normal circumstances) the quality of the box the phone is sold in.

Reverse Quality
As weird as it may seem, the presence of these “qualities” makes the product less desirable to the customer and affects his satisfaction adversely. For example, the iPhone 6 had a protruding camera to accommodate better optics but it was disliked by a lot of users worldwide.

Now how can we use the Kano Model for better Release planning and Backlog grooming? To start with, it might make sense to remove features that are perceived to fall under Reverse Quality or Indifferent Quality. You might not know these features upfront which is why market validation and lean analytics go a long way in identifying such features. You can choose to open the throttle on Satisfiers and Delighters based on your financial situation and your market strategies around your customer base (whether you want to expand it, retain it, consolidate it, etc.). However, it is worth investing in features that satisfy basic needs before going all out on delighters. Nobody has ever bought a car without a provision for spare tyre in the boot even if it had all the power under the bonnet!

Cynefin Framework and Agile

Cynefin Framework

I remember hearing about the Cynefin framework for the first time from Mark McDonald when I started working for Appster, the company he co-founded. When I looked it up, it seemed like a categorisation model of dealing with problems/ solutions. I made a mental note to understand it better but forgot about it over time. I recently had an opportunity to attend a meet-up on Cynefin that prompted this blog post. Without claiming to have extensive knowledge about Cynefin framework, I would like to put forward a brief summary that is the result of my online research and crowd-sourced knowledge at meet-ups.

Cynefin is a Welsh word meaning the various factors in our environment that influence us. Google translates it simply to “habitat”. Cynefin Framework is a model devised by Dave Snowden to sort contexts based on their cause and effect relationship. Contrary to what I assumed early on, the Cynefin framework is a sense-making model, not a categorisation model. In a Sense-making model, the framework emerges from the data, while in a Categorisation model, the framework precedes the data. It’s a decision framework that helps you identify the solution approach when looking at problems/ situations at hand.

Based on cause-and-effect relationships, systems can be identified as one of the following:

  • Ordered systems (further broken down into Obvious systems and Complicated systems)
  • Complex systems
  • Chaotic systems

Obvious systems (previously called Simple systems) are those where the cause-and-effect relationship is conspicuous and easily understood. It is predictable and repeatable. For example, following a recipe for omelette du fromage (my staple breakfast lately) is a simple system (even though I always argue that cooking is more art than science). The approach in such a domain is to sense the situation/ issue at hand, categorise it into one of the previously defined situation types, and respond based on what is the best for this context. This is the realm of best practices.

Complicated systems are those where the cause-and-effect relationship, despite being present, is not conspicuous. The relationship here, in order to be uncovered, requires a dependence on experts. For example, diagnosing what’s wrong with a V-8 engine requires an expert. Yes, you can Google it based on the symptoms but that cannot replace years of expertise. The approach in such a domain is to sense the situation, analyse it, and then respond. This is the realm of good practices as there can be more than one practice that works well (unlike best practices in simple systems).

Complex systems are those where the cause-and-effect relationship can be revealed but only in retrospect. For example, the climate change crisis we are all witnessing falls partially in a complex domain as this is the result of our actions (and inactions) over decades that is now manifesting as freak storms, weird weather patterns, and random climatic conditions across the globe. The approach in such a domain is to probe what’s going on, sense the situation, and respond accordingly. This is the realm of emergent practices.

Chaotic systems are those where there is no relationship between cause-and-effect. Stabilising and getting out of chaos is the primary solution here. An example of this would be the scene from the movie Flight where (spoiler alert) Capt. Whip Whitaker (Denzel Washington) does the unthinkable by flying the plane upside down in order to stabilise uncontrolled descent. The approach in the chaotic domain is to act first, sense, and then respond further. This is the realm of novel practices.

Between the above 4 states lies the state of Disorder where one doesn’t know what type of causality is in play (“what the f*** is going on?”). In such a domain, one usually shrinks to his comfort zone and takes decisions based on what one thinks is best.

Now how does Cynefin fit with Agile thinking? During the days of Waterfall-based software development, it was assumed that extensively detailed software plans would result in successful projects. Some of these projects (which fell in the Obvious domain) were relatively straightforward and were successful indeed. Some of them were part of the Complicated domain and they were partially successful. The others which were part of the complex domain failed miserably – huge cost overruns, delays several times the original schedule, glaring mismatch with customer needs, etc.

Not only is software development complex (by-and-large), the prominence of the human factor makes it all the more so (sometimes even chaotic). Cut-and-dried recipes of the past do not survive today’s world of software development. This is why Agile stresses on being open to change and tweaking the plan as we go about it. A big-design-up-front (BDUF) causes more problems than it fixes. Because emergent practices would help deliver the right solution, it is imperative that we iterate frequently (while keeping the iterations short) as we continue to build the solution over time.

Fixing Bugs

Bug

Bugs, flies, mosquitoes are common in most countries. And some of these bugs are found even in our code!!!

Even though we try our best to prevent bugs, sometimes these bastards make their way in the cool software we produce.

So, when do we fix them?

It all comes down to one golden word. No, that word isn’t “now”. It’s Priority.

This Product Backlog is always arranged by priority – highest priority stories at the top and lowest at the bottom.

You work in Sprints while picking up new stories from the top of the Product Backlog. This would also include bugs if they are high priority ones.

So in a typical Sprint Planning, you would pick some items from the top (they could be a mix of stories and bugs), estimate them, and then go about working on them during the Sprint.

But what about the bugs that are discovered during a Sprint?

Guess what, the answer is Priority!

Let’s say you are in the middle of a Sprint with 2 days left, you have completed 3 stories and are left with 1 story. Suddenly the QA angel comes to you with 3 bugs.

But what to do? You don’t have enough time to work on the pending stories AND the bugs. So you seek PO’s/PM’s help in prioritising.

Maybe the bugs are critical. If you don’t fix them, then the stories they pertain to are useless. In this case, it might make sense to work on the bugs instead of the stories.

Maybe the bugs are not so serious and can be attended to later. Maybe you can send them to the client as “known issues”. In this case, you put them on the Product Backlog where they get prioritised for the next Sprint (or even later).

Or maybe, if time permits, you work on one of the 3 bugs raised that was critical but wouldn’t take time. That ways you can complete the remaining stories and fix the bug. But if it isn’t so, then you prioritise.

When in doubt, talk to your PO/PM for priority. They would help you decide which is more important – the bug fix or new functionality.

That Nasty Word Called Backlog

Backlog

Before Agile, I always considered the word Backlog to have a negative connotation. It always signified that I was lazy and that I had work pending. It always hinted at my inefficiency. Google’s synonyms for backlog (logjam, pileup) aren’t very promising either.

However, Agile rescued me from the dark side (ok, maybe I am exaggerating but you get the idea). In Agile, backlog is not a nasty word. It actually signifies that you have a roadmap of what shape your project is going to take in the future. A backlog is a repository, in fact, a nursery of future features where they evolve over time. It is a hopper that contains user stories that would form the product in the future.

Every feature that you would like to have in your project is present in the backlog in the form of a user story (or maybe an epic). A backlog, ideally, should be DEEP (credit for this acronym goes to Roman Pichler, author of Agile Product Management with Scrum): Detailed appropriately, Estimated, Emergent, and Prioritised. Let’s see what each of these fancy words means.

  • Detailed Appropriately: High priority backlog items (at the top of the backlog) are defined in detail and are ready to be discussed in the next iteration. Lower priority backlog items (towards the bottom) are more coarse grained. The items in the middle are, well, somewhere in the middle with respect to detail too.
  • Estimated: Each item in the backlog is detailed. Coarse grained items have coarse estimates while fine grained items have a relatively accurate estimate (if there is a term like that).
  • Emergent: The product backlog continues to evolve over time with items being added to it, removed from it, modified, split into smaller stories, and so on.
  • Prioritised: Each item in the backlog has its own priority vis-a-vis other items in the backlog. The priority of stories, like the stories themselves, can change. Overall, the items at the top of the backlog have a higher priority and the ones at the bottom have a lower priority.

In order to have a smooth Sprint (and Sprint Planning), a groomed backlog is imperative. Failure to groom the backlog can take the project on the wrong track and leave the developers confused.

If you are aware of the acronym GIGO (Garbage In, Garbage Out), you would know that wrong input can create wrong (sometimes, even worse) output. Same is true of backlog.

Do not fear having a backlog. Instead, fear having a backlog that doesn’t evolve, a backlog that doesn’t reflect the upcoming features, a backlog that doesn’t show you at a glance the higher priority vs lower priority features.

Capturing Sprint Planning Discussions

Meeting Notes A lot of discussion happens around user stories during Sprint Planning sessions. Sometimes there is a discrepancy between what gets discussed and what gets implemented during the Sprint. This is because something was discussed but not captured somewhere. We need to close this loop and make sure that that capturing happens. I am not talking about recording some fancy audio-video tool. I am referring to capturing this discussion in the user stories themselves.

As you already know, user stories are only reminders for conversations and not be-all / end-all. There are details that are left out of user stories in the favour of discussion. When that discussion happens, we need to make sure that the conclusion is captured in the user stories. It could result in updating of the acceptance criteria. Or if the discussion was around technical aspects that need to be handled in a certain manner, the developer creates technical tasks for himself under the same story.

The key point is that whatever was discussed and agreed upon gets captured. During the sprint, when you get to that story, you should be able to look at it and know for sure what needs to be done in order to be done with the story. This helps in doing a good QA and UAT as there is a firm reference to verify against.