Doing things like Scrum or Kanban Does Not Make You Agile
I’ve come across many people who say they or their company are Agile because they are doing Scrum or Kanban. However, when I dig a little deeper to find out more details, I find a lot of them lacking. I’ve even encountered a few places where they tout they’re doing Agile and using it as recruiting bait.
They are what has now become a trendy term in the community – Fake Agile. (It seems to be fashionable once again since I’ve seen this wave before back in the early 2000s. As they say in fashion, what goes around comes around.)
What makes them fake?
For one thing, they’re only doing the motions. “Oh, yeah, we have two-week iterations.” “Yes, we meet every day at the stand-up.” “Oh yes, we do sprint planning.” And it just ends there. When I try to see the wizardry going on behind that curtain, I am aghast to find that they haven’t released or much less tested anything. And yet they say they are “doing two-week iterations.” Honestly, a lot of the times, they’re doing a bastardized version of Spiral – an iterative version of Waterfall.
Doing these things doesn’t make you Agile, in the same way that my brushing on some watercolors on paper doesn’t make me a painter.
Practices and Rituals Don’t Make You Agile
Guess what – there are many companies out there who aren’t doing Scrum or Kanban. And yet, they seem to be very Agile. They constantly experiment, pivot, release, and react quickly. Google comes to mind, having worked there previously. Most of the teams in there don’t do anything like Scrum or Kanban. A lot of the time, there’s little or no formal process or mechanism. And yet, they seem to be agile enough, responding to the ever-changing landscape and dominating various sectors of the industry.
A Definition of Agile?
Agile is all about having many feedback loops and getting feedback as quickly as possible. It’s about rapidly reacting to input and stimuli, and swiftly working to release what your customer needs immediately.
These loops come in many forms – from your customers’ complaints to your business; from when engineering lets your marketing team know what’s releasing this week, all the way to your marketing and sales teams leveraging that information immediately with current and potential new customers.
How you do things doesn’t matter. Technically, you don’t necessarily need to have a cadence (although it helps). Instead, it’s about getting things out as fast as possible based on input, stimuli, or feedback. You can be using Spiral, which I had mentioned earlier, and still be Agile (and yes, I’ve seen it done).
With software, it’s getting it out daily, if need be – as I’ve done in a few start-ups that I had worked in previously. If you’re in other industries like Pharmaceuticals, it might take a couple of years. I learned about this from a friend recently. If Pharmaceuticals can cut down the drug development time from 10 years, then that’s Agile for their context. We are starting to see this right now with the current pandemic and efforts to find a vaccine.
Agile is About Being, Not Doing
Being Agile has a lot to do with your context. Ask yourself – are you, your team, and your business genuinely Agile doing these practices and rituals? What does it currently take for your business to react and then release? And if you find you’re taking too long, challenge yourself – can you and your business respond and release quicker? What can your business do to make this the new reality?
In the end, you can sum it up and ask – why are you accepting the current status quo?
What Management Needs to Consider About Agile Transformations
Many Agile transformations are happening in various businesses at the moment. Yes, the current pandemic has sped up the need to transform organizations to be more Agile. But even before COVID-19, I was encountering transformation stories in the news, on LinkedIn postings or blog posts. I heard many first-hand experiences in MeetUps and conferences. As an Agilist, I am happy and pleased to see all these transformations.
Still, a part of me sees a problem with all these transformations, especially those made by large companies. The leaders who want these transformations think there is an end state to a transformation. They invariably will ask – how long will this transformation take? When will this transformation end?
The Honest Answer
My candid answer to this question of when a transformation will end is: Never. There is no end state. And if there is – it’s because someone defined that end state, and maybe defined it prematurely. There are a couple of reasons why.
Usually, the first and primary problem that leaders want to fix is the inability of their product teams to deliver fast, on time, or even deliver something at all. This pain point is typically the basis for starting the transformation. You send your people to take classes. You hire consultants and coaches to work with your teams to implement things like Scrum or Kanban. As the change gains momentum, you experiment with scaling tools like the Spotify model, Scrum of Scrums, or LeSS, to solve the broader coordination and focus needed to execute and deliver.
And invariably, this is where management sees the endpoint of a transformation, a myopic and short-sighted conclusion.
Transforming Delivery Teams is the Beginning, Not the End
As your delivery teams gain Agility, they will run into problems interacting with other departments. The problems encountered at these boundaries will slow them down. I first encountered this when I was an Agile coach for Yahoo from 2005 – 2008. Yahoo was rolling out Agile enterprise-wide. It was the first of its kind in Silicon Valley. And a first of this magnitude and size for the Agile community. That endeavor yielded a lot of excellent practices, patterns, lessons, and surprising results.
It also showed me the painful reality that getting delivery teams Agile was only the beginning of an Agile Transformation, not the end.
One example that highlights this issue from my Yahoo experience stands out to this day – the boundary between Engineering and Finance. As engineering teams gained speed in their execution through their Agile transformation, the procurement process slowed them down. A month or two wait to get expenses approved was the average – but I ran into several instances where it took three to four months. That’s a lot of wasted market opportunity. That is a lot of time that the teams could have used working and delivering on priority items. Instead, the teams spent a good amount of effort in managing the procurement process, instead of managing their deliverables and outcomes.
I always remember this example because I’ve seen it manifest itself repeatedly in two or three other companies after my stint at Yahoo. Same problem. Same result of delivery teams slowing down. There are other examples that I can give – the boundaries with HR, Marketing, Sales, etc.
And it manifested itself, too, in coordinating with some executives. You would not believe the wait it took to schedule a meeting with one executive for approval, let alone two or more if you had to deal with more than one.
Name the department, and I most likely have an example.
Change is Constant, Agility is Not
If you, as an executive, decide to green-light the transformation beyond your delivery teams, what then? Is there a potential end destination that you can reach? Can you consider the transformation as Done?
Unfortunately, my answer again is No. Change is constant. Agile itself is not unchanging. People are continuously experimenting and evolving with new Agile ideas, tools, frameworks, and methods.
Your company undergoes change every day. It’s a complex adaptive system. You have a constant ebb and flow of change. Ideally, teams are long-lived in Agile, but new hires come in, and veterans depart to other opportunities. Your company’s board changes. Your executive leadership changes. You go on a hiring binge when the times are good, and lay-offs when times are bad.
Your company responds to stimuli, like your customers and their changing needs and issues, the actions of your competitors, the regulations passed by the government. And yes, events like the pandemic.
You had to change your strategy and execution from all these inputs.
All these changes create an impact, and what used to work may not work again. You always have to adjust and transform – especially when it comes to addressing your company’s Agility. Doesn’t this sound familiar?
It sure sounds like Inspect and Adapt, one of the founding principles of Agile. It is the principal reason why there is no end to Agile transformations. You and your company have to metamorphose time and again into a better vision and version of itself.
What Management Needs to Ask, and The Short Answer
Hopefully, by now, you understand that defining an endpoint doesn’t complete your Agile transformation. The agility issues between the boundaries of various departments in the companies are downright challenging and complex. The constant change and stimuli require you to reevaluate and adapt your solutions.
During my journey working at various places, I’ve come up with workarounds. Sometimes, I have managed to penetrate the boundary and effect agility. But it also stopped at a point. Executives and organizations are not able to stomach the challenging changes needed to move forward continually.
As an executive, you have the right to decide and define an endpoint. You can ask and seek the counsel of consultants and coaches to help determine the endpoint. You can use them to seed and bootstrap your Agility efforts. You might copy and paste Agile, but don’t expect the results to last long term.
You are as “Agile” as your slowest department.
What Management Needs to Ask, and The Better Answer
Are you willing to go beyond what you initially thought an Agile transformation means if you genuinely want to transform your entire company? Are you disposed to let go of the notion that this transformation will end? Will you include these principles in the company Mission Statement and Values? Will you live it every day once you write it down?
Are you inclined to incorporate values of Agility in every department? Are you eager to go into areas not seen traditionally as requiring Agile, like Sales and Marketing? Are you capable of providing budget, allocating money, hiring people to help you build this continual evolution? Will you allow people to establish communities of practice within their domains and focus on helping the company see these issues of Agility and come up with solutions?
Creating a full Agile transformation goes beyond implementing things like Scrum, Kanban, or LeSS. It requires people to be vested in the mission and goal. You need people working for you to believe in it and work at it. You may start with external consultants and coaches. But in the end, you need to build this capability into your organization.
Are you prepared as an executive team to lead by example, ask help when needed, and enable the organization to follow you into this continually evolving Agile Transformation?
Fear of Missing Out (FOMO) and Bad Product Decisions (Part 4 – End)
Part 4 – Dealing with FOMO Through Planning
In my last newsletter, I talked about doing a quick dive into data to validate a FOMO-based decision. There’s another way to ensure that you don’t fall into a FOMO decision situation in the first place – you plan for it.
How do you plan for a situation like this, considering that external forces beyond your control drive FOMO-based reactions?
Well, not all things are beyond your control, because businesses have patterns. Apple usually makes announcements about the next generation of iPhones and the latest version of iOS every September. The Consumer and Electronics Show always occurs just after the New Year in Las Vegas, where many companies make announcements. These are but two examples – I’m sure you can find more patterns out there, both from your company and your competitors. (Although, because of the current pandemic, this year might be an anomaly for the patterns.)
I always bring these known patterns up at my rolling-wave planning meetings with my teams. I ensure that we have some room budgeted in the high-level plan. By setting aside time for these cyclical events, the team can accommodate potential things that might come out of left field. It further allows the business to ensure that we don’t negatively affect our strategic goals for the long term. If we end up not utilizing the buffer we allocated, then we can quickly pick something off our strategic backlog, given that we do rolling-wave planning.
I hope this series on FOMO-based product decisions helps shed light on some strategies to minimize the occurrence. The world is continuously changing, so one cannot utterly discount the scenario.
If you encounter it, I wish I was successful in giving you ideas on how you can address it and see if it is the right decision. I have a few other ways to deal with this, so email or chat with me about if you’re interested in learning about them. I’m sure some of you have encountered it, and I would love to hear from you on how you addressed and dealt with your situation.