Table of Contents

• Introduction
• Decide to invest on an idea

Introduction

Recently people have been asking me “So, when will you write a book?” Note that they are not asking “Will you write a book?” but more as a done deal that will happen sooner or later.

Writing a book is not a new thing for me. Did this 13 years ago and still proud of publishing 500 copies of “How to use AutoCad R1” that was sold out so quick I almost thought I will not keep a copy to myself. Didn’t follow up to publish more copies because at that time moved to Canada and I had other priorities to deal with.

Now, people are challenging me to write another book about what I do. I like it that they trust me and they think I am capable of it. So, here I go, I am accepting the challenge and I decided to kick-off a book on Leanpub.

In the spirit of Leanpub publishing, this will be written incrementally and so, I would love your feedback and any suggestion that will help me finish it right. Just quickly, where did the idea for this book came from and what is my goal with this book.

Where did the idea for this book came from? I am an Agile process coach. I can play the role of Project Manager, Business Analyst, Agile coach for Product owners and Scrum Masters and, I am “Decision challenger” for everyone on the team. I will bring here my experiences with teams new to Agile. The context is usually like this: A new Executive leader comes to a company and identifies that one area of the company is not achieving the expectations and is struggling to deliver. Usually this area is IT. The recent trend is to kick-off Agile transformations as the hope that will fix problems and will help these teams to deliver, increase the productivity and eventually help the company to be profitable. Trainings are the first tool on getting people to understand Agile thinking and the mechanics behind, usually lead by people with previous knowledge in Agile. What I have noticed is that, although in general (there are always some that resist!) people do understand what Agile is all about, they have a hard time to put it in practice. This, most of the times, is because, just like before Agile, they are asked to deliver projects that are big and expensive. They know how to deliver projects. They have done lots of those before. To run a project in Agile, it is difficult to understand how to change the old ways and how to deliver in an Agile way. Because they are not “armed” with the right “how-to”-s, they either fall into doing things the old way, or, they start complaining that “Agile doesn’t work for their environment and specific context”

My goal I want to put together some tools, tips and techniques to help teams new to Agile, from kick-off to success. The tools and tips are for everyone on the team, but sometime someone might be the leader or facilitator of them. On those cases, I will suggest those roles based on the strength of expertise. That said, these are tools that can be used even from teams that run Agile but are looking for new, different or better tools to improve their discussions and make better decisions.
I believe that when people are given tools to get the information they are looking for, they are less resistant to change the overall methodology used on a company and try something new. Although, for teams and companies that are moving to Agile, tools and techniques do help, the main driver is always the culture, the thinking and the continuous improvement.

Decide to invest on an idea

Usually, a work of whatever shape (product, project, enhancement, upgrade, etc.) starts from being aware of a customer or end user need or opportunity that is not taken care off on the solutions currently in use. Let’s say, someone from Business has identified a Business need that if taken care, it will help one or more of these: increase productivity, lower operational cost, optimize inventory, better customer experience, increase customer loyalty, create opportunities for growth, enable gain, remove pain, etc. Most of the times, this start as an idea that is discussed on the Business side. Hopefully, some strategic thinking is done at this phase and a decision is made to give it a try! I say hopefully, because sometimes things are not thought or analyzed well and the decision to go ahead with that work is about to set a lot of people up for failure. And we do not want that! Once this idea has received some thumbs-up from some people on the Business side, then delivery team (I will talk here about IT delivery teams) is created and allocated to work on this project. A Cost Center (usually) is created where everyone will start entering their time spent on this project. To keep the cost low, only a selected category of people from IT are involved at this stage. Let’s say we start with a Project Manager, the Development Manager, a Solution Architect, a Business Analyst and a SME (Subject Matter Expert) or two. The common method of discussion during this phase is “A lot of meetings”. Eventually, some decisions are made and we continue by following that decision.

A better way to manage this phase is to use discussions with a focus on solving some key questions we need to make at this time as well as get Business and IT to bring ideas from both sides, challenge thinking, define a better goal, derive scope from goal, understand what Return On Investment might be, etc. One tool that I am using is the Agile Project Canvas. I have had really good feedback on this from different teams and that makes me think that some other teams out there might benefit somehow if they give it a try. This canvas was created from the need I had to help my teams on this phase of a project. They needed a structured tool that would take them through the thinking, the discussions and the scope definition. I looked at the Business Canvas from Alexander Osterwalder but that felt one level up from the project team. I looked at the Lean Canvas from Ash Maurya but it felt complicated for a team with low maturity. I also looked at a canvas model that we used when working with the Lean team at Deloitte Toronto.

