IIBA IIBA-AAC – Techniques on strategy horizon

7. Value stream mapping

Value Stream mapping is a technique that helps you understand how the business delivers value to their customers. If we look at the definition, it is a complete factbased time series representation of the stream of activities required to deliver a product or service. Okay, it’s quite a fullon definition from the Agile Extension to the Beabod guide. What it means is your Value Stream map is a first step in understanding the business processes in the organization effectively. It is a series of valueadded activities that the business needs to perform to deliver essential value to the customer.

Let’s see how it is being built. You have your actions from your customer journey map. These are the actions that the customer performs. These actions are performed or interfaced through touch points to your business and behind each touch point there is a whole back of house that happens in your business to enable that touch point. Each value stream will happen behind the touch point. To make sure the touch point can help customers achieve what they want to achieve, let us map an example value stream. For one of the touch points, I suggest we start with the first one, the build.

So just like with customer journey maps with value stream mapping or process mapping, you can always look at it from two points of view. As this point of view how does the process work now and to be point of view, how it is going to work after the initiative is delivered. So with the bill, the assist value stream may look something like this. It starts with some sort of financial accounting process that calculates the outstanding amount. I’ll call it reconciliation process. Then it goes into the next step which issues the bills. Based on the results of this process, I would say that we first issue these bills in the system, somewhere in the financial system, so there is a record of it.

And after this is done, we can physically print the bills and send them for delivery and we don’t need this final step. So this is our asis value stream for sending the bill to the customer. Now if we want to change it in the future, we can take the assist process as the baseline and make a few changes to it. So the reconciliation process will probably be the same. The bills in the financial systems will probably be issued in the same way.

But instead of printing the bills we may queue them for SMS delivery or we can email them. This will be our future. State Value Stream Map what do we need to take into account when creating a value stream map? First of all, process wise, you start with assembling a cross functional team. You assign a value stream map owner, then select a product, a product family or a service and define the scope of the value stream map.

You identify the customer value received so it can be traced back after that you are ready to create your current state map. You give it a name, you draw the map. You capture the step by step flows, identify which steps are the candidates to be eliminated and you validate the map against real processes. You talk to people and gather their feedback. After that, you analyze the current state. You find the sources of waste. You could use techniques like crude cause analysis to do so. And then you create your future state to identify the improvement opportunities. And then for each improvement opportunity, you create a measurement that will tell you whether you succeeded or not.

Finally, you prepare for implementing the change. You identify which supporting material and activities are required for implementing the improvement, such as which changes need to happen in these systems or which training is to be delivered. Then you implement the improvement. Well, these stream maps are great too because they are comprehensive and they provide a blueprint for implementing the improvement. They also help you establish a shared understanding of the process, waste and bottlenecks. However, they do have some limitations.

First of all, they require significant effort to be constructed. Then, they are prone to mapping paralysis. It is easy to get caught making the current statewide stream map complete and perfect instead of proceeding to the improvement stage. So, you spend too much time fine tuning the current state map. It doesn’t work so well in knowledge based or or nonlinear work. And finally, it usually leads to disruptive or re engineering approach in improvement.

8. Roadmap and MVP

What have we learned so far? We’ve learned how to map current state and future state experiences and value stream maps to identify the gaps between the two. This allows us to scope the initiatives to deliver the missing capabilities to the business. What we haven’t discussed yet is how to estimate those initiatives and how to prioritize them. Let’s do it. Now, there are a couple of definitions that we need to discuss first. The first one is MVP Minimum Viable Product. According to the Agile Extension to the BBQ Guide, an MVP is a concept from Lean Startup that describes the fastest way to get through the Build Measure Learn feedback loop with the minimum amount of effort.

But what does that mean? It means that you want to prioritize the features that allow you to learn what is the best way forward. Contrary to common belief, MVP doesn’t mean that you want to prioritize the business value in the first release. What you do is you maximize learnings and try to validate as many hypotheses in one release as you can. There is no single formula of what your MVP should look like. There are, however, three most popular types of MVP that you may consider.

The first one is an MVP without a product at all. An example of this can be a landing page or some promotional marketing materials that explain what your product is about and collect some initial feedback. A great example of such an MVP was issued by Dropbox in their early days. What they did is they created a landing page with a video explaining how the Dropbox product was going to work and then they had a CTA to register your interest. As soon as they’ve received enough registrations, they realized these products may be in demand and then they decided to actually build it.

Another type of MVP is with substitute for a product. An example here is you may hire a few casual workers to do some work manually before trying to automate it as a scalable service just to see if this type of service is viable or is of interest for your audience.

