Sunday, January 24, 2021

Forecasting - Answering the question of “when will it be done?”

 “When will it be done?” is a question that a surprising number of IT professional struggle to answer with certainty. This is surprising to me, because in many situations it is reasonable easy to come up with a suitably certain answer. Yet no one has done so. Instead they are pushing ahead with little to no understanding of whether they are on track to achieve their goals. This blind faith is admirable even if misguided. This article aims to show you how to answer the question of “When will it be done?” with a suitable level of certainty. Doing this allows you to harness and direct that faith to achieve your goals sooner or better. 


Set-up

To answer the question of “When will it be done?” there are several pre-requisites; none of which are difficult when working in an agile manner.

Your Work items need to be potentially shippable increments of the product. They need to be vertical slices that ideally deliver some business value. Splitting up your work in this way means when something is “Done” it is really “Done”. This approach reveals the hidden work to achieve our goals. This article will not delve into how to accomplish this as there is plenty of existing literature on this subject.

We also need to know:

  • How much needs to be done? Aka. Work items to do.
  • How much has been done? Aka. Completed work items.
  • How fast are you completing work? Aka. Rate of completing work items.

The following sections will provide more detail on how you can answer these questions.


How much needs to be done?

The biggest hurdle I see to people answering “when will it be done?” is that they don’t know how much needs to be done, and they don’t know that because they don’t know what “it” is. The excuse of “we will know it when it’s done” often comes out, which does not help anyone. Instead you need to become comfortable with ambiguity; and focus on the reducing the unknowns that get us to a point that we can develop an initial high level view of what “it” is. Often you can develop a forecast with what the project team currently knows about “it”. Early on this forecast will be less certain than you want; however this forecast will be refined and improved as the project team learns more by doing.

How much you know about “it” should guide your choice of determining how much needs to be done. To figure out which approach to use, please determine which of the following three situations you are in. 

Situation 3: What needs to be done to achieve “it” is unknown and currently unknowable. Currently we cannot write out a bullet point list of what needs to be done; even at a high level. There are multiple significant unknowns, multiple risks, and likely more risks or issues we are not even aware of yet. You are deeply in “Research”. Suggestion: Don’t use forecasting yet. Instead focus on reducing your unknowns, reducing risks and doing spikes/investigations. Your aim should be to get to Situation 2.

Situation 2: What needs to be done to achieve “it”, is only understood at a high level. We can write a bullet point list of roughly ten or more work items that comprise “it” Those work items may be very large, this is not a problem. Suggestion: Determine how much needs to be done by elaborating a sample of work items. This means: 1. randomly select three of those ten plus work items. 2. For each selected work item hold a workshop with a cross functional group from your project team. In the workshop split up the large work item into smaller potentially shippable product increments. These need to be close to the size of work items that your team regularly completes. 3. All of these smaller work items need to be estimated. The result is that you know the size of three of the large work items. Importantly this size matches up to the way that you measure completed work. To determine how much needs to be done average the size of the three elaborated work items and use that size for the remaining unelaborated work items. This provides a roughly estimate of the total work be done.

Situation 1: What needs to be done to achieve “it” can be known with some certainty. The Product Owner has a vision for the Product; the technical people have a rough understanding of how they could build it; the ‘leads’ have a reasonable yet incomplete understanding of what “it” is.

Suggestion: Hold a half day User Story Mapping workshop with the whole team. During this workshop:

  • The whole team will form a shared understanding of what “it” is and is not.  
  • The work will be split up into work items of a size that your team regularly completes.
  • All of the work items will be estimated.

Having done the hard work of understanding what “it” is, determining how much needs to be done can easily be achieved by summing up the size of all of the work items.


How much has been done? 

This is simply a matter of adding up the size of the work items that we have completed that directly relate to “it”.


How fast are you completing work?

On average how much work are we completing within a cycle? If you are doing fortnightly Sprints and using Story Points; this question becomes “What is our Velocity?” or “What is the average of total Story Points completed within a fortnight?” If you are just starting out you may have to initially guess this figure. As you complete more sprints/iteration this figure will become more realistic; hence improving your forecast.


Create the forecast

