Let Them Eat Cake

How do you proceed to eat an entire elephant?

One bite at a time.

Wait – I thought this was a post on cake? Why are you talking about eating an elephant? Let me get to that in a moment. (Unless you made an elephant cake, of course.)

I’m not trying to be facetious here with the eating an elephant analogy. I’m highlighting a struggle that many Agile teams face when they are first going about their Agile journey. How do you break down a project or product delivery into smaller pieces? How might you deliver something that has value to someone every two weeks (or even much less, like three or fewer days for Kanban)? You will need to create small bites – or slices – that someone can use if you want to deliver within your iteration. In other words – it has some value to someone. 

Marie Antoinette and Cakes

Think of it this way – say you’re serving a 5-layer cake (are you noticing copious food analogies here? 😉 ). When you give the cake to someone, you don’t give them the entire bottom layer (since it’s the only one you’ve finished baking, perhaps), and then wait for them to finish before giving the next layer (which hopefully is done by the time they consume the first layer). That’s just too cruel and disappointing, right? No, you give them a slice – a small sliver that contains all five layers and icing.

When you break things down to their smallest value, you have to think about delivering in terms of valuable (consumable) slices (of yummy cake). You might say – yeah – but I still had to bake all five layers, make frosting, put it together, and then get a slice of cake to serve. For cakes, yes – you have to do that. But when it comes to work and what you deliver, do you genuinely need to build every layer?

A Simple Slicing Strategy to Start

One of the most common ways to start slicing is looking at the Happy Path Scenario and building that. We solve for all sorts of flows, where someone starts from point A and ideally ends up on point B. 

For example, if you’re building a website, one small flow you can work on is creating an account. The Happy Path here is landing on a sign-up page, providing an email, providing a password, and voila – you now created an account. 

Does your sign-up page have to be high-fidelity at this point? Not necessarily. When Google first started, all they had was a simple space bar and a Search button.

What if the user entered an email that already existed in the system? Well, you may not have built that yet. As I said, this slicing example is the Happy Path. This example is what I mean by a slice. A slice is a small piece of work that is achievable in a tiny amount of time. And it has value – we enabled a user to create an account. And we can get feedback to help us enhance and modify what slice we potentially will do next: Do we continue with the current cake? Or do we pivot to another part of the cake? Or do we make another cake entirely?)

You might be saying, “Yeah, well, if this was your cake, you still can’t serve one piece to the customer. They are buying the entire cake.” Yes, you are correct. The beauty here is that you’ll find yourself building a bunch of small slices. And when you aggregate these slices together, you will end up with a “good enough cake” that you can serve. It’s valuable enough for people to use. You may not have built everything you wanted yet. But you may have something usable by a small but sufficient amount of people to be valuable enough to release.

Other Slicing Strategies

In the previous section, I already alluded to two other slicing strategies. Were you able to spot them?

The first one that may be obvious is slicing for different error conditions: What if the email account exists? How do we prevent a bot from creating a bogus account? And so on.

The list of error conditions can be infinite. Do you need to build for all of them? Not necessarily. You can now look at prioritization strategies. You might create a variant of an Eisenhower Matrix. Your X-axis can be the probability of the error (low probability to high probability). The Y-axis considers your risk (low risk for the customer to high risk for the customer). You can target the error conditions in the high probability, high-risk quadrant as the ones to build out first. (Or, another alternative instead of prioritization is to build a story map.)

The second strategy may not be as evident with the Google Search example: start at very low fidelity, and build up from there. Using this strategy is most effective when you’re collaborating with UX Researchers and Designers. Working together, you might target a low fidelity scenario for the first slice of cake you’re producing to get feedback on what you’re creating. You’ll be continuously learning from feedback while still building for the whole.

Beyond Software Delivery

You might be saying to yourself, “JF, this is fine and dandy for software product teams, but I’m not in software.” 

The same slicing strategies apply. For example, let’s take a look at HR and onboarding a new hire. From the moment a new hire clicks on Accept on their offer letter to the first week they start, an onboarding flow exists. And you might want to build a flow that is engaging and frictionless for the new hire.

As a startup company, your new hire flow might be somewhat low fidelity. You might start with a simple document that they sign, a questionnaire for what machine and login/email name they’d like so that these are ready on their first day. You might start sketching out a manual process to start and then slowly automate it over time.