And finally, with just enough functionality, you build a prototype or a simple cut down version of your solution just to see how it works and to collect the feedback. Another important definition is the definition of product roadmap. Product roadmap is a visual representation of how a team plans to implement their product strategy over progressively longer time horizons. The product roadmap is updated frequently and reflects outcomes the team plans to realize, rather than outputs the team plans to deliver. This is the definition from the Behavior Guide.

What it means? Essentially, it means that your product roadmap is your list of initiatives that you want to deliver in the order of priorities with associated delivery dates. So how do we construct a roadmap? First of all, based on your previous research, you list the capabilities that you need to deliver then you need to perform relative prioritization. You need to compare which ones are more important than the others. You take into account two things the value that your features bring to your customer and the value that they bring to the business.

And then you make some trade offs to understand which ones are more important than the others. Then you perform the relative estimation here to understand how long these capabilities are likely to take to be delivered. And finally, you place them on a time frame in order of priorities. This will be your product roadmap. Let’s have a look how this is done. To do that, let’s jump back to our mirror board. As you can see, I have listed all of the capabilities based on our previous research. These are all the potential features that we want to include into our solution. Some of them are really important and we want to work on them right now. Some of them are less important and we may decide not to work on them at all or for some foreseeable future.

So, as you can see, my presentation board is divided into three swim lanes. Top one, middle one, where all of the features are right now, and the bottom one, the top one will be used for the features that are prioritized for our first release for our MVP. They will go into our development backlog with the highest priority. The middle lane will be for all of the other features that are still relevant but less important than the MVP ones. And the bottom one will be for the features that we decided to disclose for now. So for this example, we may decide to first build the simplest solution that will help us validate our idea that remote payment is more preferable than paying face to face in the office.

We may decide that the simplest way to do it is to start with sending an SMS reminder for the payment, then enabling our farmers to pay via their phone so they can call the support line or IVR system and process the payment over that call and then receive a confirmation via SMS. These three features or these three capabilities will form our first release, our MVP. As we go through the rest of the cards, we may decide that some of them are actually not desirable and we don’t want to waste any resources building them.

As we discussed before, credit card payment online may not be important for us because people may not have stable internet in their places and they cannot actually pay via website. And same goes with sending the receipt while letter after online payment just because it may be too hard to implement. So as a result, you can see we’ve got three priorities top priority, what goes into our press release medium priority, something that will be built as we have some resources available to do it and closed priority, something that we decided to disco from our solution.

Now let us move to the next step of preparing our roadmap relative estimation. We’ll be using a technique called Tshirt Sizing for this. Let’s have a look. As you can see, I’ve got all of the features from my previous exercise here on the left hand side, and I’ve got four columns for four T shirt sizes s to Excel. Each one has an associated time frame. This time frame is the estimate of how long it might take to build a feature. And the idea is very simple. It’s like trying t shirts on. If the t shirt can be squeezed on your feature, it means the feature belongs here.

For example, something like an SMS bill. Your developers might look at it and say no way, we do it in less than a week. We probably are not going to do it in one to two weeks, but four weeks is definitely enough to finish it. So it receives an estimation of L. We do the same exercise for the rest of our features, and by the end of the exercise, you will have some indication of how long it might take to deliver this or that feature based on this T shirt sizes. This exercise is really good, especially on a strategic horizon, because it allows you to estimate quickly and get a decent level of accuracy to produce a roadmap.

However, when you go into a proper development lifecycle, you will reestimate your features in more details to get a much more detailed and confident estimation. This is just a starting point to compare the sizes of different tasks and make decisions. Now finally, we’ve got our relative estimation and relative prioritization done, which means we can start road mapping. I will move on to the next frame in my mirror board. This is my frame for roadmapping.

Here I’ve got a calendar which I’ll use for uploading the roadmap, and I’ve got three swim lanes on this calendar. Each swim lane will represent my internal team that can work on tasks independently from others, so I can parallel some work. And I’ve got my features. As you can see, the features come in different sizes. The length of the box represents my T shirt size estimation. So the shorter the box, the quicker it will take the team to deliver. This one will mean just one week of development. This one is two times longer, so it will mean up to two weeks, then up to four weeks. And this one will be an Excel up to eight weeks. For the sake of road mapping.

They also come in two different colors. The red color represents my MVP priority, so the things that are top priority for all the teams and the blue color will represent a secondary priority. We’ll start working on them when we have resources available, so we can just start assigning tasks to teams and see how long it is going to take us to deliver something to production. Let’s assume the digital team has expertise in all the SMS related things.