Now that you know how much needs to be done, how much has been done and how fast you are completing work; you are ready to create a forecast. It is the forecast which will answer the question of “When will it be done?”



Example burn up chart showing forecast completion 1 day after the target release date.

For your first attempts at forecasting I recommend a Burn-up chart. A burn-up chart has work on the X axis and time on the Y axis. The burn-up chart is updated each unit of time (usually Sprints); providing a more accurate forecast each time it is updated.

 

The burn-up chart above shows five key pieces of information:

  1. The total scope (how much needs to be done) Purple - solid
  2. A projection of the scope into the future (what is the average increase in scope) Purple - dashed
  3. The total done work - Green solid
  4. A projection/forecast of the done work (based on your expected velocity) – Green dashed
  5. Where the two projections cross over, tells us the expected completion date - Orange

Please contact me should you want assistance in populating or interpreting your burn-up chart.

NOTE: Forecasting using a Monte Carlo simulation provides a richer and more realistic forecast; however they are complicated to set-up, and will not be addressed in this article. Please contact me if you would like to start using Monte Carlo simulations. 



Example of a completed project. Sprint review on Sept 1 indicated we were way off track. Note the large de-scoping that occurred shortly after and the increase of delivery from hiring one more experienced developer.


Continuous forecasting

Forecasting should not be a one-time activity; while it useful to do it once, its true value comes from continuous updating the forecast and holding regular conversations about what the forecast is telling us. For a Scrum team you should update your forecast at least once a Sprint.

Continuous forecasting will catch situations such as:

  • Our recent reduction in velocity has pushed out the expected completion date by 5 weeks.
  • Adding those new features has pushed out the expected completion date by 7 weeks. 
  • Each sprint we are finding more new work then we anticipated, at this rate we will never achieve our goal. 

If you started your forecast while in “Situation 2” there will come a time where the team has learned enough to move to “Situation 1”; this is a key time to update the forecast which could shift significantly. The earlier you can do this the earlier you can hold the potentially difficult conversation with stakeholders about when they are going to obtain their objective.


Wednesday, October 7, 2020

Project Steering for Games

The Games development is a highly competitive global industry; with hundreds of games launched or updated every week. To achieve anything more than mediocrity requires the entire value stream of game development to be working together effectively with each individual along that stream delivering a stellar performance. Maintaining a healthy company balance sheet, means each game project needs to have solid indicators of future success before significant time and effort is sunk into it. The Project Steering approach described in this article was something I helped to design and implement to keep multiple game projects on track while allowing those game projects the flexibility needed to find the next hit game. 


Context on company structure

The year was 2017. Game teams were the basic building block of the company. Generally, each game project was executed by one game team. Each game team was deeply cross functional including people who can cover the following as a minimum: design, development including engine development, QA, art, marketing, analytics. Each team was led by a Product Manager (effectively Product Owner and Team Lead). There was a strong emphasis on the PMs being servant leaders, who grow and develop a self-organising team. What I observed in games was that everyone was very passionate about the game they were developing and wanted to have a say in the direction it took. While this passion is intoxicating it could also lead to chaos; this why the Product Managers (PM) retain authority to make decisions. Retaining creative control ensures that the product follows a clear vision. 


Objectives of the Project/Product Steering approach

  • Ensure each game team is focused on regularly assessing if their current project is the best use of their skills, time and effort.
  • Balance the autonomy of new Product Managers (PM) with the control mechanisms that prevent significant mistakes from occurring. 
  • Support the Product Managers and teams to maximise ROI for the company over the long term; through feedback and guidance from experience leaders within the company.
  • Transparency of project Steering so that the whole company can choose to be aware of what is going on and learn from the success/failures of each game team.


Monthly Product Steering meeting

The key element of the Product Steering approach was a monthly public meeting held for each game project. During the meeting the Product Manager or a representative from the team presents from a standard template. The primary attendees are the Product Steering Committee*; however the meeting is public so anyone from the company may attend. The Product Steering Committee asks clarifying questions and provides non-binding feedback and guidance. Initially everyone apart from the Product Steering Committee was asked to observe only. Over time this gradually changed first with specific audience members being asked questions, then later open question time at the end of the meeting. 

These meetings were scheduled for 1 hour and some of the early ones took that long. However, in the matter of few months they were regularly completed in 30 minutes including question time.


Product Steering Committee

The Product Steering committee was composed of senior leaders who held a vast depth of experience in the games industry from around the world. I was also included; initially to help refine the template I had created for the meeting and after that stayed on as me asking the questions a 5-year-old would ask seemed to provide some value.

  • CEO
  • CFO
  • CTO
  • Head of Product Development
  • Head of Business Intelligence
  • Agile Coach


Preparing for the Product Steering meeting

While the Product Steering meeting was often insightful and helpful for all involved. The act of preparing for the meeting also provides a lot of value; especially for those Product Managers who were considering not holding a meeting. Often their desire to not hold the meeting is a subconscious move to avoid facing some uncomfortable facts about their project. 

Another positive aspect of the preparing of the meeting was that the Product Managers often reached out to members of the Product Steering Committee for assistance with preparing their presentation. These interactions were a chance to learn from each other and improve the direction of the project.


Regular feedback

Completing the Product Steering approach was regular 1 on 1s and feedback from the Head of Product Development to the Product Managers. This is massively important for less experience Product Managers and still very useful for the remaining Product Managers.


Common Presentation Template

The template was a two-page slide deck that provided answers to the key questions the Product Steering Committee wanted to see from every game project. Without answers to these key questions the committee members would struggle to provide effective feedback and guidance. Creating a consistent template helped both the Product Managers and the committee. For the PMs it cut down their preparation time, for the committee it meant they did not have to translate the information provided to them in different formats by different PMs. Additionally, it meant the committee had could compare game projects.

The PMs were free to add additional slides showing whatever detail they felt appropriate. Roughly three quarters of product steering meetings include extra information; such as partnering deals, highly feature maps, results of experiments etc.

Page One:

  • Product goal in one sentence
  • Declared intention (Persevere, Pivot game, Cancel game)
    • Sub section seeking input from Product Committee on specific topics
  • Product Health
    • Is the team learning what their customers will respond to?
    • Is the team delivering with suitable throughput?
  • Team Health
    • Overall morale
    • Specific issues affecting them
  • Financial summary, last three months
    • Costs, revenue, ROI
    • Projected financials, next month with certainty, next 6 months with low certainty
  • Results of objectives
    • Were last month’s objectives completed?
    • Did those objectives change?
  • Objectives for the coming month.
    • High level deliverables, learning outcomes, etc.

Page Two:

  • High level road map of deliverables, experiments, deals, etc. 
    • Current quarter was more detailed and showed when items were completed.
    • Next two quarters were highly level and subject to significant change




Sunday, July 12, 2020

Achieve more by delivering less: descoping is the secret sauce of agile teams that quickly achieve business objectives

Switching from traditional development to agile development usually results in a significant increase in the speed of delivery. This increase in speed partially comes from agile practices speeding up the people’s ability to build and test functionality. Interestingly the vast majority of this speed improvement comes from dramatically reducing the amount of functionality we are working on at once. By reducing our scope, the people are able to focus, gain fast feedback and quickly deliver outcomes. What is most interesting to me is that to further increasing the speed of building and testing functionality has a high cost; while further reducing the scope has a medium to low cost. This means that to achieve the greatest impact we should turn our attention to cutting scope where ever we can. This is the key to FAST deliver with agile.

To put all of that in numbers, adopting Scrum compared to Traditional methods usually delivers a 20% increase in speed of delivery. This can be gradually improved year on year, say 5% increases each year. When we cut out 30% of our scope from the first years’ worth of work, we are already two years ahead for a lower investment in effort. I am not saying stop trying to improve your development speed; please continue and add that to the gains to be made by reducing scope.“But our stakeholders have been promised X, Y and Z, you can’t just remove any one of them.” I hear you say. That is fine, we not going to remove those items, we are going to reduce the scope of each item, honing it in on achieving the business objective(s) it relates to. The business will still get X, Y and Z, it will meet all of its objectives; it will just be achieved with slimmer versions of X, Y and Z.

