agile – Rajat Bhalla

What Determines My Decision When I Am Looking For My Next Role

I have moved around a fair bit in my career spanning almost 15 years. But it has definitely helped me build an extensive experience over the years with organisations ranging from 10 people startups to enterprises like Telstra to global behemoths like Oracle, in industries from Financial to Sports-tech to Telecommunications to Utilities, in roles from permanent staff to consultant to independent contractor. It has helped me develop a perspective on how the ways of working differ from organisation to organisation even when they are similar sized or in the same industry and how I can add value to them. Over the years, I have developed a significant expertise in Agile Coaching and Leadership (depth of my T-shaped skills) and adeptness with other areas like Software Development, Delivery Management, Project Management, Business Analysis, Testing, etc. (width of the T). I leverage my experience to enrich my work and my interactions with my colleagues. And this experience has been worth its weight in gold for me.

Every time, I have decided to move on from a job either voluntarily or because my contract was coming to an end, I have evaluated my options and tried to make the best choice. In the initial years of my career, that choice was more of a heuristics based decision. However, in the last couple of years, I have formulated a set of criteria that helps me make this decision better. I evaluate each potential employer with respect to the following 3 criteria:

1. Better Pay
Do I earn more than my current pay? Day rate contract jobs always pay better than fixed term ones or permanent jobs but do I want to take short term contract job just for better pay and then be back in the market again?

2. Learning Opportunities and Culture
Are there any training opportunities (more common with fixed term or permanent jobs)? Or do I stand to learn new things by working with experts or people in a new area? Is the culture one that fosters growth, creativity, and independent thought? Is it okay to fail (a culture that enables psychological safety)? Is it fun to work there? Sometimes you get hints about these from people in your circle who have worked there. Other times you just have to take a leap a faith and experience it for yourself.

3. My Lifestyle and Quality of Life
I go to the gym 3 times a week (nowhere near looking like Arnold Schwarzenegger or Rock), Buddhist meditation 2 times a week (even further from being enlightened), meetups on Agile and related things, and catch up with friends frequently. Would I like to do a job that compromises one or more of these things? Can I work it out by going to the gym or meditation classes at different times or at different places?

While the above things might seem random or even vain (money, lifestyle etc.), there is a method to this madness. Underpinning the above are 3 main values:

1. Mental Health

2. Financial Health

3. Physical Health

While I have made a conscious decision in the past to move to job that pays a bit less (when moving from a day rate contract to a fixed term one), I have made sure that I am not jeopardising my financial health. I will take up a job that is challenging over one that is boring. I will take up one where I have more avenues to stay fit and engage in social activities than one where I have to work long hours even though I am being paid way more. At the end, it is like technical debt. I might choose a job where I am less better off on one of the above factors but at some point, the debt needs to be paid off. And the question I ask myself is, “Is it worth the debt?”.

I might also add that, in the past, I have actually chosen to not go for organisations that are responsible (directly or indirectly) for destroying people’s lives (gambling, tobacco, cigarettes, etc.) or the environment (energy companies heavily invested in coal and fossil fuels).

Agile

Master

I came across the following quote at a Meetup on Leadership:

“When the Master governs, the people
are hardly aware that he exists.
Next best is a leader who is loved.
Next, one who is feared.
The worst is one who is despised.

If you don’t trust people,
you make them untrustworthy.

The Master doesn’t talk, he acts.
When his work is done,
the people say, “Amazing:
we did it, all by ourselves!”

– Lao Tzu

I believe the above aptly describes the Master in ScrumMaster.

Agile, Microblogs

Mindset

An Agile framework with a Waterfall mindset would not fly!

Agile, Productivity

Theory of Constraints

Image Source: chuansong.me

I recently attended a meet-up where one of the presenters spoke about Theory of Constraints. While a lot of us use this term, only a few truly understand it and can put it to good use. Luckily for me, the presenter was one such person and did a great job at explaining it to the audience. As he went along explaining the paradigm to us, I couldn’t help but notice how nicely it fit with the Agile and Lean philosophies. This blog post is about that connection.

But before we go any further, let’s first understand what ToC is. The website for Theory of Constraints Institute describes ToC as a way of identifying and managing bottlenecks that restrict the entire system’s output. It is a set of management tools devised by Dr. Eli Goldratt and introduced in his book “The Goal”.

ToC says that, at any point of time, there is a single constraint throttling the system. Eliminating/ easing this constraint improves the output. You then have to evaluate the entire system again to find out the next constraint. Rinse and repeat.

The above has an interesting corollary. An hour lost on the constraint is an hour lost by the entire system. However, an hour lost on a non-constraint is no loss for the system overall. So when we continue to improve something and still wonder why there is no improvement with the system at large, possibly we are trying to optimise something that is not the constraint choking the bigger system. Yes, we might still end up improving a sub-system but local optimisations do not help the larger scheme of things.

Eli structured the following 5-step process for ongoing improvement:

Theory of Constraints

Image Source: Theory of Constraints Institute

When we get bowled over by methodologies like Agile, Lean, Six-Sigma, etc., we forget that these methodologies primarily help to Elevate the Constraint (Step 4). Some of them might also contribute towards other steps but we still need to perform them.

Agile

I am an Agile Coach

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.

Agile

Innovation

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.

Agile

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.

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!

Agile

Cynefin Framework and Agile

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.

Agile

Fixing Bugs

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.

Agile

That Nasty Word Called 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.