So they will work on implementing SMS build capability and then they’ll move on to SMS confirmation capability and then they can pick up another task. And as you can see, the next SMS related task is already beyond MVP. So they can start working on it after they finish all of the MVP related things. At the same time I’ve got my infrastructure team. This team will be focusing on all of the back of house payment processing tasks and they will start with developing a capability to accept payments over the phone.

Again, this is a part of my MVP. Once they’ve done, they can move on to another payment method. For example bank transfer payment. And then finally I’ve got my mobile team. The mobile team doesn’t have any tasks to work on that go into MVP. So they can start building the mobile app in parallel to the rest of the teams. So they can start with delivering a bill in mobile, then building payments in the app, then sending a confirmation inside that app.

And we’ve got final task email bill. I would assume email bill will be associated with bank transfer. So as soon as we’ve got our bank transfer payment capability, we can send bills via email with details how to pay using your bank account. And this will be a feature on its own. So now we’ve got a roadmap and what we can do is we can understand which milestones we are likely to have. So I’ll add an icon to my roadmap. This flag will indicate a milestone.

My first important milestone is somewhere in May I’m going to have MVP ready. I know it because I see that all of the red tasks will be done by this date. Then somewhere in June I will have another milestone which is I will have my email bills with bank payment capability. And finally, somewhere late in July I will have my mobile app ready. This is our roadmap for this initiative or this group of initiatives. What we need to remember when working with a Roadmap a good roadmap helps you land on an MVP. And MVP is less expensive than developing a product with more robust features.

It reduces cost and risk defined roadmap oriented stakeholders to a shared focus and it can be used to facilitate conversations about priorities. Roadmapping, however, has some limitations. First of all, it requires advanced market understanding to identify the necessary feature set for early adopters. MVP is not about creating a minimal product, but testing an initial hypothesis for a product. Roadmap is time consuming to maintain if it is overly detailed or if multiple different use are required. Finally, it may be ineffective if the organizational environment leads to frequently changing vision and desired outcomes.

9. Portfolio Kanban

Now, as we’ve got the roadmap for strategic initiatives lined up, let’s have a look at a tool that will help us track status of those initiatives. The tool is called canben. If you remember, we talked about Canbean boards when we explored the capabilities of Mirror. Now let’s have a closer look at this technique. There is a definition in the Agile extension to the Bao Guide which says that Canben is a framework which helps in the application of agile values and principles. That’s good to know that Canben can help apply agile values, but it doesn’t really explain what it is. So let’s have a look at another definition which may be a bit more useful for us. Canben was originally introduced as a part of Toyota production system quite a lot of years ago.

In its core, there is a physical board that visualizes how individual work items travel through your production process or business process. In fact, Kanban in Japanese means billboard or sign board. So a physical board with cards on it. This board is used as a single source of truth of the status of different elements of your process, different tasks or activities or other work items that you want to track as a part of your process execution. Now, let’s go back to the definitions from the book guide. The next important definition is the definition of portfolio. A portfolio is a collection of strategic initiatives for an organization or department to execute in alignment with their business goals. Basically, when we talk about portfolios, it is important to understand that a portfolio is a set of initiatives or a set of projects that are executed based on the same pool of resources.

So you’ve got your resource pool, say your department or team, and you’ve got a couple of initiatives that they need to achieve. And the way you plan your resources to achieve those initiatives will be your way to manage your portfolio of initiatives. So, with these two definitions in mind, we can get to the definition of a portfolio can bend a portfolio. Canben is a visual board that brings structure to analysis and decision making at the strategic horizon. It does so by visualizing the work in progress and showing you which initiatives you are working on and what is their status at a moment in time. So let’s have a look at an example. Here is an example of a Campbell board that you may use for your initiative.

As you can see, it has a couple of columns representing these steps identified in the organization to move your initiative from early stage of being just an idea all the way to being delivered and done. These columns are the visualization of your business process.

So depending on the organization and depending on the processes that you’ve got in your business, the columns may be different. What is important is that those columns are communicated to all the stakeholders and the people in the business are aligned, what are the steps of the process? So let’s have a look at how initiatives may travel through this canvas. At the start of the process, all the initiatives will live in the backlog or in the ideas column, the first column of your canvas.

Then they will be picked up in order of priorities and go into the next column on the next stage of the process. Like this, they go into research in our example. Then, based on the research, some of the initiatives will progress further into delivery and some of them may become canceled like this. While the initiative is being delivered, you may have some extra resources to pull a new initiative into research. Into research. Sorry. And this is how your canvas works.