The approach to delivering business outcomes faster for less effort is not magic. It is a composition of basic agile practices, wrapped up in a feedback loop and supported with lots of collaboration. To start achieving more by delivering less, follow these steps.


  1. Scope what you know: google “User story mapping” to start.
  2. Split work into smaller pieces that are vertical slices: google “splitting user stories” to start.
  3. Forecast your delivery outcomes: Please refer to my blog post of Forecasting.
  4. De-scope to fit your objectives: explained below.
  5. As you learn more, repeat those steps just for the changes/additions/removals. 

A forecast indicating late delivery



Descope to fit your objectives

While this is titled as “descoping” it will not descope everything, some items will be deferred for later releases, some will be cut never to return, some will be split with bits done now, later and much later (aka never). Any item that is removed from the current release has reduced the scope of that release and hence will increase the speed at which we can achieve the business outcomes attached to that release.

To stand a good chance of succeeding with this approach you will need to understand the business environment and the objectives that the business (aka stakeholders) are setting out to achieve now and in the near-term. Understanding this will help to guide the splitting and descoping discussions; without this knowledge you are effectively operating blind. 

The work of “descoping” should be done collaboratively with a small group that represents a cross section of those involved, such as Product Owner, experienced Tester, experienced front-end developer, experienced DevOps developer. This small group should be able to move quickly, creating a view of the work that can then be reviewed more broadly.

Together the small group will repeatedly prioritise the backlog, split up larger items and move items between different releases until the delivery forecast indicates we have a chance of success (aka we have a chance of completing the release ahead of the targeted release date).

Forecast after descoping; indicating that delivery will occur ahead of the milestone

Prioritise the backlog

To figure out what to descope, and what to spend effort splitting up we need to prioritise and order backlog. When I say prioritise the backlog I mean ruthlessly prioritise by value! Forgort MoSCoW prioritisation it is too emotional; “oh I must have that”, “we should have that”. We need to be RUTHLESS! To get you started use “above the line” prioritisation. To do this visualise the backlog, draw a very clear line, then collaborate with the group to end up with only 50% or less of the items above the line. Now draw another line above that line, and repeat. You will end up with three sets of items: Top Priority <25% of the backlog, next priority <25%, and lower priority >=50%. These sets don’t have to correlate to your releases. What these sets give you is a clear view of what is important and not so important. You can even remove those lines if you like, they have no served their purpose. The backlog should also be ordered for dependencies.

Split up larger items

Larger items often hide within them some work that is crucial, some that is nice to have, and some we don’t need to do at all. Splitting up larger items helps us to uncover the work that we can move to later releases or not do at all. 

I recommend that you find the largest items in your backlog, split them up, move and/or descope those smaller pieces, then go onto the next largest items. The key to remember here is to split the work into vertical slices, it is all about finding what is valuable and what is not so valuable. If you split horizontally the value is spread across all of the split-out items and you will have wasted your time splitting it up in the first place. 

Move items between different releases

Whether your work starts out as separate releases/backlogs or as one larger backlog that you cut up into separate releases; having your work in separate releases provides you with flexibility in planning and how you communicate to your stakeholders about what is going to be done when.

I recommend that you always have one more release in your backlog then you include in your published delivery forecasts. This is the lowest priority release, the YAGNI release, later, never what ever you want to call it. This dumping ground allows us to keep all of the items around, reducing tough conversations with stakeholders that are deeply attached to something that should never be built. 

When you move an item from an earlier release to a later release you increase the chance of the earlier release being completed by its target date. Of course, the work has not disappeared just been deferred. With the rate of the change in most businesses deferring that item may mean it is never done; depending on your point of view that may be a win or a loss. 

As your small group updates these releases and their corresponding forecasts of deliver it is important to get the whole team to review them and to share them with your stakeholders.

Sunday, November 3, 2019

Under cooked Kanban, an opportunity to significantly boost outcomes


People proclaim “we are doing Kanban” all of the time, unfortunately the vast majority of them have an “under cooked” Kanban implementation and because of that they are missing out on the bulk of the value that Kanban can provide. “Boardban”   or “just pulling in work at will” are the two most common patterns of under cooked Kanban I see. Both of these patterns make some people “feel” very productive (usually the developers) however they produce little benefit to the customer (which is the point of being productive). These patterns make a small part of the system go fast, but produce waste, delays and management overheads for many other parts. Kanban is intended to operate as a cohesive package of principles and practices that re-enforce and support each other. If you are only doing part of Kanban (under cooked) I encourage to learn about the rest of Kanban and consider applying all of it.

