Scope Creep
We’ve all worked on it. That project from hell.
The project when we started with a great idea, and it’s morphed into something else.
It typically doesn’t happen all at once. And it often happens with the best of intentions.
Any time I think of any product, especially a digital product, I’m reminded that one of the agile principles is that “simplicity – the art of maximizing the amount of work not done – is essential”. It’s so easy to add more. It’s so easy to add just one more button, one more field, one more bit of information that will help our customers.
It’s easy to add more. Too easy.
The real trick is not to add more, but to take more away. To limit the visual noise, and help accomplish a specific task. There’s a reason that one of the foundations of human centred design is “don’t make me think”. Seriously. The real trick is taking stuff away. Making it ridiculous easy to accomplish a task, without oodles of visual noise competing for my attention. This is where great designers set themselves apart from good designers. They’re able to allow me to accomplish what I need to do in a way that the technology isn’t even apparent to me.
What impresses me the most when I use an application or system is when I don’t even notice the technology. It’s just invisible, and I’m able to accomplish my task. I wrote about this a few weeks ago regarding doors – specifically what makes a door a Norman Door.
But today, I wanted to share a great video about scope creep. This is an idea that the initial concept and outcome of a project or initiative grows and grows, and as you’ll see, ends up with a product that serves none of the original needs. While it’s might be considered a great product at the end, the purpose and objective has been lost, and it no longer serves the purpose for which it was needed. Maybe that’s because needs have changed. Or maybe not.
While starting with a design thinking approach allows for something to start with a customer need, it can be important to keep that goal and objective in mind.
In any case, here’s a link to a humorous video from the movie “The Pentagon Wars”, showing the evolution (and scope creep) of the US Army’s Bradley Armoured Personnel Carrier, which started in 1968 (although the earliest specifications date back to 1958), to the Bradley Fighting Vehicle. The Bradley Armoured Personnel Carrier was put into service in 1981.
https://www.youtube.com/watch?v=aXQ2lO3ieBA
I hope you enjoy it, and can get a bit of a laugh before you go and look at some of the products your company has made, or is currently making…
No More Meetings!
Most companies I get to work with love metrics. Most love to measure things. I wish I could say that they always spend the time to understand what they’re measuring and use the information to inform their decisions, but that doesn’t always happen! Still, most companies I’ve interacted with love to measure things.
On a journey to work in a more agile way, there are a number of metrics that we can put in place.
Team Health might be a pretty good one. Not only does this allow each team to self-assess how they feel they’re doing, it allows the team to quickly see areas where they want/need to focus efforts, as the journey to help make it easier to get our work done progresses. Whether your team has developed their own way of capturing this data for use themselves, or if they’ve aligned with other teams in their line of business, or possibly beyond, it may be a great first step.
If you think you’re well along your journey, here’s a little test you can take:
Count the number of meetings you attend.
It’s an interesting metric to consider for your team. Simply counting the number of meetings you attend. That may sound odd. Bear with me as I set this up…
Your team has a clear purpose. Or at least I hope you do, if you’re well along your journey! You’re also, hopefully, following the working agreements your team has in place, visualizing your work, running retrospectives on a regular basis with improvements that you’re able to make within your own team…
So what does the number of meetings you attend have to do with any of this?
Well, the number of meetings you attend might be indicative of something. It might be a clue that your team doesn’t have the skills, expertise, or authority to deliver against your purpose. It’s a signal that maybe, perhaps, you need to revisit the design of your team, and look at the makeup of the skills, expertise, and authority your team has.
A great place to start is to consider your value stream. A value stream is the sequence of activities required to design, produce, and provide a specific good or service, and along which information, materials, and worth flows. When we look at the product or service our team provides, our value stream helps us identify how the work we do creates value. And understanding that if we’re not able to create that value within our team, it might mean there’s an opportunity to find a way to revisit the design of our team. Maybe we can enhance the design our team to allow us to make it easier to get our work done.
Not all meetings are created equal. Your daily huddle could be considered a meeting. Your retrospective could be considered a meeting. Your planning and refinement meetings even have the word “meeting” right in them! In my opinion, your regular retrospective meeting is the most important meeting you can attend, assuming you’re coming up with improvements for your team. Please don’t try to eliminate that!
In spite of the title of this post, the object isn’t to eliminate meetings! It’s to get us thinking about the meetings we do attend today, and why are they necessary. The idea to think about is making sure we have the right skills on the teams that need those skills. Being Self-Sufficient means we’re working towards eliminating – or reducing as much as possible – the dependences outside the team.
This isn’t going to happen overnight for most teams. We’re all on a journey to help us find ways to make it easier to get our work done. Having all of the skills, expertise, and authority we need as a part of our team can help us get there. But it is a journey. And it’s going to take time to move along this journey…
For now, think about the meetings you attend. Why are those meetings necessary? What skills, experience, or authority does your team not have that’s requiring you to have that meeting? What might you consider to help your team become more self-sufficient, and make it easier for your team to get great work done?
Effective Retrospectives
As with just about everything I find I’m writing, or being asked these days, there is no one right answer. This is also the case with running an effective retrospective.
But, there are some good practices that will help you get started. As with everything in the Agile world, I hope you’ll use these as starting points, and learn what work for you and what doesn’t. And figure out ways to make it more meaningful, and more valuable, for your teammates.
So first of all, let’s review why we do retrospectives?
We do them to find better ways of getting our work done. That’s pretty much it. This isn’t really the time for us to talk about our work itself, but rather about how we’re doing our work. That may seem odd. But we have demos (or sprint reviews) where we review the work we’ve done. The retrospective is our time to review how we’re working. You’ll see why this is the first point I’m going to make in a moment.
But before we get into a retrospective, it’s important to decide who gets to attend. Often, it’s the people actually doing the work. I tend to recommend that managers not be a part, because it can often cause people to not talk as freely. It’s also important to remember who the retrospective is for. It’s for the team.
Now, the team may need to rely on others to accomplish some of the things that come out of a retrospective. It’s okay to share action plans that come out, but not such a good idea to share individual comments. If you want me to speak freely, it’s got to be a safe environment where I can say what’s on my mind. If I’m concerned that what I say will make it to people outside my team, I’m going to be less likely to say what’s on my mind, and that may prevent us from figuring out what’s really going to help our team improve.
And one more thing. There’s a Retrospective Prime Directive. Even though I am a Star Trek fan, I didn’t come up with it. And unlike Kirk, it’s not something that you can violate without impacting the trust of your teammates. One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame.
Clearly such an event will not contribute to very much learning.
The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive. It says:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, an the situation at hand.
At the end of a project, or period of time, everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.
This comes from Norm Kerth, and is found in his Project Retrospectives book.
A retrospective is a key part of any improvement cycle. It’s in Scrum (Inspect & Adapt). It’s part of Kanban (Improve & Evolve; Agree to pursue improvement through evolutionary change). It’s in the Agile Manifesto (“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”). And it’s part of the PDCA-cycle (it’s explicitly in the Check section, but informs everything else in that cycle!).
It’s important. Got it. But how does someone actually run an effective one?
There are lots of options. But all of them tend to follow the following steps:
1. Set the Stage > 2. Review previous actions > 3. Gather Data > 4. Generate Insights > 5. Decide What to Do > 6. Close the Retrospective
Setting the stage is very much like laying out an agenda. Why are you there? How long will you be there? What are you hoping to get out of the time you’re together?
Review action items from the previous retrospective. This is where you close the loop from your previous retro, but reviewing the progress you’ve made and the impact it’s had on your team. It’s a chance to celebrate the improvement you made. It’s a check that what you planned to do got done, and made a difference. If it didn’t make a difference, is it still something you’d like to work on? Don’t just assume that because it was something you wanted to work on a week or two ago that it’s still the thing you want to work on. We hate to leave work unfinished – make sure you’re not falling victim to the sunk cost fallacy. If it’s not done, or didn’t have the impact you hoped, use that as an input to the next steps, to determine what your priority will be.
Gathering data can often start with hard data. What milestones or objectives were achieved, or not. What decision point were made along the way? Depending on your team, you’ll have different metrics you can use, but this is only part of the story. Feelings and emotions make up the other half, or often more than half! It’s important to capture this, and often the “soft” data will drive some amazing insights and conversations. While many of us shy away from the f-word, there are lots of ways to understand the emotions. And they’re important to helping uncover ways for your team to improve their way of working together.
In generating insights, we want to ask “why?”. We can use tools, like 5Ys, Ishikawa diagrams, root-cause analysis… There are lots of ways to use the data that’s been collected to try to hone in on opportunities for improvements. But be careful about jumping to solutions too fast! A solution to solve a problem too early in the process is often like a band-aid – it’s not actually fixing the source of the problem. It’s important to explore how events, behaviours, and circumstances contributed to whatever it is you’ve identified.
When you’re deciding what to do, you’ll want to come up with a number of possible experiments and improvements. We’re finally at the time when we’re going to narrow our scope to one, maybe two items. Any more than that and it’s unlikely you’ll make traction on any of them. Whatever you decide to do should be made nice and visible for any and all to see in a Continuous Improvement section of your visual management board. This allows you to make sure that work isn’t getting lost while you’re delivering your other work, and allows others to see what it is you’re working on improving. It never ceases to amaze me the number of times someone else is walking by a board, sees what another team is working on trying to improve, and either (a) is trying to improve the same thing, or (b) has already solved it, and can help that team.
When it comes time to close the retrospective, make sure you have a clear way to measure if your improvement experiment is successful at your next retrospective. You’ll want to start by there next time. The learning and action items that have been generated belong to the team. Not the manager. Not the coach. It’s up to the team to own the improvement for their own working environment. And sometimes, yes, that will mean getting help from others. Remember, only the improvement experiment, not the information as to how you got there, needs to be shared beyond the participants. And remember, you can (and should) make improvements to your retrospective, too.
A lot of this material comes from Esther Derby and Diana Larsen, and their “Agile Retrospectives” book. Really worth picking up, IMHO.
There are lots of tools available for retrospective formats. I’d encourage you to look at ways to make them different, so they don’t become boring and routine. Here are just a few of the many, many available: