Lean Coaching Summit

Last week, I had the opportunity to attend the Lean Coaching Summit, an event put on by the Lean Enterprise Institute.

It was a good couple of days, with lots of information, sharing of ideas, and collaboration. I took away a number of ideas and thoughts from the various sessions. But the conference started with a Lean Coffee session. I’m a huge fan of the format of Lean Coffee, because the topics discussed come from the people participating, and are voted on by the group, so the highest priority topic gets talked about first. In a matter of moments, our table of seven people had generated over 30 topics we’d like to discuss. But after a quick vote, two topics clearly came to the top, so we started on the first one, and when done with it, moved on to the second. At the same time, all the other participants at the conference were doing the same thing, at their own tables. And at the end of an hour of discussion, folks shared what their insights were, and shared them for all to see.

As I walked around the room, looking at the insights gathered, four jumped out at me, from four different tables. And while this was a Lean summit, you’ll notice that none of the ones that really resonated with me have to do with Lean or Agile specifically. Let me touch on each of these, briefly, to explain why they resonated with me.

Leadership alignment is key…
Common language
Understanding
Current culture

Alignment is key. Having a common language allows us to communicate effectively, not just with our leaders, but with each of us. But words are not enough. We also need to have a shared understanding of what those words mean. The same word(s) can have different meanings to different people. Communication, and language, depends on both the sender and the receiver (and also the medium used to communicate – I’ve read about that somewhere…). I think most companies feel like they’ve got a lot of good stuff going on in this space. I’d encourage you to challenge that assumption, and find a way to validate it’s true. And even if you think it’s good, I suspect it’s not perfect, so where can we look at our current understanding and culture, and think about what the next improvement could be.

Are we leading with tools or leading with thinking?

One of the core principles from Agile is that we value Individuals and Interactions over Processes and Tools. It’s important that we remember that Agile values both Individuals & Interactions AND Processes & Tools. Know how I know? It’s because that’s what’s written in the Agile Manifesto itself. So while there’s value in both, if we just blindly use a tool, we’re unlikely going to get much value from that tool. Take your daily stand-up, for example. If you’re not getting value from it, or aren’t sure why you’re doing it, you may have perfectly implemented the tool, without understanding the why. Tools are great to help support and push our thinking forward, but on their own, they can become ‘check-the-box’ activities, that don’t actually help us deliver a better solution to our customers. We need both, tools and thinking.

People try to optimize before they stabilize

Wow. This one really hit home for me. I’ve seen this time and time again, when we want to jump straight to (what we think is the) end state. Thinking back to the last point, tools or thinking, the reality is that it’s the journey we’re on that’s going to make sustainable, meaningful change. I worked with one manager who was great at getting short term results. He jumped directly to optimizing when working with a new team. The result, though, was that the team was full of disfunction, a severe lack of trust, and as a result, the inability to sustain the short-term performance gains the team produced. Effectively, they skipped all the hard work in changing the way the team & stakeholders thought about delivering value, and really, about building a team in the first place. This also ties back to the first post-it, about starting from a place with a common understanding of the current culture and understanding of where we are today, and what the next step could be. While we want to have an idea of the direction where we want to head, it’s going through the process and learning along the way that creates a sustainable culture and environment.

You cannot change individuals, you need to create the right conditions to allow them to change on their own.

What can I say about this? I can help with all of the tools and processes. I can tell you exactly what to do. But that’s not going to help on any Lean and/or Agile journey. No matter what I say, or what I do, it’s not going to change you. Only you can change you. Only I can change me. And it’s through learning what works that we make those changes. Now certainly, a Lean Change Agent, Lean Coach, or Agile Coach can hopefully bring some experience and expertise that can help accelerate, and be a guide on your journey. They can help play Devil’s Advocate, and offer alternative approaches to how things are currently being done. But ultimately, it’s up to each of us to set the conditions for ourselves, and for those around us, to change so that we can deliver more value.
If we continue doing things the way we always have, we’ll continue to get the results we always have. It takes new thinking, and new approaches to arrive at new solutions. But just as in the previous section, it’s about each of us going on that journey so that it’s sustainable. This isn’t about delivering great work in the next quarter, or next year. It’s about creating an environment where great work is inevitable.

There were lots of great ideas discussed at the conference. These are just four that resonated with me from the first breakout session of the conference! I hope you’re thinking about your own work, and what you can do to challenge how work gets done today, how you can help create an amazing environment to effortlessly get work done, and how can we propagate that information in helping create the right conditions to win as a team.

Agile Change

If you fail to change the way you look at the way you do your work today, all of the stickies in the world aren’t going to help you.

Can you estimate without knowing the solution?

Recently, on Twitter, a post came across my feed. I responded to it. Which generated a response. Which I really couldn’t figure out how to respond to in 140 characters or less.