So I took some ideas from all of them, added some of mine, got some feedback from some colleagues and created this Agile Project Canvas that is targeted for new teams to Agile. Feel free to use it even if you are not new to Agile. You will find it helpful to start the conversation. This is version 2.0 of it, improved slightly from Version 1.0 based on the reaction and feedback I received by teams that are using it. I will explain all these boxes and help you with the discussion for each. I have put some numbers to help with “Where to begin?” but you don’t have to follow the numbers. All that being said, 1, 2 and 3 will be where you must start! Another “must” is the fact that you need more than just Business, PM, BA and the Architect on this discussion. You must bring someone from Development, Testing, Operations, Support, Infrastructure and any SME required from affected areas.

The Agile Project Canvas

Agile Project Canvas

You can find this canvas in a PDF format on this location: http://bit.ly/1k5GnSZ Feel free to download it, print it on the real size, put it on the wall and start discussion with your team by sticking post-it notes on each of the sections.

Let’s explain all these boxes:

• Problem This is the first box we start to throw post-it notes. The reason behind is to understand the “Why?” and the “What we want to fix?” of starting new work. The discussion is mainly lead by the Product Owner or depending on the team structure, the person that represents the customer needs. The focus is to lay out at least 3 problems that are identified and need to be taken care. Each problem has also a sense of urgency that helps the team to understand the Project category, or the Class. Will talk more about Classes of work when we describe what goes to Scope. For now, let’s say that this is the box that Business team will use during the initial discussion of deciding on a new idea. This box might be updated again when we decide to continue with this project. Once we have a team and are about to start the work, Business/Product Owner will present the team with the problems that are raised on this box during the initial discussion on the business level. Keep an open mind and be ready to hear issues/problems that the team might bring along. Sometimes IT knows some tricky things that might not be visible to Business. Also be prepared to hear the team saying that a problem might not be a problem and maybe a solution is already in place but somehow not implemented.
• Customer segments Once the “Why?” and “What?” are discussed, the next step is to focus on the customers that we want to satisfy. This might sound pretty straight forward but the power of it is to make sure that we are not planning to make happy ALL the customers. It is very key to understand and accept that each solution we provide, every change we make on the product, we target only a selected category of customers. A product usually has many flavors of customers and they have different usages of the product. For a specific category, specific set of features are really important. The same set of features, might have lower usage on the hands of another category of customers. By understanding “Who?” are the target customers that we want to satisfy with this change, we bring focus to the scope and solution that the team will design next. This is also a box that Business team will be using during the initial discussion of deciding on a new idea. Just like with the Problem, this box will be touched again when we start involving the team and decide to start working. Be prepared to hear what team has to say and what suggestions they will give. It might help a lot to focus the scope and efforts. There are a lot of techniques you can use to find the most important user for your system. Some are easy because they come from some sort of feedback you have collected from a previous release of your product. Some are elaborated and require surveys on different profiles of potential users (otherwise called Personas). You can organize the results in layers of Primary user, Secondary users and Tertiary users. Like this, everyone is aligned on “Who do we want to make really happy with this change?” and “Who else can we help with some improvements?”. It might sound easy but sometimes it is complicated and, it might change completely the scope of the work we had in mind. The same goal might be technically easy for User A, but it’s a whole new story for User B. And this is where a good Product Owner is required to say NO a lot of times, so the team is focused to the right User, the right Goal and will come up with the right scope.
• Benefits This is where we now start crunching some numbers. Once we understand the “Why?”, “What?” and “Who?” let’s decide how will we be measuring these. What are the benefits of fixing those problems we listed on the first box? What is the Business Value and User Value? Do we reduce any known Business/Market risk? Do we enable opportunities for a better place in Market or for a completely new Market? Do we give to Business or User a competitive advantage? And how will we measure this? What are the the current numbers telling us? Where do we want these numbers to be after this work is completed? And this is probably the last box that Business team will be using during the initial discussion of making a decision on a new idea. Just like the other two boxes, Problem and Customers, we will get back to this box again when we decide to start the work. Be open minded to ideas, suggestions and also action items that you might need to take to do gap analysis or customer surveys to help you with metric decisions. Here is where we usually go and dig deep to analytics, set the new target standards, do some market surveys, etc. The team will not be able to do anything with “Improve user experience” but they can do a lot when we say “Improve user experience. And this means 30% faster to get to Shopping cart compared to what it takes now, 40sec”
• Scope This is the box that Business should not complete without IT. To discuss this box, we need to bring in front of the canvas more team players. In this discussion, we need to bring Dev Lead, Testing lead, any SME of the affected systems, the Scrum Master (or Project Manager), and the Architects. Do not start discussing Scope until everybody from the list above is on the same page with Problems, Customer segments and the Benefits, all the questions that came up are either answered or put on the Unresolved column of the Planning board on the bottom of the canvas (will talk more about this later). If the need for information on a system or a process is identified, and there are no SME or team members that are able to help clarify, then would be good to invite someone as soon as possible. The best case would be to just go and bring someone on the room and quickly bring them up to speed with what has been discussed so far, in order to help them provide the appropriate feedback that we are looking for. The worst case scenario would be when we either do not know who to contact or the person is not available. On these cases, a task is created on the Backlog, assigned to someone on the team to follow up, and a note is added to the appropriate post-it note to identify that more information is required. Maybe a post-it note is added on the Risks box as well, depending on the fact that the missing info might either raise an Issue or a Risk. After Business discusses the first 3 boxes with the team and makes any necessary updates, we might already have put some post-it notes on this box. Key features and project/product Goal are the focus of this conversation. In a collaborative way, the team and Business work together to create the list, clarify them and maybe also make decisions on what would be Out of Scope. These decisions are tracked on the Planning board, on the “Out of Scope” column. By making them visible, talk about them and make sure everybody on the team understands what’s In scope and what’s Out of scope, we build boundaries around the Technical solution we will design later. Another important factor on this box is the Project Category. Not very different from the Class of work, here we need to understand if this project falls on the Expedite, Standard, Fixed or Investment Class. The final goal of this discussion is to understand the Cost of Delay on the delivery of these features and eventually the entire product/project. Cost of Delay is a well known concept on Lean Agile and a lot of people that contribute on Lean/Kanban circles have spoken a lot about it.