This article highlights the pieces of Kanban that can be missing from under cooked Kanban, it explains the value that can be gained and coaching strategies to get you started. Regardless of whether your Kanban is for a team, a portfolio or a company this article will help you improve the outcomes of your Kanban implementation. 

Principles of Kanban


We are doing Kanban!

Sarcastic Response: That’s interesting. “kanban is a signal card used to pull more work into a value stream in a controlled manner. I don’t see signalling occurring or any control for that matter. Do you mean you are doing “The KanbanMethod? which is a rigorous approach for evolutionary change of your technology business? Unfortunately, I cannot see any structure, process, artefact or cultural norms that indicate your business will evolve into anything other than being more chaotic than what it is now.

Missing Element: Principles of Kanban

Helpful Response: Great, I am glad that you have decided to pursue evolutionary change for your business with “The Kanban Method”; it has been proven to work in many different situations and I am confident it can work here too. To have the best chance of successful outcomes with the Kanban Method we should be following its Principles.
  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Respect the current process, roles & responsibilities
  4. Encourage acts of leadership at ALL levels.

Do you have the whole management team onboard with the principles of the Kanban Method? They will be crucial in the coming months/years as your people collaborate to change the business.  While we started with your existing process, roles and structure (as per principles 1 & 3) we will likely change some or all of that in the future. Without strong management support the necessary changes will be blocked or delayed significantly reducing the outcome Kanban can help you to achieve. That is why principle 2 is “Agree to pursue incremental, evolutionary change.” We will also need management support for principle 4 “encourage acts of leadership at ALL levels”; we need them to actively support this AND to active not undermine it. Having them on board with this from the beginning will allow us to make the most of any “leadership” opportunities that arise.

We are doing Kanban, because it is better than X

Sarcastic Response: You are seeking to change your business because you heard Kanban was better/easier than X. But you have no goal, no objectives, seemingly no purpose. It must be time to declare victory already and move on.

Missing Element: Purpose and objectives for the change

Helpful Response: Are you and the management team clear on your current situation? I highly recommend System thinking approach to implementing Kanban (STATIK) as an approach to figure out your current situation and what your initial Kanban system should be. STATIK will help you know how fast or how responsible you need to be, among other things. It will help you to define your goals. On that note, are you and the management team clear on what you want to accomplish? Broadly speaking everyone is seeking to improve some of these items, while maintain the rest. Have you formally agreed what you working towards, even if it is just in the short term?

What are you aiming to improve by using Kanban?
  • Responsiveness | Delivery faster or change direction faster
  • Efficiency | Reduce your costs
  • Reliability | Increase your predictability and/or ability to forecast into the future.
  • Innovation of product or service | Produce more value or produce new value.
  • Quality of product or service | Improve the intrinsic quality or make it easier to support
  • Morale | Make your people happier or retain them for longer


If you would like assistance with running a STATIK workshop please contact me.

Practices of Kanban

With the principles agreed with everyone involved, we are ready to implement the practices of the Kanban Method.
  • One: Visualise the work
  • Two: Limit your WIP
  • Three: Manage flow
  • Four: Implement feedback loops
  • Five: Create explicit policies
  • Six: Continuous collaborative evolutionary improvement



None of the other practices are feasible without the first practice ‘Visualise your work’ being in place. Most Kanban implementations have this in place, yet few get past it. Without ‘limiting the work in progress’ (practice 2) it is not feasible to ‘manage flow’ (principle 3), also the other practices are significantly hampered in how much value they can provide. The remaining practices (Implement feedback loops, create explicit policies, evolve collaboratively and continuously) work a lot better when all of the practices are implemented together. Consequently, I view the practices in three sets that have sequential dependencies. Set 1 (visualise your work), Set 2 (Limit your WIP), Set 3 (all of the other practices). Most Kanban implementations visualise the work to some degree (set 1), some apply implementation Limit their WIP (set 2), very few get on the other practices (set 3) and hence miss out on a lot of value.