The thread is on the right…

And, below is my (slightly longer than 140 character) response:

First of all, let me be clear that I’m talking about work in the obvious or complicated domains. I’m not talking about something in the chaotic or complex domain. If this doesn’t make sense to you, have a look at this video: https://www.youtube.com/watch?v=N7oz366X0-8

And why is this important? Well, because in the obvious or complicated domains, it’s something we’ve done before. Maybe not you, specifically. But someone has.
Building a 747 is a solved problem. We know how to do it. Well, not me. I don’t have a clue. But there are experts I could go an ask, and since they’ve done it, they can help me. There might be different ways to build it, do things in a different order (again, I have no idea), whatever – not the point. My point is that if someone were to ask me to build a 747, I could provide them with an estimate to do that, without knowing exactly how I was going to do it, by talking to the experts who have done it before, and solved that particular problem.

Let me get out of 747’s, and into a domain where I have a little more experience…
A few years ago, I was asked to provide a quote to a potential customer on the cost to build a web application, with specific functionality and usability requirements. And to be clear, I had never build this specific web application before. But, I had been part of teams that had built other web applications, with similar functionality. So I could apply expert judgement, and validate some of the assumptions I made with others on the team who had also built similar solutions for other clients. And we did. We ended up with an estimate for time and cost, and we wrote the SOW with enough latitude that we could adjust the specifics of the scope along the way. Not for our benefit, although it did work out well for us. But really for the benefit of our potential customer.

You see, we’d built similar applications in the past. We had an idea that what the customer was asking for wouldn’t actually be what they wanted once we got started. And we were right. It was on day three of the project when the customer changed their mind on something, and wanted an additional section to be added. No problem. We weren’t contractually obligated to deliver on any specific item. What we were on the hook for was to deliver a web app to help them solve a business problem.

And when the customer asked for changes, on day three, we were able to have a meaningful conversation of what that might mean to the overall project, and allowed us to look at ways of providing a better solution to solve their problem, and meet their needs. We spent a lot of time over the course of the project, working directly with the customer to build something that would work for them. We re-architected aspects, change the information architecture, created an enhanced UI, and made their initial UX designs far superior & easier to navigate and use. None of this was scoped explicitly at the outset. But we still provided the potential client an estimate.

Our estimate, which fed into the budget and allowed us to earn their business was a key in this process. It provided a budget for the customer to decide if they wanted to start the project at that time, or hold off until a later date. We didn’t need a specific solution. We just needed to be 80% confident that we could deliver something that would solve their problem, in the time they wanted it, for a price they could afford. And yes, we told them that our estimate was likely off a bit, but that we were willing to assume the risk through a fixed price contract. Remember, we’d done very similar work before. We were clearly in the complicated domain for our team.

There was a  huge industry convention coming up for them, and they wanted to feature their new web app at that convention, if they could.

So, estimating a solution depends on how you define the word solution. Going back to the initial tweet, that “behind an estimate there is the assumption that any piece of functionality has only one possible implementation”, is flawed if you mean defining how, specifically, we’re going to solve the problem.

Providing an estimate, in this context, as to what problem we’re going to solve, actually frees the team to come up with any solution they can imagine, while providing a constraint that something needs to be done by a certain date. And, that it’s all based in actual historical data, so it’s not just a wild-ass guess. An estimate doesn’t need to be based in a single solution, and thinking it does constrains the learning and ongoing conversations that can and should occur during the development. I’d suggest that if this isn’t the case, you might be doing it wrong.

I’m a huge proponent of #NoEstimates. I believe there are lots of better ways to make decisions, and make shared, informed choices about how we spend our money. I also believe that not everyone is on that same page. And that, in certain contexts – like this one – an estimate can be a good thing. Without that estimate, our potential customer would never have become our actual customer. No one wins in that scenario. By providing a simple estimate in this case, we were able to earn the business, and deliver an exceptional product about 20% under budget and 22% ahead of time. Oh, and as a fixed-price contract, that went directly to our bottom line. Happy customer. Happy business. Happy team.

When we’re in the complex or chaotic domains, I think you’ll have a tough time convincing me of the value of most estimates. But when it’s a solved problem – something we know how to do – an estimate can not only be quite accurate, it can be quite helpful. We need to be aware that sometimes, when we think we’re in the obvious or complicated domains, we’re not actually in the complex or chaotic domains. It’s often tough to tell. And, I’m not content with the status-quo, so I’m always going to be looking for ways to challenge anyone who says “well that’s how we do it here”. In this case, I’m pretty happy with the choices we made, the estimate we provided, and the result we delivered.

We need to be careful with absolutes. There can be a time and place for anything and everything. We should continue to question everything in order to continue our quest to find better ways of working together, making decisions, and solving problems.