Cost Of Delay

By understanding the project category, we make more mature decision on the discussions that will follow on the other boxes. Cost of delay also helps to clarify any deadline we need to be aware, any fixed date we need to make sure we understand what features are a Must and what are Nice-to-have and eventually prioritize this project against other projects that are lined up for the same Dev team. Use this discussion wisely to make sure the Team will be committed to the work that Returns the highest value on the Investment

• Business readiness Here is where we discuss what do we need to have in place in order to unleash this work in the hands of the customers. Who do we need to train and what kind of training? What do we need to do to bring the Sustaining /Support team up to speed? Will this affect Operations and how can we prepare them? And so on, as per the specific project and context. It just forces the team to think past “Push code to production” and one step more after that. Think here Flyers you have to maybe prepare and send out or any marketing campaign that needs to be in place. Discuss dependencies on other project, teams, 3rd party vendors, special events, etc.
• Possible technical solution And this is where everyone loves to write! At the end, we are all wired to solve problems as quick as possible. I have found that moving to this box without a good understanding of the Why/What, we end up with solutions that we keep changing when we start asking the questions we ask on the previous boxes. It might feel like “analysis paralysis” sometimes, but the discussion on the previous boxes is not meant to take days or more than a couple of hours (for big and complex ideas). As such, I find it necessary to go through that discussion before we bring technical options. One thing we discuss here is the Type of the project. Is it a brand new project? An Enhancement on existing solution? Update to keep the current solution functional? Bug fixing/Patching on known or reported issues? HotFix? OverTheAir update? Based on the maturity of the teams and organizations, these types do matter. They help with the prioritization of this work on the Team’s queue, or on Enterprise level prioritization of the next work to invest on. Leave Technical team to lead this discussion. They know this area and they might bring much better and elegant solutions, when considering the current technical status, the future technical strategy and the opportunities to minimize technical debt.
• Desired team As per the title, here is where we do a high level plan on the skills that we need for this work to be done. In project management vocabulary, this might be translated to “Resource plan”, but here we are talking about the skills that come from people. This is the place where we identify if we have all the skills required in-house, if we need external people to come and help us on specific skills/knowledge, if we need to ask another team for help, etc.
• Elevator pitch Imagine you get in the elevator, press on 15 and the CTO gets in right after, presses 18. He asks you “What project are you working on?”. You say “Project ‘Merlot’ Sir”. “What is this project all about?” asks him. All this while the elevator moved you one floor up. You are stuck with him for 14 more floors and now have to explain what Merlot is all about. You can blabber words and come up with some problems you are trying to solve and the solution you have found, and say all this while sweating and looking at those floor numbers increase very slow. OR, you can recite the elevator pitch that the whole team prepared together! You will look so smart and business-like that the CTO might just promote you. Only if he knew your name! Hope you have a smile in your face now. And I am not kidding when I put you on a situation like this. I have worked with Product Owners that are very often on similar situations with Executive Leaders that take the same elevators and sometimes have offices on the same floors. Preparing people with this quick pitch, helps not just to bring everyone on the same understanding, but also on the same way we present this project to others. Everyone sends the same message.
• Risks One of the things I talk about a lot to my teams, are Risks and Issues. Usually, in project management style, risks are low priority and issues are the ones that are tracked and followed-up and reported. The problem I see is that when dealing with issues, we are in reactive mode. The right mode to be is pro-active. And this is what we do when we deal with risks. Issues are risks that we didn’t take care of properly and at the right time. By making risks visible and raise awareness, we start thinking pro-actively, we start making decisions on what to do about them and also, we make decisions by when we want to prioritize work to lower a specific risk. That being said, there are issues that do come up before we could identify them as risks. The goal is to minimize the number of these cases. They bring in-planned work and this is the kind of work that puts to jeopardy your planned work and your plans (even when they are short term/sprint bound).
• Cost Cost is not only to understand our investment, but more important is required to calculate Return On Investment, ROI = (Benefit -Cost)/Cost *100% . And ROI is one of the metrics that we use on decision making. Is this ROI within our threshold? To make these decision, we now do an estimation of the cost with a high tolerance. Maybe even +/- 50% but less than +/- 25%. Less than 25% tolerance doesn’t leave room for the team to deal with issues they don’t know they don’t know at this point of the project. Do not forget, we are in early stages of a project. We face a lot of unknowns and risks. Don’t forget to identify the sponsor or the source of funding for this project. Sponsors are very important players on decision making and we need to understand and consider their needs throughout the project.
• Short term planning board This is a small Kanban board that is meant to help the team to organize their questions, needs for investigations, etc. during the phase of completing the canvas. The post-it notes we put there are usually tasks (small stories) that someone on the team can take and move to “Ready for review” quickly. Usually, the entire process of completing the canvas is within 1-3 weeks long, depending on the size of the project and on the needs that we identify. Sometimes, the tasks created are Proof-Of-Concepts that will require the team to actually produce some sort of small deliverable, in order to help with decision making and other questions we have un-solved or un-resolved. The “Out of Scope” column is there to visualize the work that during the discussions, we decide to call it out of the scope of this project. It is there because it will not be carried over to the next phase of the project, when we will plan the work a bit deeper. Unresolved column is a “Parking lot” of ideas/suggestions/questions that we don’t know yet what to do or if we want to put any effort to find out what to do. Backlog has all the tasks that we do want to take care, do something and evaluate based on what we find Sometimes, before we start working on a task from Backlog, we might need to do some prep work. For example, the task might require the involvement of someone outside the core team. As such, someone from the team must first talk with this person, bring them up to speed, explain our needs and then, when the person is ready to do some work for us, we put it In progress. Post-it notes that are In Progress column, are the work that team members are doing currently. Just like any Kanban board, try to use the same thinking when tracking the work here. Limit the Work In Progress is a good rule to have. Ready to Discuss means that some work is done and now we are ready to report to everybody on the team what we found. This can be done over a short meeting or a Demo-like gathering where we actually show in action what we did/found. Once the work is showed/demoed, based on the discussions we have, we update the appropriate box on the canvas. Remember that all the tasks that we tracked on the Kanban board, had a goal to clarify/identify/remove blocker on the team being able to complete the canvas and be clear on the work they have ahead.

I like very much a saying: You cannot mandate what must be discovered! During the exercise of completing the canvas, the team is continuously discovering more and more about the work ahead. And this is truly a discovery process because only when everybody is working together and opinions of all areas are heard and considered, we can say that we are moving one step closer toward the right direction.

When are we done with canvas?

I did mention above a 1-3 weeks timebox to complete the canvas. We do not want to make this a long activity. The whole goal of using this tool is to speed up the conversations and decision making. We can stop this exercise at any time when we have a common understanding and agreement on whether to stop looking at this project, or we agree to continue and we know where to begin the project plan

In Recap:

When Business identifies a new need, start having some initial discussions over the Agile Project Canvas and focus mostly on boxes 1, 2,3. Once we conclude that this idea is worth it to be explored, we extend our footprint to other areas that bring expertise and knowledge about solutions and work that needs to be done. In a collaborative way, with all the areas represented, we complete the canvas. Any work that needs to be done in order to complete the canvas, is tracked on the Kanban board at the bottom of the canvas. Stop when you are ready to move forward or put a break on this idea.

Hopefully you decide to continue. And the next step is to plan for this work