We are doing Kanban.
Sarcastic Response: Great to see you don’t waste time visualising your work, you are so lean. You must be completing all of your work so quickly that there is no point showing progress? Your customers must be over the moon with your performance.

Missing Element: Practice of Visualising the work (zero visualisation)


Helpful Response: Having your management and people doing the work bought into the principles of Kanban is a really solid foundation. Are you ready to start implementing the practices of Kanban? Good, I would recommend that we start by visualising all of the work. This helps manage our work, is easy to do and is the skeleton that the rest of the Kanban practices attach to.


We are doing Kanban; see we have a board!

Sarcastic Response: That is great news! “Boardban”  makes everyone except the customer feel better. People can work on whatever they want whenever they want; always being busy allows your people to feel productive while generating immense amounts of waste. Managers can see work sitting in the blocked column for months; and staff can explain to them how busy they are.

Missing Element: Practice of Visualise the work (incomplete/ineffective visualisation)

Helpful Response: That is a good start, visualising the work helps your people to better manage themselves and the outcomes. Visualising your work can also act as a subconscious limiter of the amount of work. To achieve more value from Kanban consider asking yourself these questions:
  • Do you have all of your work visualised? Have all of your people visualised their work? Without ALL of the work visualised:
    • Decisions about how to complete the work will be made with incomplete information, leading to poor decisions.
    • Delays and bottlenecks could be hidden.
    • You are unable to effectively move onto the next practice of limiting your WIP. There is no point reducing the flow from a visible garden hose, if there is a hidden fire hose on full, flooding your pool.
  • Can your people self-select their next work item? Does your visualisation provide all of the information they need to make an effective decision? Can you see the following?
    • The workflow steps.  Not process steps, the workflow steps. All steps from Idea to Cash.
    • The assignee or lead on each item.
    • The breakdown of work (which parent item do the children relate to)
    • Clear description of each work item
    • The items which are blocked.
We are doing Kanban; see I can pick up a new work item from the board whenever I like!

Sarcastic Response: That is great news! I see here you have 23 items in progress, you must be so productive. Oh, everyone is really busy, there is a mountain of work on this board. [Looking closer] Most of them are blocked, when you get blocked, do you just pick up another item, and keep on working.

Missing Element: Practice of Limiting Work In Progress (WIP)

Helpful Response: This board is very helpful, I am glad that you have it up and showing all of your work, this will allow us to bring in the other Kanban practices; which in turn will allow us to achieve our stated objectives (refer above for more details). The hardest step of Kanban is now before us, time to start limiting our work in progress.

Limiting WIP to deliver more value is a counter intuitive concept. It is a significant coaching challenge to help people get past their intuitive view. Some of the concepts to convey that help to get this across include
  • The big goal we are working towards is to deliver value to our customer.
  • Littles Law – the mathematical proof behind Limiting WIP leads to increase throughput.
  • Limiting WIP, increases throughput, even if staff feel less productive.



We are doing Kanban, there is a WIP limit on our “In Progress” column

Sarcastic Response: So, that one limit has optimised the flow of value to your customers. You must be a luckiest Kanban practitioner alive.

Missing Element: Practice of Managing Flow

Helpful Responses: It is refreshing to talk to someone who realises that limiting WIP delivers great results. It seems as if you are not actively managing the flow, this presents a great opportunity to get closer to your objectives.


Flow of value
  • Does your board visual the workflow up to the customer obtaining value? 
  • Do you apply classes of service to manage your different types of work?
  • Have you applied the Theory of Constraints (especially the five focusing steps)? TOC helps us to increase flow in an economically sound and sustainable manner.

Limiting WIP to increase flow
  • How do you limit your WIP? 
  • Have you tried limits other than column limits? 
  • Have you separated each workflow state into “doing” and “ready”?
  • Do you stick within your limits, when they are about to be breached do your people meet to discuss how/should this occur and also should the system be changed? 

Waste
  • What have you done to identify and remove the waste in your system? 
  • Have you limited your WIP until it exposed the delays in your system? Aka If your WIP limits have not caused pain you haven’t lowered them enough to find the delays in your system. 
  • Do you “Follow the work, not the worker”? This encourages better discussions and helps your staff make economically sound decisions.




