Category: Agile

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

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.

Agile

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.

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.

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!