Author: Rajat Bhalla

Agile

Agile is dead, long live Agile!

I recently ran into an old colleague and friend who works at a big retail brand (let’s call it BRB) as an IT PM. He enquired if I was still working with Yarra Valley Water, to which I replied that I had moved on and was looking for a new gig. He suggested applying for upcoming PM roles at BRB. I, however, expressed my desire to continue in my field of Agile Coaching rather than sidestepping into project management. He remarked that Agile had become a bad word at BRB and no one liked using it. He attributed the negative brand image of Agile to poor implementation on some projects by an “Agile person”. Due to his paucity of time (he had just stepped out from work for a coffee), we quickly wrapped up our conversation and agreed to catch-up again. But our conversation was enough to crystallise the thoughts I had already had in my mind (albeit on the back burner) about the way Agile is going (or being taken).

I have seen a few bad implementations of Agile that have caused stakeholders to develop a sort of PTSD towards Agile and everything that it advocates. I agree that perhaps they didn’t have the right person coaching them but the failure to deliver the right outcomes could be attributed to many causes (and mostly a mix of them):

1. Lack of expertise

If I had a dollar for every time I came across a fake “Agile Coach”, I wouldn’t need a full time job! I have seen so many charlatans in the name of Agile Coaches that it’s understandable to see people doubting their trade. When you invest in someone who is not an expert and doesn’t know how to deliver outcomes or is unable to see the big picture, you’ll end up with sub-optimal solutions at best or a mess for someone else to clean up after later. ScrumMasters, Delivery Leads, Agile PMs might be great at what they do, but they aren’t Agile Coaches. Yes, they can definitely become one of the best coaches over a period of time but expertise requires, amongst others, effort, commitment, and a resolve to stick to the principles.

And please allow me to a bit controversial here. Whilst some consultancies are great at providing valuable solutions, not everyone is specialised in Agile. I have come across consultancies that didn’t have much Agile experience but knew the jargon because they had worked in Agile environments before. The people that they deploy at organisations are just consultants in that they have broad experience but not necessarily the depth required. I remember working with consultants who were brought in to do Agile Transformation who didn’t even attempt to address the lack of Agile mindset at the client organisation. They were consultants who had wound up at this consultancy and were sold as Agile consultants to the client. At one of the organisations I had worked for, a senior member of the leadership team sent an email addressed to the other members saying “we do not need servant leadership outside of Agile”. This clearly demonstrated a lack of the right mindset and the transformation consultant did absolutely nothing to address it. They were just focussed on getting more people billing and extending their contract.

2. Lack of environmental support

Agile doesn’t just happen. And it’s hard to make Agile work in isolation when it has connected parts that aren’t functioning in an Agile manner. Yes, you can get some benefits for sure but if you continue to drive the overall system in the old way, you will not get significant improvements. If you are still feeding requirements the old way, still using your Gantt charts to measure progress (I remember working with this programme director who was using a Gantt chart to track the delivery of user stories and plan for next ones), asking for powerpoint reports, not providing opportunities to generate feedback from delivered output, running a command and control shop, then you don’t have an Agile workplace.

3. Lack of organisational mandate

This point is related the one above but still deserves a separate mention. I have experienced departments and divisions trying to do Agile without an overall organisational mandate just because it’s the new buzzword (well, not so new anymore) or you see your competitors doing it or because it attracts better talent. Whilst there is scope for an experimental approach towards Agile to see if it will work for you or not, lack of an organisational mandate will always run the risk of not getting enough environmental support to drive it well, reverting to old practices because this isn’t working out, or people simply refusing to change their way of working. This is why “new way of working” is becoming a popular paradigm with organisations committing to doing things better. However, it has it’s own pitfalls as well which I will save for another day.

4. Solving a problem that doesn’t exist

This needs to be said. If it ain’t broken, don’t fix it. Yes, Agile offers great benefits that go a long way in supporting your organisation and addressing the needs of the customers better but if you are getting what you need with your existing system, you may not necessarily need to change to Agile.

