Was your business agile enough to respond to 2020?

Hello again! 

I can’t believe it’s October – the beginning of the fall season here in the northern hemisphere. I can’t believe time went by so quickly. It feels as if it were only yesterday when we had to go into lock-down to respond to the pandemic.

One thing that seems to be pervasive this past 2020 is that we couldn’t make any detailed, long term plans. For example, I had to give up two major bucket-list trips this year that I was researching and planning for as far back as the latter half of 2019. I’ve had to sense and adapt to the ever-changing landscape constantly. I only planned as far as a month at most. Preparing for an entire year that’s always changing due to the pandemic was a waste of time.

For my trips, I had paid for certain things in advance. One reason for doing this early was to lock-in on fairly reasonable (cheap) airline ticket prices for premium economy. The other was to amortize my payments, since paying it in one big payment was very painful on the pocket. Moreover, I also purchased travel insurance, just in case, given the potential uncertainty of a trip 8 to 12 months far out into the future.

The (Mostly) Silver Lining

By the time the pandemic hit in March, I had already paid fully for my first trip since it was happening in April. Thankfully, I was able to get a full refund on the hotels that I had booked. However, I couldn’t get the airline ticket refunded. Instead, I got an extension by the airline to use the booking for a future trip. 

For my second major trip, I had only spent about 30% of the cost. I was lucky to get all the money back. I even got my airline ticket refunded for the 2nd trip. I also got my money back from the trip insurance I paid for since it no longer applied. 

Contortionists

I got about 90% of my money back. The remaining 10% was from the airline (who shall remain nameless here). Which now brings me to the point of this newsletter: except for that one airline, all the other businesses were able to respond very nimbly to the ever-changing conditions brought about by the pandemic. As a result, they were able to preserve goodwill to customers (me, in particular). Yes, these companies were impacted. But they were still able to elicit positive outcomes for themselves and their customers. How come the other airline could not? As a customer, I would go back and do business with all except for that one airline. I’ve since put that airline in my “Do not fly unless you have no options” list.

Is your organization nimble enough?

Upon reflecting on the vents of the last 5-6 months of the pandemic, was your department or organization agile enough to pivot in the pandemic quickly?

When people think about Agile, they usually think about applying Scrum and Kanban to their delivery teams. Limiting your thinking to this scope constrains your transformation prematurely. People neglect to look at the big picture – their entire organization – and it’s ability to turn on a dime, especially with unforeseen circumstances (like this pandemic). 

Business Agility implies that you and your entire business – not just delivery teams – can quickly respond and adapt to whatever is happening. Not only your engineering teams – but other areas of your company, like Finance, Sales, Customer Support, or HR, etc. – need to adapt, adjust, and deliver fast. 

In my trip example, all the other businesses I had dealt with were able to adapt to the pandemic, except for the one airline (who couldn’t give me a refund). That fact tells me that this airline had a very brittle organization that couldn’t respond well to the new pandemic landscape. 

I also tried to be as agile about my finances by amortizing the second trip’s expense at regular intervals. I didn’t pay everything upfront in one shebang. Notice how similar this kind of thinking is similar to iterative product development. I’m just applying it in the financial context.

Seeing the lack of Business Agility first hand

I was one of the coaches at a large company (about 25,000+ people), helping roll out Agile to the enterprise, the first of it’s kind back in the early- to mid-2000s. I started seeing how this lack of agility in other areas of the company impacted Scrum or Kanban delivery teams. The pain point for engineering was trying to deliver new products and services, and yet a 3-month (average) procurement process from Finance hampered them from releasing things in time. This pain became very evident, especially when a particular service or feature became viral. During these scenarios, engineering needed extra hardware or software quickly to scale up. Imagine what could have happened had the procurement occurred in a month instead of three.

How does one affect change in other parts of the organization, so that you don’t hamper your delivery teams? I’ve already written a couple of posts about performance reviews, for example, that address the lack of agility in the HR arena. In the next few newsletters, I’ll highlight some specific examples in other company areas that I’ve encountered. I’ll recount some of the approaches I did to make them a little more agile. Hopefully, the next few newsletters will give you some ideas on how to build a bit of business agility in your company.

In anticipation of my next newsletter, I’d love to hear from you. I’d like you to think about the paradoxical situations you’ve encountered between your Agile delivery teams and the organization areas that impact their agility. Drop me a note – I might highlight it as an example, and how I solved it (or something similar) in my upcoming newsletters on overall business agility.

Hasta luego,

-JF

 

Slicing Your Hiring Dinosaur to Pieces

Many companies have gone Agile over the years, undergoing transformations and seeing their teams deliver quicker (hopefully). Organizations seem to lust after delivery teams going faster. And yet as an organization, we hamper them in other ways, such as hiring.

Let me illustrate this with the following scenario. I’ve encountered this scenario many a time at various companies here in Silicon Valley. Some of the details may vary, but I’m sure most folks would commiserate with me.

Godzilla Dinosaur Cartoon

The Scenario

You and your teams are working on a very critical project. Tight deadlines are coming up. Out of the blue, a few people give notice to leave – for whatever reason. What now? The critical product that you’re working on will be severely impacted.