We are doing Kanban, meetings and reviews are wasteful so we don’t do them.

Sarcastic Response: That is fantastic, our market never changes and we have no risks, so there is no need to spend time understanding them. I see everyone is 100% aligned to our development approach which is working flawlessly, so no need to spend time on that either.

Missing Element: Practice of Creating feedback loops

Helpful Response: You are managing your flow and that seems to be producing results, for now. The market you are in, and company you are part of and the work you are asked to do, is continuously changing; do you have approaches in place to identify and adjust to those changes? Kanban addresses this with feedback loops , aka a series of meetings with defined purpose, appropriate cadence, suitable input of both data and people.  Perhaps we could review them and understand which would provide value for your situation.



We are doing Kanban; we don’t waste time recording the process

Sarcastic Response: That is elegant; your process is so simple, that all of your staff have memorised all of the rules and regularly enacts them correctly, that is very lean. 

Missing Element: Practice of Creating explicit policies

Helpful Response: You do have a process though? Yes of course you do. What good is a process is only some people know it? What good is a process if some people are deliberately doing something different? Assuming those people are acting in the best interests of the company (which is likely) that would indicate the process is either wrong or incomplete. Kanban is a very process driven approach; that empowers everyone equally and removes heroes as the only way things get done. Explicit policies and the next practice of evolving collaboratively and continuously and tightly linked. Without explicit public policies how can your staff collaborate to change the policies?

Some lines of inquiry to help with creating explicit policies

  • Where are the policies currently recorded? 
  • Do they cover the whole approach? Are they consistent? Are the simple?
  • Are the WIP/Constraints visualised next to the work? 
  • Can your staff see the policies when deciding what next step to take?
  • Can your staff see the policies when they are reflecting on how the current system is working? 



We have been doing Kanban for over a year it has been great from the start

Sarcastic Response: Brilliant, so you got your process completely correct from the start. No need to tweak, improve or refine it, that is amazing! Ah I see so you do refine it, by yourself, ah yeah, no need to involve the others who do the work, better to keep them busy, they aren’t interested in how the system works as long as it works. Plus, you have a much better understanding of what changes are needed anyway. And no need for experiments, just make the changes that you know will work, you are the manager after all.

Missing Element: Practice of evolving collaboratively and continuously.

Helpful Response: You have all of the other pieces of the puzzle; it is time to unlock it through continuous evolutionary change done in a collaborative manner. It is the practice that ties Kanban together and delivers significant benefits over the long term; both in terms of staff engagement and achieving all of you other objectives. To get started it is ideal to have all of the principles and practices of Kanban in effect. We then need to add in suitable metrics and a scientific approach to running experiments on your system. The feedback loops we established earlier provide ample opportunity to carry out the work of evolving your system. Overtime the validated experiments that embed as the new way of working will maximise the value you deliver.

Summary

You don’t have to use Kanban. You can “under cook” Kanban and get some value out of it. To maximise your outcomes from Kanban, I recommend you apply all of its principles and practices. For assistance with this please contact me, to discuss how I can support your business to achieve more.


Friday, October 18, 2019

Mindset for lean start-up success



The Lean start-up achieves success through experimentation and Experimentation involves following a set of processes. With an output focused mindset, the processes seem cumbersome, over the top and a waste of time. When you think you already know what will lead to your desired outcome, experimentation seems wasteful. Just going through the motions of running an experiment won’t aid your learning and will just slow you down; so the experimentation is wasteful thinking becomes a self-fulfilling prophecy. This is something that we need to flip on its head for the Lean Start-up to have a chance of success. It is with a “Learning will lead to Outcomes” mindset that the value of those processes becomes clear.





We can start by promoting belief in the idea that experimentation leads to learning, which leads to outcomes and outcomes are more valuable than outputs. As people increase their belief in experimentation they tend to practice experimentation more rigorously and more frequently. This tends them towards perfect practice, which leads to their experiments generating more knowledge. As they gather more knowledge from their experiments they gain clarity around which outputs are more likely to lead to outcomes. With that clarity they can focus in on a smaller set of outputs with a good chance of producing a positive outcome. The effort saved can either be put towards working on other outputs with a good chance of success or entirely different endeavours. Either way those that apply experimentation appropriately, learn more and importantly deliver improved outcomes.