Having looked at why Agile may not be working for some organisations, it is all the more relevant in today’s day and age.

  • The markets are getting more and more competitive
  • The rate of delivery to customers is increasing all the time
  • Customers are jettisoning products and services quickly that don’t solve their real problems
  • Employees are prioritising work culture and quality of work life over other perks and remuneration
  • Organisations that have had a significant presence in the market for decades are getting over taken by new age businesses
  • New markets are coming up that hadn’t been envisaged before

Agile doesn’t solve all your challenges. It is not a panacea. However, it will help you navigate your way through your problems. It will help you do things well based on real feedback that will keep you focussed on the real pain points. And it will help you flag issues early on that might become a setback later. It will help you foster a culture where your employees buy in to your vision and work with you on your problems. However, it still requires making the hard yards and real experts to guide you on your journey.

Photo by Clément Falize on Unsplash

Agile, Productivity

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:

Three 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:

Three 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, Uncategorized

Why You Don’t Need Superhero Developers

No Superhero

Image source (prior to modification): beliefsoftheheart.com

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”.

Microblogs

Microblogs

Microblogs

Image Source: kcet.org

Many times I come across quotes, phrases, small nuggets of information that seem profound yet do not require an entire blog post. Henceforth, I will post such pieces as “microblogs”. No fluff, no detail, just the condensed version.

Uncategorized

UX vs UI

Lipstick on Pig

Image Source: lipstick-pictures.blogspot.com.au

Oh, the confusion! Saying UX when you meant to say UI and vice versa? Believe me, I have been there. I have watched designers and UX experts cringe when I mixed up the words. I think I understand them better now. And not because I got myself a certification in either. It’s because I am a foodie! So, I will explain you the same way I understood it.

How many times have you dug your teeth into a pie (or a burger for that matter) that looked tantalising only to realise that it didn’t taste as good. All those pretty pictures of food in advertisements (I call it food porn) that left you salivating and yet had you taken a bite of it, you would have probably ended up in the hospital. That’s all fake. But I don’t want this post to turn into a rant on how advertisers mess with our senses so I will stay on course.

How the food looks is its UI (User Interface). What you feel when you eat it is its UX (User Experience). If it looks good and tastes good, you are a winner (and so is the chef!). However if it looks good but doesn’t taste so, then you might not visit that eatery again (don’t go there on a date). If it doesn’t look great but tastes awesome, then you might want to go there repeatedly (it might be a tad difficult for the eatery to get customers in the first time though). Now let’s see how does this analogy work with digital screens (websites, mobile apps, etc.).

When you look at a website or a mobile app that looks really slick but is a nightmare to work with because of convoluted workflows, you have a great UI but bad UX. The opposite is when you have an average or poor looking screen but it does what it says and doesn’t tax your brain in the process. That is when you have a poor UI but good UX though such scenarios are rare. A winning website or app not just looks awesome but also lets the user cruise through it leaving him with a sense of satisfaction and accomplishment.

Sometimes the experience with food goes beyond eating and involves digestion or even longer term affects. You had a great meal but it made you feel bloated and you ended up farting all night much to the chagrin of your partner. Or it gave you a sore throat and you had to go to the doctor to find some relief from incessant coughing. Disclaimer: As someone who loves to try new food from different eateries, I have fallen victim to both the above scenarios. Similarly, it’s possible that the user experience with a website led you to believe that you had set everything properly only to realise later that it wasn’t so and you had to go through a lot of trouble fixing it. That qualifies as poor (if not terrible) UX too.

Summing up, don’t just put lipstick on a pig. Before you make the website or app pretty, make sure it works well too. If you really want your burger to give an orgasmic satisfaction to its eater, make sure its done well and looks good too. Now all this talk about food has made me hungry. I will go and eat something.

Agile, Productivity

Theory of Constraints

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

 

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.