A short Twitter Drawing following up from my blog post about how great teams work:
— Cory Foy (@cory_foy) March 12, 2018
A short Twitter Drawing following up from my blog post about how great teams work:
— Cory Foy (@cory_foy) March 12, 2018
Nearly my entire adult life I’ve traveled in some form or another. In a band you drive on tour, and even when I was dating my wife I would drive from Florida to Virginia nearly every other weekend. So when it comes to traveling I have a very experienced sense of what it’s going to take when I decide “drive or fly” – and usually that means I drive if I can get there in 5 hours or less.
In our organizations, we face similar decisions – typically the “build versus buy” decision. When we want to do something we have to figure out whether we start an internal initiative to build it or purchase and configure something from a vendor. Or in a larger context, whether we simply acquire someone already in a space we want to be in.
In the book Stand Back and Deliver: Accelerating Business Agility Kent McDonald and Neil Nickolaisen present a model called the Purpose-Based Alignment Model for aligning business decisions around one of two purposes – market differentiation or maintaining parity based on the mission of the business.
The goal is to help us figure out how we should make certain “plays” in our business. I’ve talked before about developing a map to understand what plays were available in a hypothetical situation where the CEO has come to us wanting to do “something in the Internet of Things space”. At the conclusion we had the following map:
We also said we could make a play for the measurement, configuration and communication components. But what wasn’t answered was how we should make those plays. Let’s place those components into the various quadrants based on who we are as an organization:
Does this mean we shouldn’t buy things to help us with components in the Differentiating quadrant? Not at all! Instead it means we shouldn’t just outsource it – we need to own the Intellectual Property so we can drive the evolution of the component. Basically we want to develop the capabilities in those areas, so we should invest in building those capabilities out.
Taking together with the Wardley Map we can see that so far we have a strong agreement that the play we can make is in the Configuration and Communication spaces. And we have a sense that rather than purchase that capability, we should own that expertise in-house, either through building it, or acquiring a company who has it.
On a lower level, I tend to use this model as a way of helping smaller organizations figure out where to spend their time. For example, if their strong innovation comes from user experience, then they may find strength in partnering for development. However, if the innovation comes from the development they are doing, then they should focus on growing it in a high-quality way.
For more information I’d recommend picking up Stand Back and Deliver: Accelerating Business Agility or skimming Kent’s article on it. You can also watch a talk I gave on combining mapping, purpose-based alignment models and the Business Model Canvas. Finally, if you’d like help mapping your organization, give us a shout!
From time to time people on Twitter ask me things and I record a little video about them. This first one came from Susan Almon who wanted to know my thoughts on Scrum:
Ok, so @susanalmon asked me for my thoughts on Scrum. Here's the first go at this. Also, here's the blog post I mentioned in the video: https://t.co/Vs0R8X8NbG (also learning the size limits of Twitter, so the first couple seconds got cut off) pic.twitter.com/n6RMZpcRps
— Cory Foy (@cory_foy) March 5, 2018
Ever seen an island in a lake in an island in a lake? This unusual combination exists, and you can go check it out. I included a map above for you to find it. Go ahead, I’ll wait.
Did you find it? Chances are, the “map” I gave you wasn’t very useful. It showed the picture of the feature I wanted you to see, but didn’t include any context as to where it is at in the bigger picture. Nor did it include any sense of direction to know how you can get from where you are to where it’s at. If instead I gave you a link to the Google Map of it, you could then zoom out to understand the context, and plot where it was in relation to where you are.
We often operate as businesses with similar types of limited context. We have a feature that sounds great, but no sense of how we get there, or whether that would be the right thing to do with what we have. For example, if you are in Europe, you’ll need an airplane (or at least a boat!) to see that particular island. But if all you have is a bicycle, then you might want to look for something a little more accessible.
A couple of years ago I gave a talk about figuring out what things a business should go after. It started with the notion of mapping the landscape and what options were available – known as Wardley Mapping. The basics are that you start with the needs of the situation, visualize the components needed to meet those needs, and then map out how those components evolve to understand what “plays” you can make.
Let’s say our CEO wanted to get into the “Internet of Things” space starting with a device that lets people measure the weather and automatically report it back (We’re leaving out the process we used to come to wanting to do this, which in most businesses amounts to basically throwing darts). We’re supposed to start with user needs, but since “IoT Device that Measures Weather” is our charter, let’s start there.
In the above image, the Customer “needs” an IoT Device. But from there we start getting into some interesting things. The IoT Device needs ways of measuring the weather, configuring the device, and communicating the measurements. In turn, communicating the measurements requires a server to talk to, WiFi to talk over, and security to make sure no one hacks in. Of course, both the Server and WiFi require a Network to talk over.
At this point we’re only marginally better than the initial Google Map image we started with at the top. Sure we have a pretty picture, but it’s not telling us much. So let’s add the concept of motion – or in this case, evolution.
Now we have something interesting. It turns out that there aren’t really any measurement devices out there for IoT devices, so it’s in its Genesis. The IoT Device – along with configuration and communication – all exist, but need to be custom built. However, the protocols for communication, including WiFi and Security, can all be purchased as Products, and both the servers and networks we’ll talk to are basically commodities we can just use.
It’s interesting because we start to see where we can make a play based on who we are. For example, one should never get into a land war in Asia, nor should one fight a battle for something that’s a utility unless you have the resources to back it up (For example, Verizon has products specifically for IoT networks making that probably not a good decision to break into as a startup).
But the measurement, configuration and communication pieces will all eventually evolve into products. That means we can have a strategic advantage by figuring out how to lead and accelerate that evolution. So while measurement might not be something a lot of IoT projects would need, they almost all would need Configuration and Communication.
How we make those plays depends upon many other elements, such as how they align with our business purpose, and how they fit into the capacity we have. But at least now we know how we can dazzle our CEO’s desire to have an IoT weather product – while still making it something that stands a chance of being a smart play into the space.
If you’re interested in learning more, start with Simon’s introductory mapping post as well as his book in progress. You can also see the slides and videos from my talk. And if you’d like help understanding your organization, give us a shout!
Update: I said above that seeing the evolution is “interesting” – so I recorded a little video to dive into that a little deeper:
I make the statement in https://t.co/FRDOphc1ea that seeing the evolution makes us able to "make plays" into the market. Here's a little more detail on what I meant by that: pic.twitter.com/kECzZx8Rpa
— Cory Foy (@cory_foy) March 5, 2018
One of the hallmarks of effective teams is trust. This applies not just to the interpersonal relationships between team members, but also to the relationship the team itself has to other teams and the rest of the organization – especially management. In a low trust environment, any attempt to bring about new changes, especially from an external perspective, are going to be hit with a double-whammy: People are naturally resistant to change, but especially when they feel they don’t trust the reason, or the change is being brought onto them without any recourse.
To help overcome resistance, one of the first things I establish in organizational change is a mechanism to give teams control over their destiny. I want it to have several components:
1) It must be a “heartbeat” review – something that happens on a regular cadence the team expects
2) It must be driven by the team
3) It must look at what the team expected to happen
4) It must let the team decide how to change things to fit their operating model
Taken together, teams can rapidly discover how to incorporate surprisingly significant change in a short amount of time. The specific process I use follows the concept of a retrospective – but I’m often quick to point out that what teams normally call a retrospective usually ends up as a gripe session rather than a regular opportunity to reflect on processes the teams want to try. Done well, it encourages the notion of experimentation, because no process is ever permanent.
For example, let’s say someone on a team wants to introduce the concept of No Estimates – breaking work down into similar sized chunks – to their team to help solve some issues they are having with sizing things in story points. The team agrees to try it, and at their first retrospective two weeks later they review how it’s going. The facilitator first starts with a simple 4-column board:
The team starts with the first column: Expect. The facilitator asks: “What did we expect to happen over the past two weeks?” The goal of this column is to review the hypothesis of the experiments we took on during the last cycle. In this case, the team expected to see a reduction in time spent estimating stories.
Next, the facilitator asks the team to talk about the things that went well. I find it important to start with the good in sequence – especially in a low-trust environment – to get people focusing on positive things initially. The team mentions that it felt freeing to not have to size things from a relative perspective, and that the goal of decomposition made it clear what their goals were.
With the positive elements identified, the facilitator now moves on to the things that were not so good. The team mentions that it was not always easy to get things into similar sized chunks without splitting things arbitrarily. It also felt like they got less done because when they counted the number of stories completed it was a lower number than the story points they normally complete.
Finally, the most critical portion of the retrospective, which is what experiments the team wants to run this cycle. In this case the team agrees that they found the previous experiment fairly interesting, and feel like they still have some learning to do to get No Estimates right, so they want to keep the experiment going for another cycle, along with trying some different decomposition strategies.
This process creates a feedback loop where every process the team uses is only ever in place for one cycle, giving them the opportunity to not be afraid of trying something new and that thing being now forever a part of their process. For example, maybe a team feels standups aren’t useful, so they can try not doing standup for a cycle. Or they want to try pairing, or Test-Driven Development. All of these things can be attempted for a cycle or two, with feedback going to the whole team about how it is going.
While the cycle feels very Scrum-like, one doesn’t need to be doing Scrum to have cadences. A team doing Kanban, or Waterfall, or any process can still establish an explicit policy of having a cadence for retrospectives. In addition, teams may choose to have additional retrospectives to focus on different areas – say, after a release which may incorporate additional exercises. I’d recommend the excellent Agile Retrospectives book for additional retrospective ideas.
Finally, any kind of retrospective does rely on some degree of interpersonal trust within the team. If your team doesn’t have that trust, or it’s a high-emotion retrospective then it’s going to take a little more time to establish that trust. Members want to see that they are going to be heard, that action will be taken, and that they won’t “get in trouble” for their thoughts. I generally recommend bringing in an outside facilitator – either an external facilitator, or at least someone from outside the team. But regardless, as the facilitator you have to make sure that your role is actually facilitating, and not participating. If you feel the need to jump in, be explicit to the group about switching roles, and maybe let someone else facilitate.
Change can be quite difficult, but establishing a process where people feel in-control of the cadence and application of that change makes implementing significant change that much easier. Keeping that process regular and consistent helps increase trust and familiarity. That trust is extended when people understand what they expect to get out of the change, can discuss the impacts, and have direct input into how to best implement the change in their sphere of influence. Taken together teams can come together and make amazing things happen.
For many people, the word “Waterfall” causes a visceral reaction – especially in the context of projects and organizations. Unfortunately, I’m starting to come across more places where “Agile” causes the same reaction of disgust and fear. The fundamental problem is that we’ve let bad management hide behind methodology and frameworks.
At their core, Waterfall, Agile and Lean represent three modalities of project delivery – either Sequential (Waterfall), Iterative/Incremental (Agile) or Continuous (Lean/Kanban). If the problem space you are delivering within is well-known and needs a sequential process, then use one! For example, if we have to move a group of people from one office to the next, there are defined tasks that have to be done in certain timeframes in a certain order. Or perhaps we are adding analytics to an existing application, but we know what the analytics are, where they need to go, and the order we want to implement them in. Again, a good fit for a sequential process.
But what if we aren’t so certain about the order or value? In that case, we want to decompose the work into increments, each capable of allowing the realization of value once deployed, and then build it iteratively – a great fit for a number of agile processes. For example, we used to cook over 2,000 lbs of barbecue chicken for the 4th of July. We would divide the chicken into increments – basically as much as would fit onto one cooker – and then constantly inspect the chicken and adapt to the conditions. We would then pull chicken off one cooker at a time, and once off, the chicken could immediately be sold (value realization!).
Or maybe we have a software project where we know the overall value potential, but not exactly how to build it. In that case, we want to see how we can divide the goals into increments that help test the value potential once released, but we still want to build the pieces inside of it iteratively, constantly inspecting and adapting so that the discovery process doesn’t slow us down.
But what if we aren’t even certain of the value – or even if the idea we have can be built? In that case, we don’t have the ability to define value criteria or increments – we instead have to focus on continual delivery and discovery to find the business model or business value case. This is common in startups where an organization is searching for a repeatable business model. There’s a notion in kitchens of tasting as you go to make sure you have the right balance of spices or flavoring – an example of continuous delivery. Or maybe we’re attempting to disrupt a legacy market, and don’t know exactly how customers are going to react, or what they may even need. In that case, we need a model for continuously testing, iterating and responding.
When we step away from the words, and we instead focus on the modalities – sequential, iterative/incremental, continuous – we can even start to see how things can be combined. For example, maybe we do have a sequential process, but we can still focus on decomposing and delivering it in increments. Or maybe we need an iterative cadence, but want to deliver continuously.
One of my favorite conversations was with a director of a $50mm project I was coaching. He had just taken over the entire project, and I was talking to him about agility. “I don’t believe in Agile,” he told me, “because I’ve been plenty successful with waterfall!” I asked him to tell me how he was able to see such success in waterfall projects, when so much of the industry talked bad about them. He said, “Well, we would define and lay out the plan, and every 2 weeks we would inspect the plan against what had actually been done, and then adjust the plan based on what was actually happening.” I told him I would happily do that kind of waterfall!
So don’t try to “Be Agile” any more than you should try to “Be Waterfall”. Instead focus on the modalities that make sense for your project and organization, and how the principles, values and practices from other modalities can be combined – so you can “Be Successful”.
Along the path towards agility inevitably one comes across the terms iterative and incremental. I have seen many cases where the terms are used interchangeably, even though the mindset behind them is pretty different. To understand how, let’s introduce Roberta and the Church Analogy.
Roberta (in our analogy) is the lead pastor for a rapidly growing church. Her current congregation is usng every inch of space in their current facility, so they know they need to expand and build a brand new campus. But she still has to balance repairs and upgrades to their current facilities, since those are going to continue to be used while the new campus is being built.
In our organizations, this duality of building a new campus versus maintaining the current one comes across as building new features (or gaining new capabilities) versus maintaining existing systems or running the business. Some percent of our budget will be used to fund maintenance (sometimes called “Keeping the lights on”), and some percent will be used to fund things that will help grow the business. The goal as a business leader is to make sure that the funding percentages balance out the needs, and that what gets funded in each bucket is done in a way that moves us forward as quickly as possible.
So back to Roberta. She has a plan for handling the existing buildings, but is trying to figure out the best way to tackle the new campus. She has a list of all of the things they are going to build there:
Right now they meet at a local school, and they have office space they are renting, which also has a hall they can rent out for special events.
The above list are incremental pieces of the entire vision. By completing any one of these, the overall vision gets moved forward. But which one should be first? Or should they build them all before taking advantage of any of them?
To answer that, Roberta and her team of leaders needs to know what their needs are as an organization. She knows they want to grow the number of people that can attend (and for sure not lose anyone because it is too crowded). She also knows that the current flow on Sundays doesn’t work well because, well, they’re meeting at a school that was not designed for their needs. She also knows that if they keep growing and not moving, they may run into fire code problems with too many people. And finally, all of the money they put into the school is money not going towards their future.
These criteria can be mapped to the kinds of things businesses look at:
With her criteria in mind, Roberta and her team rank the things they want to build:
Roberta and her team feels great about this ordering. Within 12-14 months they’ll have a fully complete multipurpose building with a gym, classrooms, and amenities.
If only they hadn’t stopped, they would find an even better solution.
It turns out that one of the big gaps in the community they serve is a lack of soccer programs for youth. There are several programs they can partner with that would draw in a large group of people who could all be potential attendees of the church. But the season starts in 5 months, and they aren’t planning on even starting the activity fields until after the gym is built.
Looking at the requirements for the soccer program, they have the following requirements:
Taking the multipurpose building as a whole, Roberta’s team can work with the contractors to figure out smaller pieces of it they can build. The contractors state that the entire foundation has to be poured at one time, but they could then build just the bathrooms and extend the rest of the building from there. There would be a slight increase in cost to do it that way, but they could have the foundation and bathrooms done in 2 months. In the meantime, Roberta talked to the contractors about the fields – they could easily build a single regulation-sized field in two months – it wouldn’t have the lighting systems in place or the sprinkler systems, and they may have to dig up the field after the first soccer season to install those.
What is happening here is that Roberta and her team are taking the initial increments and understanding (with expert help) how they can be decomposed into smaller increments. They are then looking across all of the areas and composing a minimum increment that will solve a need or gain a capability for their organization when it is done.
With a plan locked in place, Roberta funds the plan, and work begins. The foundation pour goes very smoothly, and the walls begin being built. One afternoon the contractor calls Roberta and her team to the job site:
Hi Roberta! I know that we’ve spent a lot of time looking at plans, so what I wanted to do was have you take a peek at the progress early on to make sure this is looking how you imagine. I had the brick layers build up just to the door frames and window frames, and given where you have the activity field, I wanted you to see if this matches what you expect.
This action by the contractor involves building the first pieces iteratively, by putting a little in place, and then seeking feedback. The first iteration – putting up the door frames and windows – doesn’t give a completed increment. But it does give room for feedback from the customer (in this case, Roberta) and encourages everyone to be on the same page before moving forward.
Similarly in our organizations, we want to strive to be as iterative as we can in building increments. Specifically we want to build small slices of functionality that can be shown. My dear friend Jared Richardson refers to this as Tracer Bullet Development where each iterative slice gives us increasing information and confidence that our increment is on target. Even though the contractor could have built out all of the walls before seeking feedback, by doing the minimum he could in as integrated of a way as possible, he allowed rapid feedback and adjustment – even in a construction project!
Roberta was able to take advantage of a new opportunity by knowing what her goals were, what capabilities were needed for those goals, what increments built those capabilities, and how the increments themselves could be decomposed across her vision into smaller increments, and then composed together in a new way. Once the increment was funded, her team was able to take advantage of the contractors iterative approach to update things with new information.
It can be easy for organizations to do an initial decomposition into ideas, call those “increments” and feed them to teams, especially if those teams are building it iteratively. But as we saw with Roberta and her team, being able to go one step beyond that – knowing the capabilities, decomposing the increments themselves and using the visibility across the portfolio to recombine them into increments that form exactly what we need to take advantage of market opportunities – is a level of agility that can transform businesses.
In my last post, I gave some examples of the difference between Implementing Agile and Transforming to Agility. But like the term “Agile”, agility is an often overloaded term that means different things to different people.
When I talk about agility to clients, the conversation focuses on the agility of the business, which is different than, “we’re delivering what the business is asking us in an agile way”. Organizational agility goes far beyond the team and encompasses several different areas:
@jfraser Example: a business can have agility if Biz is agile and IT is not (generally by firing IT). But not the reverse.
— Cory Foy (@cory_foy) April 12, 2017
Woven throughout this is the principles of Lean Thinking – how quickly and smoothly things flow through the cycle, how we visualize bottlenecks, and how we continually learn and improve.
Amazing things happen just by gaining agility at the team level, or scaling the team level. But a business firing on all of these cylinders is an amazing thing to watch.
Implementing Agile practices is easy:
(Manager to team): “You have new roles! You’re the ScrumMaster, you’re the Product Owner, and the rest of you are the team.”
(Manager in meetings): “And we’ll have these new meetings! You all will get together once a day to talk about your progress, and every two weeks you’ll show the product owner what you’ve done, and she’ll tell you what’s next”
(Manager shaking paper): “And I expect status updates via updating the backlog and the Scrum board!”
With those things in place, a team can claim to be “doing Agile” (or, at least, doing Scrum). But our goal is not to be doing Agile, or Scrum. It’s to have agility, to transform our work.
In the book “Managing Transitions“, William Bridges talks about his model of change versus transitions:
The starting point for transition is not the outcome but the ending you’ll have to make to leave the old situation behind
So while it’s easy to implement agile, the transition to agility for a team is hard:
(Manager to team): OK, so team, I need you to stop doing things sequentially, and instead work together collaboratively. That means stop with silos, stop doing big design up front, stop doing test last, stop digging in really deep without thinking about what the goal for the next two weeks is, and stop hiding from the team.
(Manager to business): I also need you to stop throwing things over the wall and handing over completed specs. We want to collaborate on the solution, so stop wanting absolutely everything as well as waiting until the very end to review.
(Manager to managers): And I need you all to stop assigning tasks, doing performance reviews based on individual contribution, siloing teams, and demanding detailed status updates
(And yes, it’s all relative – if the “implementing” part is hard, then transition is exponentially harder)
If transition is what you are looking for, then get in touch today!
“This is awesome!” Jenny, the Product Manager exclaims to the team. “We’ve been having some challenges retaining customers, and I think we’ve got just the right idea of how to fix it! It’ll require a little retooling of our sign-up flow, but I think the impact will be incredible.”
Great ideas are some of the most powerful accelerants there are. Lighting one off produces a great burst of energy, light and acceleration. But like great accelerants, it burns out very quickly if it doesn’t have clear direction and sustaining energy. Ideas in software can be especially fast-burning as we try to convert an idea into actual, working software. Not only do we have the idea itself to contend with, we have to integrate it into systems that probably weren’t conceived with the notion of this incredible new idea. That can lead to friction, bugs, and downright failure to launch.
Having worked with many teams like Jenny’s, there’s a common flow I’ve begun sharing around the notion of how we can take ideas in all their uncertainty and get them to production with a high level of confidence. This isn’t a new model by any means, but highlights where steps should be at and a flow that has worked well with teams I coach.
We start with a wide interpretation of what the idea is. We take steps during development to focus that interpretation into a clear, releasable chunk. Once we’ve committed the feature, we have a clear of idea of what we wanted to build, but not a high confidence that is working as we intended. So the second part of the diagram moves us to that high level of confidence by using the work we did to gain understanding and clarity to also gain confidence.
Let’s dig a little more into these steps.
At the top, we start with an idea. We write Acceptance Tests to capture the high-level goals. This is ideally automated (using something like Cucumber or FitNesse), but can also include things like “We expect to see a 3% increase in conversions”. The point here is to develop concrete, measurable business objectives and goals for the outcome of the feature.
As we’ve begun capturing our acceptance tests, the team starts looking at how things integrate into the system, using Integration Tests. Here we think about how the feature will be put into the system, and write tests to capture what will happen once the feature has been integrated. These will not be passing, because the feature hasn’t been written yet, but will begin letting the team think through the integration questions and challenges.
Similarly, if we’re integrating into an existing system, we may need a series of Regression Tests to capture how the system works now to make sure it continues functioning as expected. For example, if we’re adding a new module to accept gift cards, we may need regression tests around calculating tax, or total costs when there is no gift card. This gains us confidence that the new feature won’t have unintended side effects.
In parallel, the developers will start writing Unit Tests (ideally using Test-First Development) to capture the behavior and functionality of the code they want to write. These tests are focused at a low-level of functionality, and help drive out the design of the actual feature. These are paired with writing the code for the feature itself.
Finally, many teams use a Code Review process to look over the feature. This could be done in real-time using Pair Programming, or through a Pull Request process, or just simply emailing team members. The goal here is to think through the logic from an outsider’s perspective, and also give information about how it integrates with the system.
With our tests written, our design reviewed, and our clarity sharpened, we commit our code and begin our deployment cycle.
Throughout Development, we write tests at various levels not just for testing purposes, but to drive out the understanding of how the code functions and integrates into the system. But at some point we need confidence that we’ve done what we needed.
So once code has been committed, it begins a workflow of gaining confidence. Immediately after code is checked in, the unit tests are run. This gives fast feedback about whether we’ve broken anything, or impacted code quality. We can also run Static Code Analysis, Security scans or other tools to make sure we’re following our team’s standards.
If our unit tests pass, we can now start digging deeper into the viability of our code. We start by deploying it – ideally to a test or staging server. These servers will have the data and access to run scenarios. We can then execute our integration and regression tests, ensuring our system is functioning as expected, and finally executing our acceptance tests to make sure we’re meeting the business needs of the feature. If all of these pass, we’ve widened our confidence in the feature.
So while this is laid out as a single workflow, the idea is to use automation and close collaboration to keep these cycles continually flowing. Being able to know within 10 minutes that a change a pair made to the code impacted conversion rates is a life-changing thing for many teams, allowing them to respond very quickly to the needs of the code – and the business.