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.

Why You Don’t Need Superhero Developers

No Superhero

Image source (prior to modification):

Most of us have worked with that one software developer whom the entire team looked up to when in crisis, the one who would come through despite obstacles, the one who would have answers to everything. To borrow a phrase from Star Wars, he was “the Chosen One” (I just had to get a Star Wars quote in). There is nothing wrong with the above except that it is “one person”. If your software strategy is hinged on one person, then you are setting yourself up for disappointment (and possibly failure).

While it is great that you have a superhero in your team who delivers when needed, what you really need are more everyday heroes. And not those one-man-army type ones but the ones who can work with a team and use their skills in harmony with others a la Fast and Furious. Yes, in a team with diverse skills and competencies, not everyone can work on everything. But it should not be the case that it is just one guy bailing the team out every time. Don’t get me wrong here. I am not advising a culture of mediocracy. In fact, I furiously fought against a culture of mediocracy at some of the organisations I worked for previously. I am all for making superheroes out of regular joes. All I am saying is that a culture dependent on superheroes to deliver instead of a team to do its job is a wrong culture.

It is not just about contingency planning (your superhero is sick or worse, leaves the company), it is also about building a culture where all the team members feel equally important and responsible. To take the analogy of Indian cricket team a few years back, some opening batsmen would play fast and loose because they knew Sachin Tendulkar (one of the best batsmen in the world) would be there to score big time if they fail. And fail they did. And when Sachin failed too, India lost the match.

We have been raised in a culture where it is good to be a maverick. Most of the movies of our times highlight that fact. But I would almost always give preference to a well-performing, highly-cohesive team of regular heroes than one that is dependent on its superhero. As the old African saying goes, “if you want to go fast, go alone; if you want to go far, go together”.

Theory of Constraints

Theory of Constraints

Image Source:

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.

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.



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.