As a manager, you now have to deal with hiring new members and then ramp them up. And to top it off, it takes a while to get your job requisition approved first by Finance before it reaches HR and Recruiting, who then starts posting the job description. If you can get that description up in a week or less, you’re pretty lucky.

Then the wait. For that perfect candidate. That takes time. You might have to compromise on good enough, but the whole process to get a single person replaced takes about two months at best. Now you have multiple people to replace (assuming you even get a replacement opened up with blessings from Finance). This whole thing is going to impact your tight deadlines.

And yet, your senior executives have told you and your teams, “We can’t let any dates slip.” You ask about maybe getting some temporary contractors. Finance says no – budget reasons. Your senior execs say, can’t the engineers work more hours, over weekends? You know this is the nth time you and your teams have heard that. You know there’s going to be an even higher price to pay with possibly more attrition down the road.

All this haggling with senior execs, Finance, HR, recruiting – just to replace departing people – contributes even further to the delay.

Companies are asking teams to deliver continuously and fast using Agile methods. But why does the hiring process today remain a waterfall dinosaur, hampering those Agile teams? Why go Agile when the supporting structures around your Agile teams slow them down?

Can we modernize the dinosaur?

You might be asking, ”How can we streamline the hiring process, so it doesn’t impact the Agile teams?”

Before I continue – I’m going to warn you – the road is fraught with peril. Why? Because some of the changes touch on parts of the organization that may not be tolerant to change. You can start being cautious in your approach and propose small experiments to introduce the change. But once you hit that roadblock, you will still end up with a dinosaur (albeit smaller).

One of the critical things to look at is the flow of your hiring process. I highlighted some of the process flow with the scenario I provided earlier. There’s a lot of phased gates when you start the process of recruiting new talent. (I’m sure you can see how Waterfall-ish the process is.) You need to examine that flow and start experimenting with it. Once you understand the flow, you need to take baby steps to modernize it (i.e., make your hiring process a little more Agile). Let me illustrate with a couple of examples.

Child in Dinosaur Onesie

Baby’s First Step

In my scenario, as an engineering manager, when a person leaves, the first thing I do is go ask my boss, “Can I hire a replacement?” In my 30 years in Silicon Valley, this has always been the case.

So my question is, why? Why is there a need for me, the engineering manager affected, to ask first? The main reason is budget. I need to make sure there’s a budget for me to hire.

One quick solution I’ve found to work is to have that budget be transparent.

“Can I have access to view the hiring budget for our department?” I’ve asked that question to my directors. Some of them said no outright, and some said yes. And for the directors that shared this info, all I needed to do was look at it, inform my boss I was going to hire a replacement, and start the recruiting process with HR.

As you can see, such a small step has varying results, but the main point here is I’ve already improved a part of the process, even by just a tiny bit.

Taking More (Risky) Baby Steps

Another area in hiring that causes teams to slow down is the act of interviewing and finding the right candidate. It takes a long time to find a good enough candidate, and I’ve seen teams and organizations try and search for that perfect candidate (and your chances are slim to nil, mind you).

So, instead of interviewing when you need to hire, why not just interview continuously? Keep interviewing candidates until you find that “perfect candidate” that everyone on the team seems to desire. You can be more stringent with your requirements in your job description. You can let your team know that everyone has to say yes to a possible candidate – no nays or middle ground. You can continuously bring in candidates to interview, mind you, not every day, but maybe once or twice a week, so you don’t overwhelm you or your team, bringing down productivity.

And therein lies the rub why this is risky – you have to get a little bit of buy-in from HR and Finance.

As a director at a start-up, I proposed this solution to our Finance and HR directors. I had to allay the Finance director that I wouldn’t blow the budget. I had to ease the HR director’s concerns that I wasn’t stringing applicants along with an always-open job requisition. I gave them an exit trigger when to take this job posting down.

One reason why I was able to do this is because I had control over my budget. I could shift things around to fit my needs. You might say – yeah, easy for a start-up director. What about a big company?

And therein lies the rub. Are you or your organization willing to unencumber hiring managers by giving them control of their team’s hiring budget to be more Agile when it comes to hiring? If you and your company want to achieve better business agility, you need to move forward towards this direction one small baby step at a time.

Slicing the Dinosaur

From my examples, the main pattern for getting rid of the Hiring Dinosaur is to look at the entire flow. And then see how you can transfer more flow control to the person impacted most – the manager who needs to do the hiring. (Hmm – doesn’t this sound like Lean?) You need to do one small slice of control at a time, one level at a time, in an organization.

And a lot of trust is needed if you’re going to do this. The quintessential question to ask in these gates is “For <person> to relinquish control, they need to be assured that <manager> will do ______ and will not do ______.”

What makes this hard, though, is that you involve very sensitive parts of the organization. Specifically, you need to loop in HR and Finance. And yes, you may need to go all the way up to the C-Suite level as well, depending on how far you want to take this. You need their trust and buy-in to experiment and enact these changes.

And you will need time since the changes don’t happen overnight. You can’t roll this out to the entire company in one big bang.

This example is one of the reasons why I believe that Agile transformations never end. You’re only as Agile as your least Agile department. To achieve overall business agility, you need to start tackling organizational problems such as hiring that slow down your delivery teams.

Agile is Not About Doing

Eyes Behind Red Curtains On Wood Stage

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?