Tuesday, October 1, 2019

Feedback Dojo

Doing the basics brilliantly is a foundation from which organisations can achieve greatness. Doing the basics brilliantly comes from lots of little, almost insignificant things, done really well, done really well each and every day. We are talking about behaviour, the ingrained behaviour of all of our staff. Some of this behaviour can be established through sharing a vision, holding shared values, establishing a sense of purpose, clear frameworks & process along with understanding how they contribute to the organisation. Yet there is still a large amount of behaviour that can only be refined in a nuanced, ongoing, day by day, bit by bit approach, by those close to the people in question. Feedback enables us to bridge that gap and steer our people towards doing the basics brilliantly.
To achieve positive changes in behaviour feedback needs to come from a foundation of trust, delivered at the right time, in a private space. It is also crucial that it is delivered in a neutral way with a focus on behaviour instead of opinion. With many aspects of this skill required for it to be applied successful, lots of people struggle to provide effective feedback.
The Feedback Dojo is proven to quickly develop the ability of participants to deliver effective feedback. That feedback leads to positive changes in behaviour in their peers, colleagues and direct reports.



Tuesday, September 24, 2019

How to dramatically improve your product


Let us image… you have found your spark, you have explored the market space and found a problem worth solving, you now even have part of the product that may solve that problem. Your objective is to make the product the best thing for solving that problem. You have been working on this for months maybe even a year or more. The product passes all of your automated test but how do you know customers will actually be able to use it to solve their problem? When you think about how your product works you view it as a clear path to success, similar to the image below. 



You enter some information, tweak this, change that, press a button and taa-dah, the problem is solved! Unfortunately, we are often blinded by our closeness to the product. What our users often see is similar to the image below. A bewildering array of choices, with no clear path forward.



How can we show them the path? This is where Observational Testing comes in. Observational Testing allows us to understand the pains of our user allowing us to remove those pains and improve our product.

On Metacritic.com Half life 2 is the highest rated PC game of all time; Half life 1 comes in at #4. Both games are made by Valve corporation. One of the key practices that Valve used to take their games from mediocre to great is Observational Testing. They call it Play Testing. Valve would get in volunteers to sit and play their partially finished game, while members of the team would observe them and take notes. The team was not allowed to say anything to the player.

Quoting from Ken Birdwell a senior designer there: “Nothing is quite so humbling as being forced to watch in silence as some poor play-tester stumbles around your level for 20 minutes, unable to figure out the "obvious" answer that you now realize is completely arbitrary and impossible to figure out.” 
A two-hour play test would result in 100 or so "action items" — things that needed to be fixed, changed, added, or deleted from the game. That is a phenomenal amount of feedback.



I personally ran many observational tests when developing prototype games “Planty”, “Bargain Variety Store” & “Siege Breakers”, at Halfbrick Studios. I can tell you that observational tests are easy to run, horribly painful and immensely beneficial all at once. That hair pulling frustration of the user seeing a forest of trees while you see a clear path really pushes you to improve your product.

Running an Observational Test is straight forward:
  1. Bring in a customer or potential customer. This bit is hard.
  2. Provide them an objective to achieve in the test, either verbally or written out. This could be a hypothesis you want to test.
  3. While they attempt to achieve the objective, video record over their shoulder (a smart phone will do just fine).
  4. Observe what they do/don’t do; while not saying anything or offering any guidance. This is the hard part.
  5. Afterwards ask what they were thinking at key steps (i.e. when they got stuck, when they achieved success).
Observational Testing is how you can dramatically improve your product. It brings three key benefits:
  1. Challenge your design approach. Are we tackling this problem in the right way?
  2. Validate hypothesis. As mentioned the objective you provide at the start could determine if they will use the product in the way you anticipated. Can they understand the information provided? Etc.
  3. Dramatically increase usability. This is moving them from the forest to the path, and is the most evident benefit when people start to use Observational Testing.


Halfbrick Studios maintains full Copyright over Siege Breakers, Planty and Bargain Variety Store.

Photo Reference: https://www.flickr.com/photos/eggrole/7524458398