In a recent workshop on inceptions I was reminded of a few things and it highlighted to me a couple of risks associated with doing an inception over an extended period of time.
- It’s easy to forget stuff.
- It’s easy to assume that because you know something, everyone else in the team does too.
The session was a timely reminder for me of the goals and outputs we should be expecting from a well run inception. I still believe that there is a right context for running the inception for a project as series of smaller workshops. We don’t have to take a large group of people out of their jobs for a significant period of time, and it allows us to target the sessions with just the right people present. However, we do have to work a bit harder at sharing the output from those sessions, and we have to be extra diligent in making sure that we have covered everything and that we are able to go back over important or risky aspects of the project as many times as it takes to get things right.
It’s easy to remember to work on project scope. Right from day one people are thinking about functionality and a set of epics or stories. It’s harder to remember to keep your project context up to date (Why are we doing this? What is the problem we are trying to solve?). It is also easy to forget things like Non Functional Requirements, Test Plans, Communication Planning, Domain Modeling and Roles & Goals.
I think the important take home is that no matter whether you are incepting in a two week “Event” or doing it as a series of smaller sessions the important thing is to plan, use your checklist of things to cover, and be diligent about doing them. Don’t just “Start” your project until you can demonstrate readiness.
A lot of us have read and practiced Agile and Lean. So much so that we sometimes forget a few things. I was reminded of this recently when looking for ways to cut some inefficiency (waste or “Muda” in Lean-speak). Put simply, I messed something up.
A cut in one part of our development process that aimed to decrease waste, and make us a little more efficient threw things out of balance, causing the whole process to become unstable. Think of an engine running on three out of four cylinders. Wondering where I’d gone wrong, I went back over the whole process and I realized that I was ignoring “Mura” and “Muri“.
So, here’s a refresher for us all… Mura refers to unevenness. Muri refers to overburden. You can’t overburden one part of a team without upsetting the overall throughput. When we are planning we need to remember simply cutting waste is only a part of the picture. Further, the best way to cut waste is by first focusing on quality, unevenness and overburden on our “production line”. Work on Muda by first examining and working on Mura and Muri. There’s actually a lot written on this subject but it seems to be too easy to focus almost exclusively on reducing waste. If you do this, processes will simply become more and more brittle, and like a bone that is brittle, once it breaks it will take longer to heal. Recovering from a break in a brittle process is harder than recovering from a robust, fault tolerant one with some redundancy built in.
I’m seeing symptoms of this “calcium deficiency” in teams I’m dealing with currently. Hard work and excellent people are providing throughput that masks brittleness in the underlying process. A lack of attention to resourcing in the QA space has lead to a situation where the QA group is being successful, but only by hard work and diligence. We’ve forgotten to “work smarter”.
Eli Goldratt’s Theory of Constraints supports this thinking. Rather than trimming fat from already efficient parts of our process, we should be looking to bolster the weakest areas.
Fixing the problem now will likely be less costly than waiting for the inevitable break…
I wrote this post as a third installment when we were moving to a Line of Business Prime model. I published it on our corporate intranet to provoke discussion amongst the teams about the process and how things were unfolding for the different teams. I’ve highlighted some of the techniques that may seem obvious to some readers but that were new to parts of the organization…
Our project has now moved on from the “Iterative Inception” and the project proper is now underway. With this in mind I thought it would be interesting to reflect on how things have started and especially how the inception process has worked for us.
I wrote this post as a second installment when we were moving to a Line of Business Prime model. I published it on our corporate intranet to provoke discussion amongst the teams about the process and how things were unfolding for the different teams. I’ve highlighted some of the techniques that may seem obvious to some readers but that were new to parts of the organization…
After our first Line-of-Business project, we were ready to ramp up for the second. This new project set out to introduce a online product for our Line of Business. It was expected to take approximately 9 months in total duration.
One of the lessons learned from our work on our first LoB project was that starting work before you are really ready is risky, and will cause churn at best. Sometimes there is an art to choosing when to start, and we got it wrong. To mitigate against this we didn’t want to do a single, big bang “inception”. This was proving difficult as we are constantly being asked “when is the inception?” by people who are now used to this as the only way to kick-off a project. I’m against doing a single inception at this point as I think that the expectation will be that as soon as we finish the inception we will be ready to start, and suddenly we’ll find ourselves trying to work off an immature deck of story cards. I know that a well run inception can give you a good base to start a project but often, an inception seems to serve only to identify more questions than answers, and often introduces noise into the project space that is not squarely aimed at the core of the problem we are trying to solve.
So what did we do instead? After the experience on our first LoB project, we felt that the balance had tipped too much towards “Just Start!” and too far away from thinking and planning. Of course we didn’t want to go down the path of simply analysing everything too much and fall into a more waterfall pattern so instead we have adopted an iterative approach to inception. The process is simple. Assemble a core group of people representing product, sales, IT, and design. Allow them to learn and agree on the whole project – it’s important that they all come to understand each other’s domain to some extent. Have them create and design solutions, and share them back to the group as many times as possible. The “special sauce” is knowing when you’ve done enough within the group, and when to share what you have with a wider group. So far I think we have managed to strike a good balance and we are beginning the process of sharing our “solution” with a wider audience. We’ve also been careful to present the solution as a “work in progress” in the hope of encouraging thought and new ideas, or perhaps more importantly, a better understanding of the ideas we already have. It’s important to remember that this product has been mapped out and relatively well understood for over 6 months.
We’re trying to achieve the following goals:
- We want the concepts to be well thought out, and to have a well rounded understanding of the problem and our solution.
- We want the core group of people involved currently to have a shared or unified vision of the product and be able to articulate it.
- We want all aspects of the development of the product (product brief, success measures, design, technology, go-to-market) to be at a similar level of maturity before we start. On our previous LoB project we had hi-fidelity designs that fooled everyone into thinking that we had a well designed and thought out solution.
We had an “inception” within the IT team, although by the time we did it, it was more of a “kick-off”. The team knew what the product was, why it was being built, and how we planned to go about it. The Kick-off decided some of the detail of that process. Even with this in place the unanswered questions came through thick and fast. Importantly, when we started we expected to be all lined up, and ready to race at the same time, with a shared set of expectations and outcomes.
So far we haven’t developed a set of objective measures to tell us whether or not we are succeeding in achieving our goals for this part of the process but (and this is experience talking) everything “feels” like it is close to where it should be…
A common problem I’ve experienced in delivery is that you are often asked to give a “rough” estimate on something the team knows little about. If you give this estimate you know that at some point, probably months away, it’ll be back to haunt you – “but you said this would take 12 weeks!!!” (forgetting, of course, all of the simplifications and assumptions that were made at the time). The same problem exists when you do a first round, or rough estimate using the same points that you use during development – an expectation is set regarding timeframes or effort that can be hard to reel in when you find out later that scope has changed, things weren’t as they seemed, or you were just plain wrong.
I wrote this post as a first installment when we were moving to a Line of Business Prime model. I published it on our corporate intranet to provoke discussion amongst the teams about the process and how things were unfolding for the different teams. I’ve highlighted some of the techniques that may seem obvious to some readers but that were new to parts of the organization…
Over the last year we’ve been moving to a “Line of Business” prime model for delivery. Essentially, this means that within IT we have structured our teams so that they are able to complete entire products or functionality with minimal input from other teams. This means, for example, reducing our dependency on a team of operations people to deploy our applications and set up environments by having dedicated, embedded dev-ops people. This idea has been around for a while but this is one of the first times I’ve seen it really start to work.
One of the first projects to be developed under the Line of Business model within our IT group has provided significant insights into how this might work (and how it might break. Although there have been significant business challenges to date this post is aimed at identifying the main challenges we faced within the team and some of the tools and activities that helped us mitigate risk along the way.
So what were the challenges? At a high level, we needed to integrate work in three different technology stacks with a team that had expertise in only one (or two depending on how you count them). All of this had a specific date target (this was a classic “Plan Backwards” project).
1. Context is Important.
The first thing that we realized was that context is important. The team needed to work across different technologies and it would have been very easy to become bogged down learning unnecessary aspects of the new technology if they didn’t have a clear picture of what we were trying to achieve overall. This meant running plenty of context setting planning sessions and aiming for a very business driven development framework. The business sponsors were heavily involved at this point. In retrospect, given the significant amount of “evolution” of the features (mostly from a design and UX point of view) we may have been a little early with our designs – it would have been better to build a more “bare bones” solution and deliver it early rather than trying to get everything perfect right from the start. This idea won’t be new to anyone with some agile experience but we did fall into the trap of believing that we had mature designs up front (or maybe that getting the UI to look like the designs would “just take a few tweaks”. Having said that, because the entire team had good context for the development we were able to ask the right questions and adjust, remaining relatively focused on the “important” stuff – it could have been a lot worse.
2. Ask for Help Early.
The next most important lesson was regarding the technological skills within the team. The lesson is to ask for help early. In the same way that having a good understanding of the business context helped us stay focused, having technological help when we needed it (early) meant that we focused on learning the important things first. Having a member of another team come and pair with us facilitated this targeted just-in-time training. This may seem obvious but it is important to note that the timing of this is important. We needed help the minute we sat down to design, estimate or code – not a week before, and not a week later. To achieve this we had to rely on the cooperation of several teams, each with their own deadlines and priorities – this tested our cross departmental altruism at times. It was difficult, even with high levels of cooperation to get more than a few hours of anyone’s time. I understand why, but I can’t say strongly enough how important it is that we support this kind of activity, as it is key to building the Line of Business teams.
A second view on this same theme is the (not new, but often ignored) idea of co-location (or, more specifically, embedding). In this context I mean having someone from another team come and physically embed in our team for the duration of the project. This is one thing that we didn’t do well and need to learn from. We had a member of another team (from another floor in the building) come up to join us but initially we didn’t sit them close enough to us, and we didn’t involve them heavily enough in either what we were working on or how we were working. We fixed this about two thirds of the way through the project and the results were spectacular. Efficiency within the group sky-rocketed once we really embedded the “stranger” and we saw true collaboration. The lesson – if you’re going to bring someone into the group, don’t do it half-heartedly. Bring them in.
The key word in the previous paragraph was collaboration. It took us three iterations to really get this right, and the end result was that we completed more story points in the last iteration as we did in the first two combined. At one point we had a dev, the designer, the copywriter and the site producer all around one monitor – on the surface this may seem inefficient but we didn’t do this all the time, just on a few occasions where we were simply churning previously. This selective pairing (or quadrupling in fact) enabled us to get many stories over the line that had been churning for way too long (weeks in one case).
I want to work for a company with no arse – that means that there’s nothing to cover and nothing to kiss (or blow smoke up)!
This thought occurred to me today in a large workshop aimed at identifying the cultural elements of “world class” companies. Never being one to shy away from a simplistic way to express what is actually a complex set of qualities I thought that this expression captured much of the feeling of the day. In a room full of very smart people I was very pleasantly surprised to see ego cast adrift and humble self-reflection take center stage. This kind of thinking could very well engender a “world class” culture. At the very least it could provide the space for such a culture to grow into.
Of course the things that get in the way of such a culture are many, and more of them come from the very people striving within the culture than we might first realise. Our own thinking and patterns probably limit us much more than any external pressure. The biggest lesson that I have taken away from today is just how we can all learn if we are open to it. Learning is just the first step though. Taking action, and backing it up, reflecting on it, adjusting it, and then repeating this cycle endlessly is going to be the real challenge…