As the startup gets bigger, your onboarding flow might become more complicated since your company may be hiring many people. You might want to automate the procurement of laptops, for example, so that it gets automatically configured and delivered to the new employee in these times of pandemic.

And here’s the third slicing strategy that you can use. When you have a long and complicated flow (whether existing or new), you can break down the long, complicated flow into smaller flows that you can target. 

It’s like driving from San Francisco to New York. You can do it one straight shot, but that’s going to be too tiring and leave you with no time for enjoyment. You can break the trip down and have some pit stops for exploration and fun. You can design your trip to stop in Arizona to explore the Grand Canyon. Then head on over, making a left at Albuquerque so that you can grab some good ol’ barbeque in Kansas. 

You can do something similar with HR onboarding. You can concentrate on a subsection of the flow and fix problems. You may want to modify it. You can also add new, additional flows to make the whole onboarding process better by adding one small flow at a time.

These are just a few quick ways to break down things into deliverable pieces of value during each iteration. There are many other slicing strategies that people have written about, which you can find through Google. I typically start with these strategies when I’m coaching teams that are new to Agile. Hopefully, these few suggestions can help you on your path to getting comfortable with breaking down items that fit in an iteration.

A Lightweight Template for Monthly Performance Discussions

In my series of newsletters on preparing for your performance review, I mentioned a template you can use when talking with your manager during your one-on-one meetings (1:1s). A colleague and I have also mentioned this template in our talks on performance assessments, rewards and recognition systems, and how to make them more supportive of Agile. Several people have requested the template, and I’m sharing it here.

I have used this template (or variations of it) in at least four companies I’ve worked in already. I use it when I meet my manager during my 1:1s, or with my direct reports when I have 1:1s with them. I do have some guidelines, so feel free to use, modify, or even add to them.

1:1 Performance Review Template ImagePerformance Review Template

Usage Guidelines

  • Use the template once each month during your 1:1 with your manager (or direct report). The idea behind the template is to get performance feedback early and often, as opposed to once a year, when HR calls on the entire company to do their performance appraisals and reviews. (And if you don’t have regular 1:1s with your manager, you should consider starting the discussion from there.)
  • The idea behind the template is that it is lightweight. You don’t need to fill in every line or go into the minutia of the details. You want the right amount of discussion, and add those as highlights to capture the key points about your performance – the good, the bad, and the ugly. Most often, the good stuff – even the regular, day-to-day wins or the win of the week, aren’t brought up. People then forget these when the yearly performance review cycle comes around. And as for the bad stuff, you usually get it right away. And it can linger and follow you for ages. As Mark Anthony said in his eulogy to Caesar in Shakespeare’s play Julius Ceasar, “The evil that men do lives after them. The good is oft interred with their bones.”
  • Tailor the template to your needs. Modify the template depending on your context. For example, I’ve modified it to conform to an Objective and Key Results (OKRs) style at one company where I was working. You can do the same if your company uses Management by Objectives (MBOs) or something similar.
  • Highlight outcomes and impacts, not outputs. People often write outputs on their performance reviews – like “refactored the architecture for our product.” Yeah – we all know you reworked and coded this, but what was the impact of that effort? Did your team get to release the product faster, positively impacting customers who were about to churn? (And mind you, this is great to bring up in your resume – recruiters and hiring managers love to see these outcomes and impacts.)
  • Always move forward. The goal is performance discussions is to grow yourself – whether it’s learning new skills like become a team lead or using new technologies. It’s about learning from mistakes – how you and the team can mitigate issues that came up, or how you all can improve and become more Agile.
  • And lastly, highlight yourself AND your team. Most performance reviews typically highlight the individual. Agile emphasizes team collaboration. Don’t just talk about yourself. Talk about how you and your team get together or do things together to amplify successful outcomes – not just for you but for the team and the company.

When you do these things, you will end up with 12 templates filled out – one for each month. And guess what happens when HR sends out that email informing everyone about the upcoming performance review cycle? You’ll be very prepared to fill out your performance assessment.

Having these monthly filled-out documents, joyously made it easy for me to fill out my assessment (or my direct reports’ assessments). I didn’t have to stress out remembering what I accomplished the past 12 months. I mostly ended up copying and pasting what I had written, with maybe a little bit of wordsmithing, to fit the assessment outlines provided by HR.

I do hope you find value in this template. I would love to know how you modified it to fit your context. I’d love your feedback on your experience using it – the good, the bad, and the ugly of it. I’d love to hear from you.

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.