So at every moment in time it shows you what is the status of a given initiative and once the status changes, it moves to the next column. Canben as an approach, is not just the board to visualize work. It also comes with a couple of principles of how to use it. And the first one is visualize the work. Make sure that your columns realistically represent your business processes.

Second one to limit work in progress, you need to introduce strict rules of how many work items can be addressed in the same status at the same time. This will make the process participants focus on completion of open tickets rather than starting more and more tasks every time they have any capacity without finishing them end to end. This way, when you limit work in progress, you get rid of local optimization.

Optimizing just works in certain statuses and you focus on the end to end optimization on end to end delivery of your initiatives. The next one is to identify bottlenecks, see which work items becomes told in which statuses, and use this as an input into your quality management and process improvement. Make rules explicit. Your exit criteria or definition of done, if you wish, for each column should be understood by all the participants.

Everybody in the team needs to know what does it mean? The ticket is done in a certain column and can progress to the next one. Incorporate feedback loops. Make sure that you introduce a feedback column or status or procedure into your process. You don’t want people to be silent in their tasks or in their statuses and eventually increase collaboration.

That is the whole point of using Canben. Make it visible, place it somewhere where it can serve as information radiator. It can be used by anyone interested in the status of the project or certain initiative for certain tasks to look at and get what they want. Remember that Canben as a tool can be used both on strategic level and on project level for product features or tasks. And the principles applied will be the same regardless of the level of application.

Canben is a great tool that can be replicated on all the horizons but specifically to portfolio management. It helps to optimize the portfolio to respond to real needs. It also increases the feedback loop through visualizing the work in progress. This also helps to identify bottlenecks and issues in your process. Finally, limiting the work in progress increases your overall flow. Kenben, however, has some limitations. It works well when on all initiatives go through the same flow.

It is not useful if there are different paths or columns through which an initiative can move. Initiatives should be appropriately sized to regularly move through columns. This approach does not add clarity when initiatives sit in the same column for a long period of time. Finally, it is best suited for single floor systems. This comes back to the first point. If you try to map multiple floor systems on one, one can be on board. It may become overwhelming and it won’t provide necessary clarity.

10. Mapping the principles on strategy horizon

Wow, what a journey. So far we’ve learned a lot. We’ve learned how to understand who our customers are, how to get inside their heads, understand their needs, problems and pain points and design solutions for those problems. We’ve learned how to plot the Aziz and to Be experience and business processes, identify the gaps, plan the initiatives to bridge those gaps and roadmap them. Amazing effort. Now, what I want us to do is to go back a little bit and revisit the principles of Agile Analysis and see how can we apply those principles to all the tasks that we’ve discussed. I hope you still remember what the principles are. The first one is see the whole See the Whole on Strategic Horizon means that you work with your decision makers in order to make effective decisions.

You incorporate a holistic view of the context in which your organization exists, what is the market, what is the political climate and many other factors. You create rapid feedback cycles and learnings throughout the organization. You establish constant and deep collaboration between business analysis practitioners and stakeholders. That’s what you do on the strategic horizon as a part of See the Whole principle. The next one is think as Customer. To think as customer on strategic horizon means to maintain a strategic focus on the customer value. You help the organization to set goals and align work to the customer’s needs. And you prevent the organization from delivering suboptimal experiences via your end to end analysis. The next one you analyze to determine what is valuable. You identify what are the strategic needs that need to be met and you help better allocate resources in pursuit of organizational goals.

You analyze new learnings and reassess viability of previous decisions. Essentially, you help the business to maintain a healthy portfolio of initiatives assigned to teams and individuals better suited to deliver them. The next one is get real using examples, you communicate evidence based information. You don’t base your decisions on opinions, you document and validate all the assumptions made. And you use hypothesis driven approach the next one to understand what is doable as a part of implementing this principle. You present clear relevant information to the stakeholders and decision makers. Also, based on the initiative types and needs, you help the organization to allocate the resources effectively. The next one is simulate collaboration and continuous improvement.

You need to help the organization develop and support highperforming teams, specifically through developing the channels for the teams to interact with each other. You don’t want your teams working on your portfolio of initiatives to be silent. You want them to communicate, to share ideas, to share insights and to share knowledge. Essentially, you need to facilitate knowledge sharing between the people in the business, finally avoiding waste. You ensure that decisions are made on current and accurate information and based on shared understanding of goals and priorities. This allows you to reduce, double handling and rework. You also remove duplication in initiatives. You help assign resources in smart ways, regardless of which techniques you decide to use. If you follow these principles, you will aid your strategic agile analysis.