The first step is to understand that for a new product there is a unique value proposition hypothesis. This is the area where your product/service will be unique.

The next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of “Tablestakes” features just to make sure it is “Viable” as a product.

Your MVP is also an hypothesis. It might be good enough to find Product Market Fit or not. The case where each potential customer you engage tells you “This is great but in order for me to use it I need X” and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet.

If on the other hand you are seeing more and more answers pointing to the SAME X then it makes sense to revise your Customer/Problem/Solution Hypothesis.

You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP.

Let’s say MVP2 is successful and you are seeing real traction of early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopters crowd. Based on feedback you’ve been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them by the way extend your unique value proposition and some of them make your current product more robust.

In the case of areas with strong indication of value you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The aim of the MMF is to bring in value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped you feel comfortable working on the next MMF in that area. If on the other hand you want to wait and see if your first MMF sticks…

…then you are back in hypothesis land. But now your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a “pioneering” feature – the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers.

If you learn that the MVF has hit gold you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point look for alternative growth path. Essentially the MVF is a mini-me version of the MVP.

There you have it. The full model. Essentially my point is that you grow a product in uncertain markets by attempting various MVPs. Then once you achieve Product Market Fit you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on.

While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective.

The dinosaur carpaccio now comes in as slicing each of those pieces here to smaller slices aimed at reducing execution/technology risk. (typically these are called User Stories) Those smaller slices might have tangible business value but on the other hand some might not. It is more important for them to provide early implementation decision feedback along the way.

Feel free to use this model. Let me know what you think about it and how I can improve it!

http://bit.ly/AgileSparksMgmtWorkshopPrep - As the name says, this is recommended reading for our AgileSparks Management Workshops (The approach we use to help organizations choose how to start their Lean/Agile journey)

http://bit.ly/Kanban101 - An initial reading list about Kanban (used to introduce AgileSparks clients to Kanban in preparation for an engagement)

http://bit.ly/Kanban201 - Advanced Kanban Reading/Watching Materials

http://bit.ly/ScrumBan - ScrumBan  - collection of resources about the mashup of Scrum and Kanban (as requested by a client of mine recently)

And finally, for my hebrew-speaking audience - http://bit.ly/KanbanHebrew, which as the link hints is material about Kanban in hebrew.

And from the archives – What do I need to read to become a product owner (I’m also working on one specifically around story slicing/splitting – see a preview at http://bit.ly/StorySplitting)

Happy holidays and new year everyone, hope to be back with some fresh material in 2013…

PS let me know if there is a key resource you are missing in one of those reading lists, or a key list that I’m the right guy to curate…

October is Lean Kanban conferences season in Europe. I chose to return to speak at Lean Kanban Central Europe (#LKCE12) taking place this year in lovely Vienna. If you are not aware of the conference or still contemplating whether to come, here are the things I’m especially looking forward to:

• Chance to hear the latest and greatest from the Lean/Kanban/Systems community leaders – Keynotes from David J Anderson, Dave Snowden, Don Reinertsen are always home runs, no matter how many times I’ve heard them already. And I’m looking forward to hear Stephen Parry for another perspective on Lean Services.
• The funky and exciting Pecha Kuchas / Lightning Talks. I gave a Pecha Kucha for the first time in LKCE11 last year and found it was a great learning experience that affected my presentation style even in regular session. Can’t wait to see what the lucky Pecha Kuchers have for us this year. Can Arne top his Munich performance???
• The new rehashed version of Jeff Anderson’s work on transformation using Lean Startup concepts as well as Jasper Sonnevelt’s talk about Top Down versus Viral Spread, both very related to things I’m focused on these days.
• Combination of LEGOLand and smart advice about Toyota/Kanban Kata at Håkan Forss’s talk. I hope to hear what new he’s been thinking of since the Kanban Leadership Retreat last spring.
• Jim Benson’s talk is focused on Lean Meetings this time. I use Lean Meeting concepts I learned from Jim all the time. If you’ve never heard about Kanban Agenda Meetings, Lean Coffees and the like, you are in for a treat that will change your approach to the activity you spend a major part of your work life in… (If you’re interested in this also check out Death by Meeting by Lencioni )
• Attaching Kanban to the Command&Control World of Project Managers Nikolaus Rumm
• In Defense of Ambiguity by Joshua Bloom – Seems to tie in with Art of Action by Bungay which I’m reading at the moment. The power of Intent and maneuvering freedom in a complex world…

• Getting feedback from people on my “Starting with Manager’s Kanban” a.k.a. Starting from Product Stream Kanban concept, and use that feedback to improve how I’m using this pattern in big engagements we’re starting at AgileSparks these days
• Getting feedback from people on FLOWer, the AgileSparks process flow simulator/game, which we are just about to launch into private beta.

• Selling a couple of copies of Holy Land Kanban. Oh, and use a LKCE12 discount coupon for the ebook version if you can’t wait for a dead-tree copy!

And all of that is secondary to meeting interesting new people, seeing old friends again and having interesting discussions over great drinks and food…

So, see you in Vienna?

If my last postrattled your cage, let’s see how you like this one… This post is a thought experiment. This hasn’t been tried in the field, and might be the worst idea in the world. But at a minimum it might be a way to understand better Scrum and Kanban. Let me know what you think.

The Context

Let’s assume a client or stakeholder in the organization wants to go agile and Scrum has been dictated to us – something like “Hey – I heard Scrum is a good thing. I want one of that please. I don’t care about other kinds of approaches. I want Agile. Agile==Scrum. Give me Scrum. Scrum. Scrum. Scrum.” (only SLIGHT exaggeration of real life…) Let’s also say we like the Kanban Method of evolutionary change management towards Lean/Agile and we actually believe it is a better approach to change management in the discussed context. So basically it might be a nice idea to give the organization what it wants – Scrum, while giving the organization what it needs – an evolutionary approach to change management. Is that possible? Let’s try to use the Kanban Method thinking and principles while implementing them using Scrum practices and building blocks. Here we go, enjoy the ride…

Foundational Principles:

Start with what you do now

Well, Kanban says to start with your current way of doing things. Scrum is perceived as a revolution, so let’s see along the way whether we are able to minimize the changes to the current way of doing things.

Agree to pursue incremental, evolutionary change

This is actually quite easy to live with since Scrum is also an Inspect and Adapt framework that seeks to look for incremental evolutionary change using Scrum as a baseline.

Initially, respect current roles, responsibilities & job titles

Here comes a tough one. Scrum comes with roles, responsibilities and some might say even job titles. Let’s see how we deal with those. One way is to say forget it. I know you’ve read about Scrum Masters, Product Owners and the Scrum Team. But we believe there is no need to change roles & responsibilities up front not to say define new job titles in the organizational structure. This might work and is a reasonable approach but is quite a “cop out”. Lets try to go a bit deeper …

Scrum Team

At least the Scrum Team is quite core to how scrum works so we can probably say that we will define Scrum Teams that will not make any change to existing organizational structure. If we want to play strictly to “start with what you have” we can map Scrum Teams to the current functional teams whatever size they currently are and whatever skills (or lack of cross-functional skills) they currently have. A major alternative here is to start with “Managers Scrum”. See “Managers Kanban”for the general idea. Applied to Scrum this means leaving the individuals/actual teams alone for the moment. Just create a “Scrum Team” that is comprised of the managers of the relevant functional teams. These managers will run Scrum together for a while until they learn the ropes and are able to go sell and deploy Scrum with their teams, or alternatively decide that different teams might be needed before deploying Scrum fully… I will probably elaborate on this approach in a separate post. Let me know if it interests you to push it up the priority rank…

Product Owner

I would ask the organization who decides priorities or align priorities amongst multiple stakeholders at the moment, teach the “Product Owner” role and responsibilities and start with the people currently involved in the prioritization and backlog grooming activities wearing the “Product Ownership” hat. If needed, they will do it as a team. It is far from being the strong Product Owner that Scrum advocates, but we will evolve in a direction that deals with product ownership issues if we see that there’s a problem and that the Product Owner is the right solution. Some in the Kanban community have a strong case against the Scrum Product Owner. I have to say I’m on the fence on that one.

Scrum Master

Oh the Scrum Master… Well recently even in pure Scrum implementations we (AgileSparks) talk about the Scrum Master being a management style that should be undertaken by the individual leading the team (yes yes we believe that even self-organizing teams should have a leader that enables this self-organization). So I find it quite plausible here to talk about Scrum Master being a very good description of the coaching style of management that teams need in order to gel and perform better and better over time. And then I say we don’t need to define any specific role like that but the people leading the teams should be inspired. For sure we don’t define Scrum Masters as a position in the HR system. What we might do is find a great coach/practitioner candidate and ask him to play the “Scrum Master”/”Kanban Practitioner” role for the organizational unit (several teams)

Encourage acts of leadership at all levels

This is quite orthogonal to the actual flow framework we are using. But since Scrum is notoriously exclusive of managers (at least the perception is that it is…) lets make sure that managers understand they need to lead their teams to better and better performance, better and better alignment with what users/customers value. Of course Scrum Teams should show leadership by self-organizing to perform better and better. Those leading teams should show leadership by investing energy in team building and performance, decentralizing control while ensuring alignment with the organizational initiatives and values.

Visualize Work

First actual step is decide which teams comprise the flow of work and visualize the work flowing in and out of those teams using Kanban Boards and work in the teams using the same Kanban Boards or Scrum Task Boards if someone finds a very good reason to do that. Note in this step there aren’t any sprints or ceremonies yet.

We will use a Product Backlog with Product Backlog Items to visualize the “incoming”/”future” work. A Release Backlog can be used to visualize the subset of that work that is targeted for the current release. Work already in progress or done in this release will also be in the Release Backlog but with a status indication of the work state. Based on this information we can understand how far along in the Release Backlog we are and how the Release is doing. A Release level Cumulative Flow Diagram or Burnup can also help us visualize Project/Release state and help us feel safe and aware of what is going on.

Manage Flow

Now that we have the flow visualized we need to manage the work with the concept of flow. Here Scrum gives us some clear guidance that is helpful.

Iterations

We will work in Iterations of 1-4w (Also called Sprints although that is a horrible name. Sprinting should mean short-term acceleration to deal with a special situation. Iteration pace should be sustainable). Let’s assume a cadence of 2w here as that is a reasonable iteration length that many times use successfully and also allows a good frequency of flow management activities. So every 2w we will have a “Business Day” in which we hold :

• Iteration Demo – review the completed work of the last iteration and get product-level feedback on it with relevant stakeholders. The completed iteration should be available as an increment of Potentially Shippable Product which means all items completed are working tested software and the relevant build is a candidate for shipping after no more than a short (few days) hardening.
• Iteration Retrospective – review and adjust our processes based on the last iteration
• Iteration Planning – based on what’s next on the product backlog,  product-level feedback from the Demo and process-level feedback and decisions from the Retrospective, We pull backlog items into the next Iteration. Pull = We take in the right amount of items to have an effective iteration. Not too few to avoid being bored. Not too many to avoid too much multi-tasking and context switches and the danger of not completing anything. Another meaning of Pull is that the team working on the iteration does this planning and makes those decisions. It is important to have a couple of more product backlog items queued up in case we are able to accomplish more than the amount we pulled. The purpose of the planning to is to establish this focused “Iteration Backlog”/Forecast and verify everyone on the team and in product ownership on the same page regarding what the relevant product backlog items mean, the priorities between them, how they will be demonstrated in the Demo, and the level of quality/functionality expected to say they are done (Definition of Done / Acceptance Criteria).

Make process policies explicit

We also made some of the process policies explicit by setting the “Definition of Done” of items to be declared Done at the end of the iteration.

Now’s the time to make more of our current policies explicit. Use your current de-facto ways of operating. You will have a chance to change/improve them in your process adaptation feedback loops:

• What is the level of readiness of a product backlog item before the team is ready to pull it?
• Any definitions for the interfaces between roles in the team?
• Any other clear policies governing the work of the team, relations to product ownership, etc.? Estimation policies? Defect Fixing? Release Criteria?

Limit Work in Progress

Now after we have a flow system working, it is time to apply the real pressure. We need to constrain the system to guide it towards better flow. In Kanban we do this by limiting Work in Progress. Applied to Scrum this translates to constraining ourselves to work just on items pulled into the Iteration. We will not start working on any other item unless the Iteration is safely done. This sounds trivial, but when there are several people with different specialties on the team it is not trivial at all. It drives people to collaborate. It drives different pains/inefficiencies to the surface and requires us to deal with them.

Note that the Iteration focus is not the ideal way to limit WIP. It is not that clear and explicit and it is harder to go on a diet that tightens the WIP limit from iteration to iteration since the Iteration focus is based on velocity which might not improve so fast even if our focus is improving. Also note that in order for the Iteration Forecast/Backlog to be effective WIP limits we need to plan carefully our capacity and capabilities for the whole iteration to avoid taking on too much (and not challenging ourselves to focus) or too little (and straining our focus to an unrealistic and unhelpful level).

We can always later apply classic Kanban per-lane WIP limits of course. And since many people that want Scrum don’t really understand that the Sprint Forecast/Backlog is a way to constrain and guide improvement we can just skip to the easier and clearer approach of per-lane WIP limits. This will also make it easier to get across the end of sprint inefficiency.

Improve Collaboratively using Models

A remaining but important feedback loop is the Ops Review which is a data-driven feedback mechanism that increases accountability to improvement results and accelerates improvement activity. We will add this routine later on typically. There is nothing like that in Scrum but there is nothing saying it shouldn’t be done. Just add it on top of Scrum when the organization is mature enough for it. (I would say after a few months of managing flow and limiting WIP so the systems are stable, clear problems have been solved using Retrospectives, and it is time to seek more pervasive improvement opportunities. )

At this point we try to decentralize the improvement activity to the teams/people. We give them different models to use like Variability / Positive Deviants / Queuing Theory / Principles of Flow / etc. and expect them to suggest and execute improvement experiments and share successful conclusions for reuse by other teams.

Conclusions

I hope this article conveys the message that the Kanban Method can be applied using Scrum as the process framework. This can be useful in case Scrum is chosen by the organization due to various reasons but we believe an evolutionary guided change approach is a good fit for the context or we would like to complement Scrum with the useful change management ideas in the Kanban Method.

I’ve yet to try this in the field but the biggest risk I see in this approach is that Scrum IS focused on flow at the team level and there’s the danger of localized focus when using it as the main process framework. I also have an hypothesis that starting with “Manager’s Scrum” looking at the end to end flow rather than work at the team level this might be overcome.

I’d love to hear what others think. Does this makes sense? What would you do differently?

Based on experience helping organizations go agile in the last few years, an emerging attractor for healthier more sustainable results seems to be the “Starting with Managers” pattern. This is a “training wheels” pattern which seeks fastest learning of the managers in the organization what going towards an agile flow feels like and entails as well as the fastest learning as to whether that is an approach the organization wants to commit to and deploy. Basically all elements of Kanban – Visualization, Flow Management, Explicit Policies, Improvement Feedback Loops etc. are implemented with Managers. People are aware that it is happening but not expected to directly change their behavior at first. They might get different “directions” from their managers due to different flow decisions but they are not “pulling work” on their own. This pattern is a change management pattern that seems to generate more buy-in and support at the managers level, which manifests as faster “stop starting start finishing” thinking, lower resistance and viral distribution of kanban systems in the organization.

For more details, see below…

The Context

Let’s say we are talking about a group with about 50 people. This group works on several products or projects at the same time, with a functional team structure mapped to the technology stack e.g. GUI, Business Logic, Database, Infrastructure, etc. Each of those functional teams has a team lead/manager, there is also a QA group which is mapped functionally as well (though sometimes QA is already a bit more tuned to the product side). This can be either the whole R&D group of a small-medium product company, the IT unit of a medium organization, or a product unit at a bigger enterprise product company or one IT department in a bigger IT unit. The majority of engagements we run at AgileSparks are comprised of those atomic units, sometimes standalone and sometimes as part of a bigger enterprise engagement.

The Typical Approach

What we did until recently wouldn’t be a big surprise to anyone. We went in and implemented Scrum or Kanban at the team level combined with an end to end flow system typically using Kanban. You’d see the typical buzz and hassle of launching a couple of teams, training dozens of people, preparing backlogs and boards, and running iteration ceremonies for a couple of times until there is a stable agile framework running in the organization. Even when using Kanban it is still a big change to create all the teams, their kanban systems, teach them the ropes of how to manage flow, and work with each of the teams to start improving using WIP limits etc.

This approach has definitely been successful many times at bringing an organization to a “steady as she goes” agile delivery process. But I felt with so much energy invested into it it is a shame we cannot get even better results. We want to reach a “Continuously Improving” organization. And on top of that I always felt a certain friction/unnecessary tension while leading these engagements. In a combination of methodically looking to experiment with how we do things together with a string of “different style” organizations that wanted a different less “gang-ho” approach an alternative emerged.

“Managers are the biggest impediment”

The center of my exploration has been the role of managers in the success or stagnation of agile change programs. Looking back at previous engagements, in “Bright spots” I was typically able to create a stronger more involved management layer that drove agility forward. In cases where the focus was on teams and I couldn’t get managers to engage the results were mediocre. Every Agile survey you read says something about managers being the biggest impediment. They don’t support agile, they don’t enable agile, they don’t trust the teams, they are not patient, etc. I have a slightly different take on this.

I believe “Managers understanding is the biggest impediment”. They don’t understand enough about why agile and flow works. What is the role of constraints in driving improvement. What pull mode actually means. Many of them show a lot of good will and ask “What do you need for me” and get confusing answers. And we shouldn’t be surprised. We spend most of our energies and time on showing teams how to work in agile, why would the managers understand? Maybe it is my Israeli upbringing but as a Manager going on a new endeavor with my people I want to be first. I want to understand the deepest what it will entail. I want to be in front, not in the back. And so far we’ve been asking managers to take the back seat in agile change management programs.

So is the solution management training? Discussion of “Agile Thinking/Values” ? management offsite? These can be part of the solution, but if they end and then all the actual agile experience is at the team level with managers back doing their own things, I think it wouldn’t work. We are talking about changing the way the organization thinks and it’s de-facto mode of operation (Schein even calls this Organizational Culture). I believe in order to achieve that, managers need to run in front, be the first to try different ways of behavior, understand what they mean for the organization, and if they see it is a good way that should be repeated lead their people by example.

Start Small, Managers First

With this in mind, the concept of “Managers Kanban” emerged. This happened at around 3-4 clients around the same time with varying results but all of them quite encouraging ranging from stable and improving in a very difficult environment to another case with viral spread of kanban systems in an organization which is known to be very careful and measured in its approach to trying new things.

The concept is quite simple. Familiar with the Kanban Method? Great. Now choose an end to end Value-driven flow like a Product line or Project. Look at all the functional/technical teams involved as well as other stakeholders. Create a Kanban System that focuses on the interaction between those people. Typically the task-level work done by individuals engineers in the functional teams will be abstracted out a bit but in any case this system is like a chess board. Managers move their pieces and take action that they then translate to marching orders for their teams. When an event comes up at the team level the Manager is the one reporting about it at the end to end Kanban system. How do they manage their own team/people? I don’t care at the moment. Wait, I actually do care. I recommend they continue with what they did so far, at least for a short while.

One thing to note about this Kanban system is that it is a multi-level one. It starts with Features, moves to Minimally Marketable Features which flow end to end. When in development those MMFs are broken into User Stories. Each such story while in development can be in different states in multiple functional teams. These so-called “Team Stories” are visualized here in using different vertical lane per team, where each user story takes up one horizontal lane/position with a box in each of the team lanes to mark the involvement of that team in this story. The state of the work on this “Team Story” involvement is visualized by marking the box as empty=TODO, half-full=WIP (or even indication of % complete feeling e.g. 1/4 complete, 3/4 complete etc.), full=DONE (and waiting for the other Team Stories to be completed for the full User Story to move to DONE). This was a nice emerging visualization we came up with along the way. When they moved to an electronic tool (LeanKit Kanban) they started to use Avatars to just track involvement (It is very easy to track flow of Team Stories using the card taskboard capability though). A different company is using a somewhat involved swimming lane structure in Digite Swift-Kanban to visualize the same information. 

To manage/lead this Kanban team comprised of Managers we typically assign a higher seniority manager. His role is to design the kanban system with the team, manage the flow, manage the improvement work. The side effect is that we get the management chain involved, leading. In the best cases even the VP of the group was involved in the system design and flow management/retrospective meetings. Nobody is excluded. When you start hearing the VP saying “Is this inline with Stop Starting? Do we think that so many things currently in WIP is healthy? What do we need to do in order to reduce it?” you know that there is something healthy going on. In some cases the “Project Manager” was assigned to lead this Kanban team. The benefit is that we instill lean/agile thinking into the Project Managers very quickly this way. The downside is that we don’t get the same traction with the core R&D managers this way. I don’t believe this is a core problem with the approach, just something to fine-tune. The important point is to make sure senior managers of the functions do a lot of “Go See”/”Gemba” – come from time to time to flow meetings that happen several times a week, pay a visit to a retrospective, etc. Ideally each senior manager should be the sponsor of one of these “Managers Kanban” and be accountable to achieving good flow and learning.

A great side-effect of this is that as the coach (internal/external you get much more face-time with the managers to gauge and influence their thinking and behavior.

Another way to look at this pattern is to see it as an answer to the question “What is the minimum viable change we can try to show us whether managers can really start thinking and behaving agile/”Stop Starting Start Finishing”? On the way we of course also let them learn how real agile thinking/behavior looks like so if they are convinced they want it they are well-positioned to take the next step and deploy it more widely through the organization

Viral Spread

When things go right, managers indeed “get it”. They “get it” so clearly that they go out and experiment with Kanban systems at their teams without the organization even suggesting it. All they need is permission to experiment and boards start popping up on the walls or in the electronic kanban system. In one example we seeded two “Manager’s Kanban” product-stream level systems and after a month or so we saw about 5-6 team-level kanbans in both R&D and QA popping up. The Product Managers that were lucky enough to be involved in the “Manager’s Kanban” experiment talked to their friends who grew jealous and wanted a Kanban system for their Product-Stream as well. Before long the constraint became wall-space and time to help nurture those self-emerging kanban systems. This doesn’t always happen though. I’m still not sure what are the key factors for virality here. I tend to think it is related to organizational openness and the amount of leadership by example and commitment to the “Manager’s Kanban” shown by the core R&D leadership, but it is certainly an important area to do some research/experimentation on.

Results

When I look across the different case studies I see different depths of implementation after around 9-12 months. But the common factors are reduction in the observed pains that led to looking at lean/agile as well as stable system of flow management – Visualization, Manage work according to Flow, Have explicit policies governing flow. There is typically quite a shallow shaky discipline around WIP limits at this point (which is quite typical in general for this stage whether it is Scrum or Kanban style of WIP limits being used) but there is the understanding and awareness that it is shaky and should be improved. There is also a shallow improvement practice/culture. Retrospectives and Kaizen moments but no model-driven improvement and no operation reviews, just initial sparks of looking at metrics and using them to drive ideas for improvement.

There are strong encouraging signs that the organization is looking to stabilize the flow and improve it. I’ve observed steps towards Continuous Integration, Feature Teams, ATDD, Continuous Stabilization (get rid of the stabilization lane and include it in the definition of done of testing) all driven from seeing flow (or lack of it…). There is also a lot of fine-tuning around the structure of the kanban system itself. The board, the meetings/ceremonies supporting it, who’s involved, etc. There is a slow but sure trend of people from the teams becoming the representatives in the end to end kanban system, on the way to a full kanban system without the need for “representative democracy”.

Another interesting area of experimentation is what kinds of extra team boards to maintain beyond the end to end boards. At the start these were (quite naturally) standalone boards e.g. Infra Team and Infra QA Team on different boards). Over time we are seeing more and more integrated boards being experimented with as a way to reduce the synchronization overhead that comes with a complex network of kanban systems.

Why I think it works

My hypothesis is that this pattern ensures the most important parties and the “usual skeptics” are on-board before going further with the change, using a practical experience rather than conference room convincing. It creates a very natural demand for full pull systems that decentralize control rather than having that dictated by the change framework. To me it sounds a very natural consequence of Kanban Method thinking which is I guess why I found myself doing this before I deliberately thought of the pattern.

Challenges/Impediments

This is far from a perfect solution. There are many challenges here. Some of you might have guessed them already. The main one is that this is not a scalable way to manage an organization. If all work is managed using “Manager’s Kanban” then managers continue to be a coordination bottleneck. There is a limit to the amount of kanban systems a manager can take part of and since lean/agile means working with smaller batches/work items the coordination costs will actually grow higher. For example the Infra Team R&D manager needs to monitor needs from his team across almost all product stream kanbans, synchronize that with his own team kanban system, sync with the QA lead, etc. This is a serious headache and cannot continue forever especially if the organization wants to scale to more activities more people without growing the management ranks significantly.

This is why “Managers Kanban” is just a temporary “Training” pattern on the way to full flow pull mode. You can consider it a kind of “Concierge MVP” - the goal here is learning about what works and is viable as a flow model. It is not a viable long-term model of managing the work. It considers the main risk of going lean/agile being the ability of the managers to think lean/agile, think flow, act according to lean/agile decision filters. When this risk is off the table, it is time to go to the next stage which is sustainable lean/agile involving the individuals with managers supporting but not necessarily involved day-to-day in the flow of work throughout the organization. The classic next step is to create stable Product Stream/Project/Feature teams that will be able to work together with Product Management on a specific value stream. These can be cross-functional, functional teams or a mix depending on the kind of work the organization is facing. Read more about those teaming options in an earlier blog post of mine.

Where Next

It really depends on a case by case basis but there are some lines of similarity in the next steps decided on by the different organizations I’ve worked with. 

All of them are re-energizing their discipline and attention to Limited-WIP/Pull discipline. This includes monitoring WIP levels, trying to look deeper into reasons for WIP level exceptions, and providing the slack capacity to do something about the constraints leading to those high levels of WIP. In many cases this touches on the tough spot of Versatility of individuals and Collaboration between different managers and teams. All senior managers I talked with feel the pain of lack of collaboration between silos. And by now they all understand that implementing WIP limits effectively is a good way to drive towards collaboration, even without changing the organizational structure.

The other front is deepening the improvement routine. Retrospectives and chance kaizen moments are fine for the first steps of creating a stable system since the pains are very clear. But in order to sustain guided improvement the next step is to adopt something like the Toyota Improvement Kata as an organizational routine. This entails revisiting the goals/pains, setting up metrics that align with those goals and running a routine of improvement and coaching towards improvement, with Operational Reviews being a key part of continued engagement and accountability of the managers towards improvement.

Summary

I hope the initial shock of keeping the individuals out of the picture initially is wearing out by now… I would love to hear what you think about this pattern. Would it have helped you deal better with situations you encountered in the past? Would you consider using it? How would you improve it?

One question I’m playing with is how much of this is Kanban-specific and how much can be leveraged in a Scrum context. I tend to think one can create a “Managers Scrum” system but it is probably a bit more involved than search & replace kanban with scrum in this article… Expect a future blog post about this…

This is the topic of my upcoming session in Lean Kanban Central Europe 2012 in Vienna by the way. If you are around and interested, come and participate. I will try to make this an interactive session with room for opinions and ideas.

updated: Added “Why I think it works” section

I’ve been talking recently about the challenges of keeping sustainable sticky Continuous Improvement programs. An aspect I’ve mentioned but not emphasized enough is the lack of management attention. In this blog post I will focus on why management attention is so important in improvement programs, why is it lacking and what might we do about it.

Why we need management attention

Basically to change the system of work you need the attention of people that are in charge of it and can change it. If they don’t have enough capacity to work on the system you will end up stuck. You might find yourself focusing on local optimizations, you might even make progress in things that affect the overall system, but changing things like management decision filters, approach to targets (or lack of them…), relations between silos and the like will be difficult.

You might rightly ask: “Aren’t we supposed to trust the people working in the system and empower them to take charge of the system design and improvement?”. Yes we should! But getting to such a system typically requires significant change/transformation of how the system of “changing the system” works. You need attention of the people in charge of that system to change it. We’re back at square one aren’t we.

You might make a case for Guerilla warfare – working with people on the ground to change the system of work without showing up on the organization’s radar or at least without requiring formal support. That might work for initial “scouting” and establishing a case for new ways of working. I haven’t seen or heard of cases where the guerilla warfare was able to scale the change in a persistent healthy way throughout the organization.

So basically, can we agree that at least at some point of changing the system of work or system of improvement we need the people managing the system to start investing attention/capacity cycles in studying and improving?

For my inspiration on this term of “Management Attention” and it being the constraint of our systems you should watch Exploiting the Constraint: Management Attention by Eli Goldratt.

Why are we lacking Management Attention to Improvement work

Many managers don’t pay as much PERSONAL attention as we’d like to studying and improving the system of work or in the capabilities of their organization. Why is that?

Some managers thrive on urgency and opportunities for heroism. One can probably inquire about the ecosystem in which those managers thrive and who is responsible for changing that system. Basically as long as the organization cherishes and commends this kind of management rather than quiet steady capabilities-focused management we shouldn’t be surprised. The counter-measure? Seek to change this “policy” constraint which typically is driven from way up… This can be hard, but if you don’t deal with it don’t expect much traction.

Other managers DO care about improving the capabilities of their organization. They DO care about the system. They just don’t have the capacity / cycles to invest in it.

Let’s pause for a second and reflect on this issue from a different perspective. We’re all familiar with the team that is so busy delivering value that doesn’t have time to retrospect let alone take action towards improvement. What can such teams do? They can start by bringing their system of work under control using approaches like Kanban or Scrum. Then they can start allocating capacity to improvement. Scrum forces team to spend at least the “Retrospective” ceremony time for improvement but still many teams don’t take action based on the retrospective. Allocating capacity towards “Improving the system”/”Housekeeping”/”Engineering Improvements” or however you want to call it is key to getting actual results and feeling that the time spent in Retrospectives or Kaizen events is well spent. This allocation of capacity can be achieved in Kanban by always having one experiment in progress for example. Or one experiment in every Sprint Backlog if Scrum is more your cup of tea. So what can we learn from our advice to teams?

Personal Agility for Managers – Exploiting the constraint

A manager can start to bring his work under control by using an approach like Personal Kanban. Once under control he can start allocating capacity and attention towards improving. Improving his personal system of work, so he can free more and more capacity to strategic themes in his system of work. What might those be? For example driving and supporting improvement agendas of the organization he’s in charge of.

If managers are a key leverage point for improvement programs, we can also see them as bottlenecks/constraints for the “System of Improvement”. What we are suggesting here is to focus on this constraint and ensure managers achieve the best results they can with the time they have.

Decentralized Control – Subordinating to the Constraint

The next step is to subordinate to this constraint. Subordinating means to look at the system and finding opportunities to divert work from the constraint elsewhere, or do work in a way that makes the work of the constraint easier/faster. One way to achieve that is to Decentralize Control. If more and more work can be decentralized, we can free management attention/time. This can be “work” decisions such as what to pull, how to deal with conflicts etc. It can also be “improvement” work. They key though is to do it right. Not just decentralize but give good guidance as to the Intent of what we are trying to achieve. For a great talk on this subject watch Donald Reinertsen’s LSSC12 Talk.

 Takeaways for Lean/Agile Journeys

My current thinking is that helping managers improve their personal agility using approaches like “Personal Kanban” should be a key building block of successful improvement program. I started nudging managers I’m working with to consider this when I’ve seen them become the constraint for the “Improvement Journey”.

It shouldn’t come as a surprise that many of AgileSparks‘s current clients are exploring “Personal Kanban” in parallel to improving their wider systems. We are also working to help them pro-actively. AgileSparks coaches such as Danny Kovatch have been working on Personal Agility programs and approaches for a while now, Jim Benson exposed many people in israel to Personal Kanban in his Agile Israel 2012 talk as well as a workshop he ran when he was here.

A great side effect of working on something like “Personal Kanban” while running or preparing for a “Kanban Method” journey is that a key group of stakeholders for the journey are experiencing it first hand and leading by example. If they can “Limit WIP” and show to people they are doing it, there’s a higher chance that “Stop Starting Start Finishing” will stick on the team kanban board. Or on the portfolio board. It might be an interesting approach to start with Personal Kanban as preparation ground, even before management attention surfaces as the constraint. OTOH we might be working on a non-issue. If managers are not the constraint in a specific situation, should we still start with their personal agility? I can go either way on this, and would love to hear what other Kanban practitioners/consultants think.

Bottom line

There’s a good chance management attention is the constraint of your system. Identify if that is the case. Exploit it by offering managers “Personal Kanban” as an approach that can help them free scarce capacity. Subordinate to this constraint by Decentralizing Control intelligently while aligning using strong Intent. Leverage the cool side effect of having managers use similar approaches to take control of their work that their group is using to take control of its work.

TODO in a future post: How can we reliably identify if management attention IS the constraint? I have several thoughts on this, but will leave them to a future post.

Your turn

What do you think? Is management attention a typical system constraint? Is personal agility a good way to deal with it? Have you found other ways that worked for you?

Now what do we do about “Make policies explicit” and “Improve Collaboratively, Evolve Experimentally”? Sagi Smolarski (who recently joined the AgileSparks ranks) and myself have been working on creating an experience that focuses on experimenting with policies seeking improvement while using ongoing quantitative feedback. Sort of a dynamic accelerated “Ops Review” simulator. It is still under wraps but we are readying it for a private beta release which will happen very soon. An example scenario would be to start with a certain combination of capacity, demand and system design, and try to fine-tune the system design using policies like WIP limits, definition of done for queue handoffs, swarming preferences, etc.

The AgileSparks Flow Simulator – v0.1

Mastering and honing a “static” context will not be easy, as we are trying to model several aspects we encounter in the real world such as the downsides of “too many cooks in the kitchen”, costs of delay both for value erosion as well as cost increase and chance for defects. Finding the right WIP levels for a system will not be easy.

But then at some point we will add “dynamic” transitions into the equation. Can “Slack” help you improve your capabilities? Will you now need to fine-tune the system towards a new balance? Is it worth allowing this “Slack” or squeezing as much value now from the system?

Some of the above is in our “To do” column, some of it in the “WIP”, and some of it already “Done”. I’m really anxious to be able to show this to the Kanban Community and whoever is interested in learning about the Kanban Method. If you are interested as well, let us know

I recently had a couple of weeks with a few activities related to “Agile Testing”. “Agile Testing” for those not familiar with it is the name we give to the set of thinking guidelines, principles and practices that help run the testing aspects of product development/maintenance in a more effective way under an Agile delivery approach.

A question that came up while presenting the concepts today at a client was “What’s broken? Why do we need this?”. While my presentation covered some of the rationale the question made even more clear (not that I needed any convincing…) that the guided evolutionary approach to improvement is a winner. If they don’t yet feel the need/pain there is a lower chance they will do something about it.

The question comes up – why don’t they feel the pain? Or alternatively, maybe they feel the pain but don’t associate it with the need for “Agile Testing”.

So I wanted to briefly touch on a few questions/indications that you might need to pull ideas from “Agile Testing” as your next improvement step.

Some indications you might need to look at “Agile Testing”

• You applied WIP Limits and testing is becoming a bottleneck. Not once or twice, but quite consistently.
• You agreed to include test automation as part of the “Definition of Done” and you are seeing a queue building up meaning the automation is slowing the entire process down, creating significant slack for the people NOT doing automation.
• You find a lot of defects which send you to rework technical design due to lack of mutual understanding of the functional requirements / stories, or you find yourself leaving things ugly since there is no time to do the rework – earning you some customer feedback that you are not really providing high quality deliverables.
• You are not able to run a very granular flow – everyone claims smaller stories are not useful since the overhead to deliver them to testing and test them is so high. Let’s just keep using bigger items and deliver to testing not more than every 1-2 weeks.
• People feel that the test automation approach you have now doesn’t cut it. The total cost of ownership / lifetime costs are very high, and even though people understand the need to have automated coverage in order to integrate often, they are very frustrated by the costs.
• Testers are confused. Do they need to be automation specialists? Domain experts? Technical experts? Supermen? In this Agile Whole Team approach where there is flexibility and collective ownership – what is their unique value? what should they focus on?

My latest presentation touches on some of the reasoning why these issues come up when going Agile, as well as introduces how “Agile Testing” can help. For more about this you are welcome to join me at one of the upcoming Agile Testing workshops AgileSparks runs in Israel and Europe. Contact us for more information.

So I convinced you that the Scrum Sprint Commitment is not such a great idea. I convinced you it is mainly there for learning. You want to move to a commitment to try to meet the forecast instead of committing to deliver the whole forecast. But your Product Owner has a real problem with this. He understands all this learning rationale but his stakeholders want to know whether he can promise then a certain delivery on a certain date. So can we make promises without the Sprint Commitment?

Making promises to deliver certain backlog items in this sprint

Sometimes a Scrum team is expected to deliver certain backlog items for a specific sprint. Examples can be stuff other teams need to consume, a fixed date commitment to clients, a regulatory requirement etc. Such backlog items have a very high cost of delay so we want to really make sure when we promise to deliver them we deliver them. One way to make sure that is to put them at the top of the Sprint Backlog. If the team is working down the Sprint Backlog by priority (as they should) there is a higher chance they will deliver these backlog items.

But I believe we should be more explicit. We should have a clearer signal that these are special fixed-date items and clearer policies for what to do to make our promises around them. In Kanban teams use classes of service for this purpose. I recommend Scrum Teams in such a context simply do the same. Mark these items with a special color in the Backlog. Establish policies such as “If they are in danger we make whatever effort needed to deliver. Sustainable Pace will be put on hold”. Visualizing that these items are different will earn them a different class of service by the team. It also means that normal items without this fixed-date commitment might be put aside to make the extra effort to deliver those, even at the price of overall throughput. These items might call for deeper estimation and planning up front than normal items.

One key point is to make sure that these fixed-date items are not the majority of items in the Sprint Backlog, otherwise they cannot rely on preferential service. If you have a case of your whole work being fixed-date driven you need to be extra careful with planning and consider taking a time-buffer to protect against the inherent variability in sprint results.

With time the Scrum Team and Product Owner will learn about their ability to deliver these items and might be able to make promises earlier before the Sprint Planning, knowing that the price will only be the effect on other normal items in the sprint.

Making promises to deliver on a bigger project across several sprints

I won’t go deeply into this aspect in this post. Normal Agile Release Planning using history of throughput/velocity and setting hard commitments and soft commitments is the way to make promises you can keep. This means that within each sprint there will be a certain level of hard commitment related to the overall project hard commitment. If that level of commitment is already a stretch for the team then you have a dangerous project in which you cannot really expect to have safe-to-fail thinking or improvement, rather a tight focus on meeting commitment. Sometimes we have those projects. If you are always doing these kinds of projects time to look in the mirror and have a discussion about whether you are really trying to set up the organization for opportunities to improve/learn or just constantly meet commitments without any slack for improvement.

Is starting with Kanban really easier than with Scrum?

Kanban is often described as a way to achieve evolutionary change in an organization, creating less fear and resistance than more “revolutionary” approaches such as Scrum. Kanban indeed respects current processes. For example, in its first steps it does not impose role and responsibility changes, but encourages continuous small incremental and evolutionary improvements to your current system. But is it really an easier way to launch a change process? Always? The last few Agile implementations I was involved with that used Kanban as a starting point made me contemplate this topic. Here are some of my thoughts.

Implementing Kanban seems to be simple technically. Just visualize your current process, build the Kanban board and describe your process as a pull system. Kanban does not prescribe specific practices, but the team is expected to apply lean thinking tools such as limit the WIP, focus on flow, optimize the whole, stop the line and fix (focus on quality), find bottlenecks, protect the team from external interruptions, etc. This requires high maturity from the team. Unfortunately, in many cases, teams find themselves struggling at the starting point, especially when attempting to apply the “limit the WIP” step. This can be extremely difficult and requires good collaboration and shared responsibility between the development team
and the PO in order to allow balancing demand and
throughput. When this collaboration is not mature, teams tend to get stuck and find it hard to move forward, which leads to frustration and increases resistance to the change.

Shape the path – Script the way

Scrum’s prescriptive nature is more suitable for such immature teams as it “scripts the way” (from “Switch” by Chip Heath & Dan Heath) and provides best practices and definitions of the processes to be followed (daily standup, planning, demo, retrospective, clear definition of the PO/team responsibilities). Scrum provides a practical framework that makes the mindset shift easier, as teams can rely on the framework in this “SHU” phase (“Shu-Ha=Ri see: http://alistair.cockburn.us/Shu+Ha+Ri). The clear definition of the PO role vis-a-vis the team provides the needed collaboration and WIP is limited implicitly by defining the sprint’s backlog, which I believe teams find more natural to grasp.

Small work units

Another point to consider is the need to break features into small pieces or user stories. This is a huge challenge that teams usually struggle with from day 1 in both Kanban and Scrum. This is fundamental to improving the flow in the system, thus reducing cycle time in Kanban, and creates the building blocks of the product backlog and sprint backlog in Scrum. I find that Scrum guides you more safely and clearly in this task than Kanban, as the framework and practices for creating stories are explicitly built into the Scrum process. Questions like: who is the owner of the stories? When should the stories be ready? What is a good story? Who approves the results and when? The team has built–in answers when it uses Scrum as a starting point.

The energy for change

It is also very important to consider the “energy” that the organization needs to have in order to change. Agile practically requires the organization to “reinvent” itself and, in many cases, the beginning of the process is an excellent opportunity to do just that. At that time, the right levels of energy exist, with the “buzz” created by training and management’s attention, as well as the willingness and courage to make a dramatic move. Scrum suits this “let’s make a revolution” mindset much more than Kanban, which requires stamina, patience and long term thinking. Most teams don’t have the time and patience for ongoing improvement cycles – they want results now. They are willing to risk, speculate and go along with revolutionary ideas rather than patiently wait for evolution.

Early success

Being able to achieve small wins early in the process provides a lot of “back wind” to the process. Scrum’s sweeping nature allows identifying these small wins quicker, thus injecting positive energy into the process at a much needed stage. The adoption of cross functional teams and creation of a rhythm in the organization, with demos and retrospectives quickly gives a sense of progress. It is important to pick low hanging fruits and produce results quickly.

I found that in many cases, if a momentum for revolution exists both in management and teams, Scrum’s constraints are much better for keeping the teams focused and accountable. Once you reach a point where you have a backlog with well defined stories and you are mature enough to go to the next leap, it is time to implement Kanban in order to optimize the whole and focus on the flow of value across the system, improving your cycle time from start to end.

So, should we start with Kanban or Scrum?

The only right answer is: it depends. It depends on the organization’s state, the scale of necessary changes, the desired outcomes and the problems and pains that triggered the Agile initiative.

What I attempt to do in this post is challenge the widespread myth that Kanban is always the easiest way to start. I have found that, when management is on board with the right mindset, starting with Scrum can be safer and easier. The Retrospectives in Scrum provide the evolutionary mechanism Kanban advocates that allow the organization to continue and make small incremental changes and continuously improve beneficial aspects and weed out harmful attributes

Start with Kanban or Scrum but, since you are interested in this journey, it is important to start! Begin, keeping in mind why you started and what you are trying to achieve .We don’t want to waste our time with too much upfront planning anyway, after we begin the journey, the steps we should take to move forward will unfold.

“The Road goes ever on and on

Down from the door where it began.

Now far ahead the Road has gone,

And I must follow, if I can,

Pursuing it with eager feet,

Until it joins some larger way

Where many paths and errands meet.

And whither then? I cannot say.“…

Hobbits walking song, “The Fellowship of the Rings”,J.R.R Tolkien

3 years ago in Agile Israel 2009 I talked about ScrumBan. The slideshare presentation has been one of most popular ones, and remarkably enough it is the second hit on google when searching for ScrumBan. Go figure… Anyhow from time to time people ask me where they can go look up what Scrumban is and I find myself not sure where to point them for a good brief description. I have a problem with my presentation – it is not aligned with the “Kanban Method” for evolutionary change. It is more applying Kanban together with some Scrum concepts as a mashup. This can be a great process framework for teams starting up (which I want to write about in an upcoming post), but it is NOT Scrumban.

Among-st the Kanban community ScrumBan is the name given to applying the Kanban Method for evolutionary change to a Scrum context. You start with an instance of Scrum and apply the Kanban thinking to it. In this post I will try to give a concise description of how that might look like.

Starting with Scrum

Let’s say you applied Scrum. If it works great you are able to deliver working tested software every sprint, there is sustainable pace, great collaboration, and no feeling of wasted time around the edges. Your retrospectives are about finding impediments and dealing with them, and not about estimation accuracy and commitment woes. If that is the case, I’m not sure you need ScrumBan to help you with the team capabilities. Start looking outside the team for how to improve. Consider using Lean Startup ideas to deliver more of the right things, or DevOps/ContinuousDeployment to shorten the time to market.

Most teams though are not there yet. They are having problems with their sprints. Stories leak out, Software is not necessarily working or tested, and the discussion in the Retrospective is focused on how to calculate the right velocity, what % of time to allocate to surprises, estimation inaccuracies and other such problems. If you are working in or with such a team, ScrumBan can help by giving you a change management process you can use as a guide on your improvement journey.

The basic principles of the ScrumBan Approach

ScrumBan is an application of the Kanban Method, so naturally the three basic principles apply (David J Anderson recently wrote a concise post about the Kanban Method and whether it is a framework or not, you should go read it):

1. You start with what you do now – That is your Scrum. All the ceremonies, artifacts, roles and responsibilities you are currently using. That is right, You start with everything. The Sprint, Scrum Master, Sprint Backlog, Taskboard, Sprint Burndown, whatever you are currently using.
2. You agree to pursue an evolutionary approach to change – You understand that things will change over time. You might adapt some of the aspects of Scrum. You might add new practices/policies. You might drop some. The important thing is that you agree to pursue improvement towards a process that is more effective for you, one that will help you meet your business goals more effectively.
3. You initially respect current roles, responsibilities and job titles – Again, you start with your Scrum and your organization. You don’t change the job titles. Whatever you did so far with your Scrum implementation, that is where you start. You might get some ideas for change when you read about ScrumBan and Kanban, but the Kanban Method is about considering/introducing those changes when they make sense, not as a big change up front.

Core Practices of Kanban applied to Scrumban

After understanding and adopting the basic principles, you start using the Kanban core practices. I will use David’s recent language and elaborate on what they might mean in a Scrumban context

1. Visualize – make the invisible work and its workflow visible – Some Scrum teams already visualize work and its flow. One of the keys to effective visualization of a Scrum context are making sure you see the flow of backlog items from early requirement to done. It is not enough to visualize the sprint backlog. It is important to make the flow of work into and out of the sprints visible as well, since many teams have difficulties exactly with this aspect. In addition, Scrumban is typically about visualizing the flow of Product Backlog Items (PBIs) or Stories, rather than Tasks. Tasks are created late in the game and don’t flow all the way. Some teams visualize tasks as well, but it is optional.

1. Limit WIP – implement a virtual kanban system – Once you have a Kanban board visualizing the flow, the next step is to implement a kanban system. This calls for Limiting the Work in Progress, which in Scrum context basically means you limit the amount of PBIs in progress at any point in time. Once the limit is reached, the alternative to starting a new story is to go and help others deal with their story. This can mean helping others in your expertise area or going upstream or downstream to help (e.g. Developers help Testers, Testers help Product Owner, etc.). Limiting WIP introduces pain. The pain of not being able to do what you’re comfortable with and got used to. We want to channel this pain towards ways of improving the team’s process and policies so in the future the flow will be better and the WIP Limit will be less painful. Improving engineering practices, using techniques such as ATDD, Reducing batch/PBI size, Cross-training, or any other technique can be considered as a way to make the WIP Limit more comfortable. Over time as team capabilities improve, the WIP Limit can be tightened to catalyze even more improvement in capabilities. Limiting WIP is a great way to drive real collaboration at the team level.
   Side Note: that the “Sprint Backlog” itself is a WIP Limit – it limits the amount of PBIs that can be started during the sprint unless all of them are finished. It is a shame that many teams and even coaches miss this point. In any case even if you are treating the Sprint as a WIP Limit, Using granular limits on number of stories active during the sprint will help you improve flow even further.
2. Manage Flow – with the virtual kanban system in play using WIP Limits, it is now time to run the system and manage the flow. Teams start looking at the cycle times of PBIs/Stories for information on where there is room for improvement. They monitor cycle time/aging in real time to see struggling stories and find ways to help them along. They care about the healthy flow of work (which within a sprint is not less important than whether the sprint forecast/commitment is met – but more on that elsewhere). They start using Cumulative Flow Diagrams which add information about the queues within the system to a Burnup chart.

1. Make management policies explicit – Some scrum teams make their “Team Rules” explicit. This is a similar approach. You make your process explicit. Both so empowerment can happen – people on the Scrum Team cannot be empowered if they don’t know the process. Self Organized teams cannot work if they don’t have a shared understanding of how work is done. But making the process explicit also helps improve. With the “invisible” process now made visible, healthy discussions about “why we do things this way” or “how will changing this policy affect our flow/results” become easier and happen more naturally. Remember that here we are talking about the team’s policies for how it manages itself. Some of the policies might be driven by the organization and require management approval for changes. Many of them will belong to the team and should be evaluated and experimented with actively as part of the Retrospectives.
2. Improve Collaboratively - using models and the scientific method to implement a “guided” approach to evolution. Start treating your Retrospectives as the place to design experiments. With an idea of how something might improve your capabilities, Plan what you aim to test, what will be the validation that you are on the right direction, and in the next Retrospective review the results and decide whether another round of experimentation is necessary (Pivoting) or whether you can deploy the change as a standard operating policy for the team. Use improvement frameworks such as A3 / Toyota Kata for this process. Invite in models like Reinertsen’s Principles of Product Development Flow to understand the interaction of Batches, Cadence, Heartbeat, Teams, Variability, WIP, Cycle Times, in ways you never had before.

What might happen/emerge when using ScrumBan to evolve your Scrum process

So far I just talked about the guiding principles and the practices you follow when applied to the change process. Beyond this point, any more changes to the way you work will emerge from what you discover when you visualize the flow, limit the WIP, make the management policies explicit, and start to have collaborative improvement discussions focused on hypothesis, experiments and learning what works.

You probably feel “cheated” at the moment. Is this all there is to it? Where’s the actual stuff? The changes to the sprint model? What about the roles? One way to finish this post would be to stop here and emphasize the complex nature of each team’s context and how we don’t know exactly what will emerge.

I will risk going a bit beyond that and share a couple of emerging behaviors seen in teams that go on this journey. Not all teams will see the same patterns. And don’t go using these patterns as a recipe book. Doing that might be useful, but it is a different kind of change process. I will write in the future about “Kan-Beat”, “Kan-dance”, “Kan-Bum” or whatever we decide to call the approach of starting a team with a Kanban+Scrum mashup. In the meantime you might get a few ideas for how to design a useful green-field process.

Rolling Finish/Start of Sprints

One of the first things teams realize when they start thinking about flow is that the sprint represents a “Batch Transfer” process. Many PBIs wait to go into a Sprint or get out of it, even though they are ready and could be processed without wait. In addition they realize the requirement to “clear the table” when finishing a sprint and “restart the machine” when starting again is in conflict with smooth sustainable flow. So what typically happens is that the Sprint Cadence becomes more of a heartbeat of rallying points to summarize what happened since last time, think about improvements, and do some look-ahead planning. Think about pit-stops in motor racing. The aim is to minimize the time it takes. If it could magically become one of those “Refuelling zones” in video games where stuff just magically happens to your car while you pass in the zone without even so much as a slowdown, it would be perfect. A word of caution is that some way of maintaining “Sustainable” pace should be used. “Jogging” periods each sprint are only one way to do it. Just be careful not to go into an endless stream of work. After all we are talking about human beings not machines.

Sprint Planning-Lite – Deemphasizing Estimations and Forecasts

When teams understand that limiting WIP is a great way to achieve the focus and fast cycle times, they more often than not ask themselves about whether they still need the Sprint Commitment as a way to focus themselves. Combined with the fact that people exposed to Kanban start to hear case studies and examples of teams that replaced estimations with just ensuring small enough units of work and use cycle-time based forecasting rather than deep up front estimations, they now explore what I call “Sprint Planning Lite” – a ceremony which is more looking at the big picture of upcoming work items and making sure it is a coherent picture and the items are ready, and give a general forecast what will be delivered and a specific forecast for items that are time-sensitive. Typically less time is spent on calculating accurate capacity – a big picture of main capacity changes from last sprint is enough just to have early warning of flow problems (e.g. tester is away for a few days on an Agile Testing workshop). Some teams don’t even look at each specific story in-depth deferring this discussion to the time it will be pulled into work. Some teams do a high level estimation using a lightweight team estimation game to make sure they are aligned on the story implications, and have a discussion only about specific stories. I found this style of planning is like a fresh wind to most teams, so it is well worthwhile trying.

Summary

In this post I started by saying ScrumBan isn’t a development process in and of itself. It is a process for evolving a Scrum instance to be more Lean/Flow oriented.

Then I talked about how this change process works by enumerating Kanban’s basic principles and core practices as applied to ScrumBan.

I then added some emerging properties when applying ScrumBan to Scrum. When you apply ScrumBan to Scrum you might end up with some of those or other ones.

It is now up to you, the reader. ScrumBan/Kanban/Scrum are just means to achieve an end. Start with why you need to change anything in how you do things. Visualize the invisible to have a better grasp where you are. Design experiments and validate your thinking on ideas that will improve your performance, pivot away from useless/harmful practices and drive towards what attracts the results you seek.

ScrumBan Training

If you’re interested in ScrumBan and in Atlanta for the 2012 Scrum Gathering this May, you might want to check out a Kanban/ScrumBan training I will deliver on May 10-11. Might be worth staying 2 days after the gathering …

We (AgileSparks) are also planning our 2012 training calendar. We have workshops in Israel every 1-2 months which and are also looking to run some workshops in Central/Eastern Europe based on need. Let us know if you’re interested to “unlock” your city/country…

• Jeff Anderson has been talking about the connection between Kanban and LeanStartup
• A discussion about Kanban Training Materials with Mike Burrows has nudged me to give more emphasis to the foundational principles and core practices.
• I’ve been pitching a lot of Lean Startup stuff myself to Product Owners and clients in general
• I’ve been thinking about how to use Lean Startup Change Measure Learn cycles in our approach to change at AgileSparks (and started to do small experiments at my own clients)
• I’m working on my Lean Systems and Software Conference 2012 talk/paper about Continuous Stagnation (Which will also be featured in similar form at Scrum Gathering Atlanta btw…)

The culmination of all this is that I created a Story Map to reflect the Kanban Method approach to evolutionary change. This maps the foundational principles and core practice areas to actual core and optional practices and can help me explain Kanban in our 2-day Accredited Kanban Training (next date is 20-21 march in Israel btw) . I’m also thinking of creating exercises using this map to explain story mapping itself as well as the concept of “Minimally Viable Change/Product”.

If you’re interested to check out how I use this in the context of my training – see an excerpt from the materials:

I want to quickly share a Kanban exercise I ran today in a workshop focused on this approach. The organization decided to indeed start with a Kanban system and

I won’t go into too many details, but if I see there is interest I might blog more about it, or write a chapter in the upcoming book.

The first exercise I ran today was Jesper Boeg’s HairDresser.dk Story Mapping Exercise. I followed his exercise with a discussion and short exercise for how the Story Map would translate into a Discovery/Delivery Kanban System, and how it might look like in several points along the development life cycle.

This setup the basic building blocks for creating the real kanban network of the organization.

We identified the product streams – 5 real Product streams driven by Product Management, with an additional stream covering R&D housekeeping, Research, Automation, etc.

We then split into small groups, each covering one of the streams – with the real PM of that stream as well as actual people that will probably be involved in working that stream day to day.

We then Visualized the work – at the level of Features currently in the various stages of the Stream – Backlog, Analysis, Implementation, Ready to be Released, etc.

Now it becomes interesting. Each Feature in a stream might require work from several different technological teams (4-5 of them). We gave a color to each technology team/stream and each group marked each Feature with the technology streams that were involved. We played with various expand/collapse patterns when trying to visualize the flow of these technology aspects of the Features, and discussed whether that visibility was required for a Product Stream interest level or not.

Then we took a step back, and went Small Batches. We took a couple of Features and sliced them to Minimally Marketable Features and then User Stories. Since we still have technology teams we still had to slice the stories to technological aspects, but at a much smaller batch size which will provide much faster/earlier integration/testing and faster cycle times. All of this still without going Feature Teams. The value of Flow/Pull without Iterations in this model is clear – there is no unnecessary wait between the time a Team finishes its “Team Story” until Integration can happen or Testing can pull.

We then visualized the Technological Team Stories and had another discussion about visualization patterns.

Next step was zooming into Technology Team Boards. It was simply a matter of collecting all the colored cards from the different Product Stream boards and representing them on a single Team Board for each Technology Stream. We are not even sure those Boards will be used at the team level up front. We might start with a Kanban system used by the people involved at the work management (PMs, R&D Managers/Leaders) to learn the ropes of the system and then extend its usage.

We also discussed priorities between Product Streams and the R&D internal streams. The understanding that allocating WIP to each stream and creating a Weighted-Fair-Queuing system based on that was very important. Senior managers in the room felt that this would make it much easier  to meet the portfolio allocations the organization decided on. By default when work for a stream is finished it would mean pulling a new card from that stream.  But there is still the flexibility to deal with struggling items by optimizing globally across Product Streams.

Another board level is the “Big Picture” board where the MMFs from each of the Product Stream boards will be represented.

The exercise brought to life the complexity of the organization’s network but highlighted how a Kanban system can simplify its operation as well as drive towards improvement. There were several A-Ha moments of understanding how Limited WIP would solve systemic problems currently haunting the organization.

It also highlighted how creating Feature Teams allocated to a Product Stream would make life easier from a coordination perspective. This gives the organization incentive to try some form of Feature Team approach when the time is right.

The fact that we exercised all this using real work of the organization, real teams, discussed real problems of starvation, one technology team being the bottleneck, how overall WIP limits might affect that, etc. was a great way to understand what an organization-wide Kanban system is all about.

I loved this exercise so much I’m thinking about creating a “sterile” version  for advanced public product management / kanban workshops…

Artem’s collection of Scrum Backlog templates

Henrik’s Index Card Generator

Hakan’s Excel-based CFD

MSDN User Education CFD Example

If you have other favorite templates, please let me know so I can update this list.

I have an early new year resolution. It is to get some more value from books I’ve been reading. I have this habit of enjoying a book, getting to DONE (Finishing it…) but not getting to DONE DONE (Generating explicit takeaways that might affect the way I do things out of it). I decided to post book reports for some of the books I’m reading here on the blog. These reports will emphasize takeaways and suggestions I’m taking away with me that I think would be interesting to the blog readers as well. Let’s see whether this resolution will stick…

I’ll start with one of the recent books I finished. It is the first book by Reinertsen – Developing Product in Half the Time. This is a book from 1997 so it predates most of recent work on Agile and Lean product development. But as I tweeted while reading, it is quite timeless.

I find it especially useful for those in multi-disciplinary environments mixing Hardware and Software that are finding it hard to digest the more software-focused Agile concepts and frameworks. The principles and practices suggested here apply to Product Development in general. If you’re already familiar with Agile, Scrum, Kanban, you will find this book brings home some of the thinking of why the practices we use work.

My main takeaways from the book

“The true measure of the value of a model is whether it actually influences behavior. If people do not understand a model, they are less likely to let it influence their behavior” 

This applies to models like a Kanban system. The more you involve people in the design of the system, or even better give them some guidance but let them design their own system, the more the system will influence behaviour, and the more sticky it will be. The challenge is when you talk about an enterprise where multiple groups each have their system. How do you balance the desire for self-design with the desire for reuse and common language? It’s a tricky area, but I believe a mix of shared living/evolving model/language which is extended by each group for their own needs is probably a good way forward. If we can take great ideas from evolving group models to evolve the shared model, or create a catalog of good design bits that can be used to build new models, it is even better. In the kanban community we keep hearing success stories where teams design their own system. I need to make sure that this happens by design in organizations I’m helping. Just this week in a workshop with Project Managers from an enterprise implementation we had a discussion about this. We agreed that the shared model should be minimal and oriented towards the vision of flow. Any specific modeling that is necessary to deal with workarounds until that vision is achieved will be done locally.

Cost of Delay

Those familiar with Reinertsen’s later work will know he is quite a Cost of Delay aficionado, well actually the thought leader on the topic I would say. I’ve heard some remarks about how this is all hand waving and where can we see how all of these calculations are actually done. Well the search is over, the answer is – HERE. The chapters discussing the sensitivity models and how to integrate them to the product development lifecycle are great. I haven’t had the chance to use this, but I know where to go for reference when that time comes.

Communicating what the product will not do

One of the ways to improve clarity in early phases of the product/feature development and reduce surprises later on, is to be very explicit about what is NOT included in the specification. This might drive tough discussions, maybe even tough decisions about viability of the product/feature without those missing capabilities, but better be aware of them now.

Consider having a section of features in the release/product backlog that you clearly mark as “Will not be delivered”. Maybe add a section of “Will not even be easily feasible with the architecture choices we’re making”.

When extracting a minimal feature / business value increment, try to be clear about the other business value increments that are in this area, so it is very visible what is NOT part of the minimal feature. Talk about what stories are NOT included as well as what stories ARE included.

Forming and Energizing Teams

This is a sublime chapter in general. Hard to decide what to emphasize. In general, I find Reinertsen’s approach to teams and management helps me have more effective discussions with real world managers and executives about effective organizational structures.

Specifically, the Project Team Leader is a role emphasized in Lean Product Development, while being quite vague in Agile/Scrum. The Project Team Leader is more like the Toyota Chief Engineer (Shusa) than a typical Product Owner (or even Chief Product Owner). The Team Leader here really sounds like he’s the “CEO of the product”, while the Product Owner is not really in charge of execution. I need to think how to balance these two approaches. BTW the Team Leader according to Reinertsen and Smith can come from Engineering, Marketing or other departments. The important thing is his ability to successfully lead the Project.

Next comes the team. One can find strong hints of Flow and Limited WIP here… The warning against fragmented teams with partial allocation of people to them, The fact that full-time team members have nowhere to hide and have higher connection to the project purpose, the dangers of over-specialization and how to deal with them. And also a discussion of motivation that gets to the core points popularized these days by Daniel Pink’s Drive.

Project Loading Rule

The project loading rule is something I’ve been using with clients even before reading the book – “The standard way of staffing projects is to simply take the projects that “must” be done and divide the people among them. Instead, we suggest that you rank order your projects. Then take your most important project and assign as many people to it as it can effectively engage. Next, do the same with the second project, excluding people already assigned. Continue until all people are assigned. Any remaining projects, even “must” do, do not get started until a project completes, freeing some resources”. 

I love this rule. But I want to add some more guidance on top of it. First, you want to challenge the current paradigm of how many people a project can “effectively engage”. I recommend trying to add more and more people beyond the prevailing norm of “effectively engaged”. Then discuss what will be the systemic impediments that will reduce the effectiveness, and whether the organization wants to deal with them now, or add them to an impediment backlog, and limit the number of assigned people for now. This is a great way to set a vision for better projects flow and also have the impediments/roadblocks you’ll need to remove along the way.

Another question that might come up is what if the remaining people after a few projects have been chosen are not enough to effectively start a new project? Should we start it anyhow? Should we add those people to the previous projects even though it is less than ideal engagement? Should we skip to a smaller project? Should we work on some impediments in the meantime? Should we keep them as slack? No best practice here, just some possible ideas. Have a discussion about it is my main recommendation…

Three essential things an Executive must do

Calculate the cost of delay and foster its use in making project decisions

Religiously control the start-up of new projects

Enable development teams to run themselves

Change Management

Attitude will follow Behavior. Therefore we need to focus on changing behaviors, organizational culture will follow. I’ve had quite an allergy to discussing organizational culture and telling organizations they need to shift their culture. So naturally the behavior first approach resonates with me. One of the challenges with a team-based agile pilot is that it doesn’t need enough day to day behaviour adjustments from the wider organization, so there is little chance for attitude to change. So when infrequently there is a need for the organization to behave in a more lean/agile way, it is not natural and not sticky. One of the approaches I’m experimenting with is to use Kanban at higher levels while running focused pilots with some of the teams. Following the Kanban Method will require a leaner more flow-oriented behavior on a day to day basis, which will start shifting the organizational attitude slowly but surely.

Assymetrical investment in the pilot. If you are going for a pilot, make sure you invest assymetrically in it. You need a strong enough dose of the lean/agile virus in order to overcome the organization’s immunization effect. If you do fail, next attempts will be harder and harder as the organization immunizes itself to this kind of change. This is one reason by the way that the Kanban Method makes a lot of sense in organizations with failed change initiatives. It is a different kind of change, and can fly in under the radar of the immunization system.

Enabling the team to move quickly 

One final quote that really resonated with me is about the shifting role of management, from a vice president at Xerox: ”Management’s job is more that of a police escort than of a traffic cop”. This is a quote I intend to repeat when talking to managers, Project Managers, PMOs and the like.

Photo Credit: http://www.flickr.com/photos/kenjonbro/6261238739

Conclusion

This short list of takeaways/highlights really doesn’t represent the breadth of information and examples in the book. I highly recommend anyone interested in Lean Product Development, especially in complex environments involving more than a few software teams, read this front to back.

Let me know if you found this useful, it might give me energies to do book reports more frequently…

This has got me thinking about Israel. Our national and corporate culture is said to in general be quite similar to America. I found this “Doing Business in Israel” article from CommunicAid which enumerates Individualism, Directness, Impatience and Polychronic as Key Concepts and Values. In general, this seems discouraging for alignment with Agile approaches – which encourage collaboration and collective ownership over individualism, focusing and finishing things over the multi-tasking hinted by PolyChronic. At least PolyChronic also means we are easy on the trigger of re-prioritizing, which explains why business agility is quite valuable to us…

Last but not least, we are impatient. And while there is nothing in general agile thinking that contradicts that, once you go to Lean, Continuous Improvement, and using something like the Kanban Method where you need to Agree to pursue incremental, evolutionary change, it becomes a bit more difficult. My experience in the field seems to align with the lack of patience for Continuous Improvement. Most Managers and Executives I see like the Agile concept a lot, think that delivering iteratively is a good idea, but the Continuous Improvement bit gets less traction, no matter how much we try. There are of course exceptions and bright spots shining through, but I cannot ignore the overall trend.

This explains why Kanban as a system is getting lots of interest and adoption in Israel, but not necessarily the evolutionary aspects of the Kanban Method. Disclaimer – my perspective is quite subjective, and related to the kinds of clients that approach AgileSparks. I’m interested in what other practitioners and consultants in Israel think.

With this starting point, you would expect head-strong revolutionary agile implementations. And we are seeing many of those. But the Impatience and PolyChronic traits also lead to losing interest and pace even while doing the revolution. Our attention span is short, and after the initial excitement, we often see organizations not focused on the change long enough to recover from a deep change and addressing all of it’s repercussions. It’s also quite typical to see organizations signing on for the revolution, but even when starting, they start making amends to the reality of the revolution being too much for them. We see feature teams which are not really feature teams. Doing agile, but continuing to work on many many projects because deciding to freeze some of them is a hard decision. Impediments actually requiring some tangible investment or management staff spending time agreeing on something and changing policies, linger.

What I started to think about was a way to learn faster what is the real change pace that the organization can sustain, before diving too deep into the j-curve. Maybe by front-loading tough decisions and seeing if they are made. Maybe by simulating real life scenarios in more depth and making the reality they will face later into the change more tangible for leaders. Maybe by starting with the tough aspects of limiting the work in progress and pull mode at the management level, before going to the teams level. If all of this doesn’t phase the organization and it’s management staff, then they have the right attitude and timing for a revolution. If they get cold feet, a more evolutionary approach can be adopted.

I’m thinking though that there isn’t much value in positioning the approach as evolutionary, at least not to those organizations. If they want an Agile Revolution, we will give them an Agile Revolution, maybe doing it in an evolutionary way.

There are other organizations which ARE dis-enchanted by revolutions, are mature enough to look for methods that are based on evolutionary continuous improvement. They might start with continuous improvement, but sometimes will consider a Revolution of sorts at some point.

I think we should develop more and more ways to recognize what is the best fit for the organization, ideally give the organization the system that helps it understand their own ability to pull change at a sustainable pace. This relates to my short Pecha Kucha talk from LKCE11 about Implementation/Policy Kanbans.

Change Program Stall Avoidance 101 & Policies Kanban

I will continue to think about this topic. Lucky for me I’m seeing many examples of Israeli corporate culture in action, so will have a chance to examine this theory. Help me out by sharing your experience from Israeli or other impatient cultures!

Energizing a kanban system has been an area I’ve been thinking of lately ( see my lkbe11 talk). One of the key areas of focus is how to expedite handling of exceptions to flow. What are those exceptions? Blocked items as well as “struggling” items that are not making the progress you expected. Identifying what is struggling is a non-trivial task especially in the face of variability, some of it inherent to knowledge discovery processes and unavoidable. I blogged some of my thoughts about this some time ago, and a collection of possible techniques is also available in the  lkbe11 talk mentioned above. Assuming we have some sort of way to classify work as “is currently a flow exception” we want to leverage this.

Exception Handling – Maybe what the doctor ordered?

Last week I was having a discussion with a team lead about the fact she thinks the team is not focused enough on dealing with exceptions, causing the exceptions to be the norm, the velocity/throughout to go down creating an overall feeling of sluggishness.   It is also hard to convince this team to use a physical board. They claim they have the data in an issue tracker. So an idea that came up is to maintain an exception-focused physical board, showing just the items that are blocked or struggling. This will the team to start looking at cycle times, and do some kind of TOC buffer management where after the mean cycle time passed, an item goes on the board. We think that visualizing these exceptions as well as having the daily meeting focused JUST on them will help the team, and even more important focus them on process and artifacts that can help them. This might create a chain effect of them continuing to fine tune their process and interactions to help them. I will report about the results of this experiment… BTW This reminds me of something I heard at LKCE11, I think it was Jim benson talking about TLC (The Library Company) – where they visualized the longest living items as a big visible chart, and within minutes the longest living items disappeared from the list. It is just a matter of what you look at…

Conclusion

As teams venture deeper and deeper into flow land, exception handling in realtime might turn out to be an effective way to improve cycle times, flow, and drive improvement at the team level. Teams should consider explicit policies for how they will handle exceptions to flow – will they swarm? slice more thinly? increase frequency of standup meetings? pull a specialist in and pair program with him? Even the discussion of flow exceptions and the need to do something about them would probably be an improvement in and of its own. I’m looking forward to the ability of more and more electronic issue tracking / kanban tools to provide ability to focus on flow exceptions like the ones mentioned above. Several tool vendors already have some capabilities. Leankit Kanban visualizes due dates in danger and has a filtered view that can probably be modified to see exceptions. Silver Stripe provides custom alerts. Another vendor has already shown me an alpha which is in the right direction. PS If you are a vendor with such a capability, feel free to comment and point to what you have… In general, I’m hoping tools will focus more and more on flow/time rather than velocity/throughput. It is a much more interesting and actionable perspective of the work…

When I looked at the program for Lean Kanban Benelux 2011 I found a couple of sessions talking about something I wasn’t familiar with – RightShifting. Since I had to speak at the same time, I didn’t have a chance to go check it out. Come Lean Kanban Central Europe 2011 I saw another session on RightShifting, again a conflict – this time with my Pecha Kucha talk. But I was curious enough to try and check it out, have a chat with Bob Marshall and think about it for a bit.

Yesterday, at home already,  a couple of thoughts clicked.

One of them was that my post about Lean/Kanban Team Modes might fit into the RightShifting model. I won’t go into what it is, if you’re interested go see the movie from Lean Kanban Benelux 2011:

Bob Marshall – Grant Rule – Understanding Effectiveness: Rightshifting and the Marshall Model from AGILEMinds on Vimeo.

Now, assuming you have some idea about RightShifting, here’s my thinking…

Team modes and RightShifting

Well, thinking about the ad-hoc phase I have in mind a start-up / small group where everyone is one big happy family, without any rules, hacking it out. No teams there for now.

At the dawn of the analytical phase, the group is too large, seems like we must introduce some discipline. Part of it is creating functional teams, and discussing the interfaces between the functions, roles and responsibilities, RACI, etc. This is the starting point for my previous post, and what I see in most organizations I start working with.

The synergistic phase seems to align pretty well with initiative/project teams and maybe work cell teams at it’s border with the Chaordic phase. These teams are more synergistic based on their cross-functionality and focus on business value purpose. Work-cell teams are more flexible, which is why I think they are a bit right-shifted from initiative/project/product teams. One interesting point is that some organizations wishing to go to “Agile”/”Scrum”/”Kanban” don’t always understand that this will pull them right dragging along the cultural mindset… They want this agile thing as a plug-in to their analytic mindset… That is always lots of fun to deal with

Where do we go from work-cell synergistic teams? Well, I think the return to on-demand teams, this time within a bigger group that already has wide any to any communication bandwidth so strong dynamic teams can be setup and tear down with minimal coordination cost, might be a good fit for a chaordic mindset. I have a few organizations on the verge of this transition, maybe exploring the framework with them will help formulating a vision / rationale for what is going on.

Disclaimer

I’m no RightShifting expert. Far from it. Just some thoughts I’m putting out there, with the hope they will enrich the conversation, and maybe interest a couple of my readers in RightShifting.

I recently had the opportunity to talk with a couple of HR managers who were interested in how agile can help the HR department become more effective. This was a context where the product development is well into their agile journey, and we are talking about a group of about 20-30 people providing HR services like recruiting, training, social events to an enterprise R&D organization in the 1000 people range.

What does agile mean for HR

Well, I tend to view HR as a service driven operation. There is demand of various types coming in. The HR turns this demand into a service that the organization consumes/uses. A classic example is recruiting. Demand is the hiring manager with the new open position. The recruiting department helps fulfill this demand, and the end result should be position fulfilled.

So the First thing we did in the session was explain how lean/agile aims to maximize effectiveness delivering value leveraging the following understandings:

• Most HR Activities are knowledge work with high variability and learning. We are not sure about a candidate so we want to maximize early feedback. We want to understand whether a training we got a request for will REALLY be interesting to the people to the level they will sign and allocate their budget to it, to avoid spending precious energy on things that get thrown away / changed later.
• HR groups have a certain capacity. When overloaded performance actually goes down, same like motorways, computers, or development groups. So we should try to use a system that lets the group limit multi-tasking to healthy levels.
• Activities that are only half done are very dangerous. We call that inventory / work in progress, and the more of those we have, the harder it is to operate. It is harder to focus, context switches cost more.
• There is a lot variability in the demand as well as the work required to deliver services. During ramp up times recruiting for example is overburdened. Versatility within the HR department is valuable to assist in dealing with this variability.

Kanban

With this context in mind, I outlined Kanban as a Method to drive for improvement in this context. What does this mean?
Kanban starts with the processes you currently have. You agree to pursue evolutionary improvement, and to respect current state but be open to change it.

What you actually do is take the following steps:

Visualize the Work

Visualize the process/workflow of fulfilling the demand. For example if we continue with the recruitment example – raise need for position -> create position description -> publish > filter candidates > best and final between a few top candidates > prepare offer > send offer > signed offer > prep for onboarding > onboard > 3 month – successful hire. With this workflow we draw a kanban board. I recommend starting with a simple board with a few steps – see below…

Now we populate the board with the current work, in each of the phases. A card represents a piece of work that when Done will mean fulfilled service ( eg one open position)

We can use different indications to show different kinds of work, work states such as blocked, who is currently working on what and more. The idea is to visualize as much of the state of work as possible. Ideally in a big physical board visible in the workspace of everyone or in frequently visited public space. This creates transparency that will in and of itself spark interesting discussions, raise problems to the surface and start creating a list of problems we need to handle ( which is good… )

We want people to use this board in their day to day activities. The board should be the main tool used to track work and synchronize. Lots of teams use daily sync meetings in front of the board.

Limit the work in process

Next step is to recognize that there are limits to capability, and work should be governed by capacity. What we actually do is assign limits to numbers of cards/items in process. The most common way is to say “no more than 3 cards in this board lane” or “no more than 3 positions we are currently writing descriptions for”. This creates a pull system, because it means that once that limit is reached, no new work can be pulled in, until some work has been pulled by the downstream process. This has the effect of “We’re all in this together, concerned about delivering value, rather than just doing our job”. Very quickly some slack will be created by the pull system. The magic is to divert this slack to help the work flow right now, but more importantly find ways to improve the capacity of the bottleneck that caused the flow to stop.

An example is probably in order. If it seems like many positions are in “sign” it might be interesting to use slack time to help create better templates or easier access to salary tables to reduce the effort it takes to prepare offers. If it also seems like a lot of offers are rejected since the candidate is not really serious, it might make sense to find a cheaper way to verify seriousness before spending the effort to prepare an offer. What you actually do will be context specific of course. The Kanban Method WIP Limit will just waive the flow problems in front of your face and beg you to deal with them, more intensively than before.

Manage the Flow

Start caring about the flow, the time it takes from start to finish, from request/demand to finish. Care about the mean time, the promises you can start making, the corner cases and what they mean and how you can improve by learning from them. For example if a typical position is handled start to finish in 4 weeks, and you see a position took 1 week, look at it and try to think what makes it a “Bright Spot”? Was the job description crisp and sexy? Was the hiring manager devoted to making it happen? Was the recruiter using some new sourcing technique? Same for the opposite case – what went wrong with that position that took 8 weeks?

Make your process policies explicit

This is a very interesting step. On the surface, this is very mechanistic. Seems like “Document your process”, what’s new here? And what’s Agile about it?

First, just to make sure we understand, these policies are the rules of the game. Things like the WIP Limit, the conditions for cards being done in a certain phase and ready for the next one, the policies for expediting work if necessary.

Explicit policies enable empowerment. They improve the level of coherency of the system among all people working on it. They can safely make local decisions that are aligned with the rules of the game.

Beyond that, Explicit Policies are not static. They should evolve based on new understanding and learning. You should experiment with them to see what works. The policies will be painful. You will sometimes feel you are hitting a wall. That they are creating constraints for you. That is good. Constraints drive creativity. And if the policies are constraining you in a way that’s driving you towards better and better flow, that’s great. It means the pain is part of the gain. The discussions you will have about what to do to make the policy work for you, will drive the improvement action items. Sometimes you will relax policies that went too far too early. Sometimes you will tighten things up to drive for more improvement. This is one of the key practical ways Kanban drives learning and Continuous Improvement – Oh that holy grail…

Improve Collaboratively using Models

Finally, with the system in place, after you start using it, there will be opportunities to use models that apply for Flow systems. I will not go into this. Suffice it to say that although the Kanban system might seem simple, there are a lot of ways to look at a system and improve it. If you’re interested in this area, I can refer you to more material on the subject.

This is it

Yes, might seem simple at first, if you’re looking for the revolution it is not here. On purpose. Kanban is an evolutionary method. It aims to provide an alternative to classic shock and awe change programs that many organizations had bad experience with. With Kanban you change at the pace that works for you. You can accelerate pace of change as you become more proficient in identifying the problems and experimenting with solutions.

What did the friendly HR managers think? Well, they liked this method, found it very applicable to various processes in the HR department, and can’t wait to start. We are meeting in a couple of days again to play some Kanban games and setup their boards. I will report when there is more to tell…

Note that nothing here is very specific to HR of course. This simple approach can be used to introduce change in many knowledge-oriented services. Many Kanban practitioners are reporting Kanban boards popping up in other departments when the IT group starts using it. It’s quite viral…

To be continued…

My main points were:

• Classes of service do apply when developing products.
• Classes of service don’t cover cases when you need to give different Treatment to different kinds of work, so I introduce Classes of Treatment for context-specific policies for “how to do the work” not just “when to pull what”
• Kanban doesn’t prescribe teams, but what kind of team formation / organizational structure works best? Explored several options and their attributes and effect on Flexibility, Resiliency, Performance.
• Kanban principles and practices scale, in a fractal way. You can zoom in and out as you wish.
• The higher you go, the tougher it is to feel a day to day flow, which is the main challenge of Kanban at higher levels IMHO.

PS If you were at the talk, I’d love your feedback!

If there’s one thing that makes me mad whenever I see it is teams abusing the commitment concept in scrum. I’ve been on a rampage against dysfunctional sprint commitments for a while now, but lately my thoughts have crystalized a bit, especially when I had a chance to discuss this with Jim benson, Alan Shalloway, Chris Hefley and Jon Terry last week at Lean Kanban Benelux 2011.

Background

So what is the problem? Well quite often you see scrum teams that finish sprints out of breath, out of quality, out of joy. You also teams that start the sprint full of numbing fear, set a low bar and that low bar becomes a self-fulfilling prophecy. Add to that Product Owners, Scrum Masters and managers all spending precious time worrying about whether we are able to make accurate sprint commitment, instead of working to improve the actual capability of the team.

It’s quite sad actually. Surely that’s not what scrum should look like and indeed other teams have energized focused sprints where they deliver what they can, stretch their abilities just the right amount and finish a sprint with just the right energy and mindset to joyfully go into the next one.

So what’s causing this?

Well, let’s start with the out of breath teams. It typically starts with unrealistic commitments they make in the sprint planning. They make those commitments either because they’re pushed to do it explicitly or implicitly. Yes, scrum says the team should pull according to their capability. But something about the way this all works de-emphasizes actual capability of the team and motivates them to try to take on more than they can handle.
With this in play, they start and since there is a lot in their sprint backlog they have the green light to start many things in parallel. A few days later, in the last mile of the sprint, it’s still many items in progress and it’s either an unsustainable effort to reach the finish line, cutting corners or having a very disappointing sprint result. In our #LKBE11 discussion we referred to those as mini-death-marches…

With teams living in fear it is a different but related story. It starts with the message/spirit conveyed to them by their Product Owner, managers or previous life management culture. When they hear commitment they hear “miss that and you’re in trouble”. And if the ecosystem is such that meeting the sprint commitment is more important than the overarching purpose of the project/release/feature they will be driven to satisfy what they perceive as important – being predictable at the sprint level. So they make a safe commitment. Usually this is achieved by taking safety in the estimates. And so starts a self-fulfilling prophecy, as described by Parkinson’s law and Donald Reinertsen’s principle of the expanding work.

It doesn’t help that the team thinks that if they are able to deliver more, there is no turning back – from that point on they will be asked to deliver more on a consistent basis.

Lets pause here for a second – Isn’t it a reasonable expectation? Shouldn’t the team commit and deliver more in the future if they’re able to? The problem is that even during a short 1-4 weeks sprint, there’s still a lot of unavoidable uncertainty and variability. In exactly what we need to accomplish (requirement space), in how to do it (problem space) and also in how much time will we have for it (capacity). A lot of teams try to eliminate this variability and spend a lot of effort on it. Planning meetings grow longer, people’s capacity is planned at the micro-level…

Many teams will oscillate between over-commitment and under-commitment exactly because of this variability of course. They and their management will be frustrated if they’re measure for effectiveness is meeting the commitment. The only way to consistently meet a commitment is either unsustainable pace, or making a really safe commitment.

Lets eliminate commitment

Well, just as an exercise for now, to see why it’s there in the first place…

Without a sprint commitment, how will the sprint look like? Probably we will see people taking on work from all over the place. They will start at the top priority, but their nature will lead them to start many other backlog items since there is no focusing force urging them to stop starting and start finishing. So we need commitment, or something else, to encourage a team to focus on a few things and finish them first. An alternative to commitment at the stories level is to say we are focusing on a single feature so let’s finish it before moving on to anything else.

Commitment as a Focusing mechanism

Wait – this is the Scrum Sprint Goal – Teams are supposed to agree on a Sprint Goal they will focus on. The detailed story level commitment is an elaboration on that anyhow. If our product backlog is very fragmented and not feature oriented we will have a tough time using an effective sprint goal though. This is something to wonder about in and of itself… but if it’s indeed the business reality that we are doing many small things, we need another focusing guidance. That guidance can be “we think we can finish at least 8 stories, hopefully 4 more, so lets start with 8, get a good feeling we can finish them, and ONLY THEN move on to the 4 others”. Here, the team is still using the sprint commitment, but they’re using it for themselves as a focusing / work in process limiting mechanism.

Containers

Another problem we might have without commitment is that the work will expand uncontrollably. There is no finish line so there is no container. One thing that might help is very energizing purpose of where we need to get at the end of the Feature/Project/Release and why it needs to be at a certain point in time. Seeing our progress towards that goal (or lack of progress…) will help energize our efforts and reduce the expansion of work.

Commit to Capabilities Improvement

Another thing that might help is to start looking at our capability as a team and make a commitment not to exactly what we deliver but in general to improve our capabilities. The capability we care about is velocity as well as ability to turn out the top priority items in the backlog as soon as possible since they are the highest priority. So let’s monitor our capabilities over time and try to make them more predictable first and improve them as a next step. Specifically, measuring Velocity can be done without making any sprint commitment. Just track the velocity for each sprint, preferably on a control chart so you can start to understand the variability in your capabilities.

How can we make promises without commitment?

This is a point I love. On one hand Agile diehards say there is no commitment in agile – “we will just work sprint to sprint and avoid any clear external commitment the business can count on”. On the other hand if you start a discussion about losing the sprint commitment they and others start talking about “how can it even work without the team making a clear commitment and sticking to it?”. Bottom line, the sprint commitment doesn’t help you one bit in making external commitments and meeting them. It’s simply orthogonal to it. You make external commitments based on size estimations and historical/estimated capabilities. You meet external commitments by monitoring where you are towards them and adjusting scope, resources, pace sprint by sprint. If you use the sprint commitment as you should, it gives you nothing towards that goal. Accuracy in sprint commitments is micro-predictability. The business cares about mezzo/macro predictability. Same like a long-term stock investor doesn’t care about the fluctuations within a day or a week, they care about the stock performance over a quarter or a year. The team should care about reducing variability in its capabilities eg. have a lower variability in Velocity, so more aggressive mezzo/macro commitments can be taken on while still allowing safe and sustainable delivery.

How can other teams count on us if we don’t have a clear commitment for the sprint content?

What if we are in an environment where other teams in the group/portfolio count on deliveries from us on a sprint by sprint basis? If we don’t have any commitment how will they know when to expect the delivery from us? If they intend to work in parallel to us, how will they know whether to plan for this or not?

There are a couple of ways to look at this. If 80% of the work is consumed by other teams then we should probably consider the organizational design. Maybe it would be better to work as a single team. Maybe it is a case of us providing a service that is consumed by many other teams, and then it might be better to move towards a pull system – where there is less reliance on dates and rather an agreement on priority, an understanding of the capability in the form of typical lead time from requesting a service from us to the time we deliver it, and then the consumers using that service whenever it is ready, either at their next sprint, or even better as soon as its ready. If you’re thinking this will make planning sprints more complicated and prone to changes you are right. The solution can be to move to full pull mode at the team level, or reduce the batch size you plan for, meaning shorten the sprint length.

If it’s just sporadic work that others depend on, make sure that is what you start with and make a commitment to deliver it. I wouldn’t be surprised if the term Class of Service comes to mind at this point…

What will be the engine of continuous improvement if we don’t have a target commitment to strive for?

Scrum is about Continuous Improvement, right? What drives this? Isn’t it the need to meet commitments? to be better about commitments?

Well, not exactly. The thing that is driving Continuous Improvement is the fact that there is a container, composed of a certain scope to focus on, a certain time to do it in, and the people/capacity to do it with. Think of circling the team with a rope telling them now move together towards the target. This will cause a lot of pain. Some people are faster, others are slowing the team down. Some impediments come up and cause problems. But the rope keeping the team together is forcing them to deal with the problems rather than defer them by making progress on things outside the container just to maintain the comfortable feeling of progress.

So in order to maintain this improvement-inducing container we need the time, the team, and a certain scope to focus on. We can do that with the Sprint Forecast mentioned before.

One important concept in Continuous Improvement is to have a vision / target condition to strive for. What is that target condition in a Scrum environment? As mentioned above, this typically is to improve capabilities.

Improving throughput/velocity requires more scope in each container.

How do we translate improving business agility to the container? The ability to define a shorter time frame that the team can still deliver in. The shorter the time frame the more opportunities to change direction without causing waste. Problem is that there is a limit to this. Work takes time, and there’s a limit to how small we can slice it to still be able to use a container of this structure. That is why, at some level, in order to improve business agility even further, we need to move to another form of container, one which limits the amount of things we are working on as a team at each point in time.

(Clarifying note – If you’re reading this to mean get to a certain level with Scrum then move to Kanban, that’s not what I mean. You indeed will benefit from Kanban at this level, but you can start your journey with Kanban in the first place, or move to it regardless of where you are on the way)

So can we get rid of the Sprint Commitment or not?

Well, my personal opinion is that we can live without a Sprint Commitment as currently practiced by the majority of Scrum Teams out there. It seems the creators of Scrum think along similar lines, as they replaced Sprint Commitment with Sprint Forecast in the latest Scrum Guide…

I personally think commitment is important, it’s only a question what you commit to. I prefer to focus on the following types of commitments:

• Commit to learn about your capabilities, care about them and continuously improve them, by using a focusing mechanism challenging the team as a whole.
• Commit to deliver the class of service that the business and other teams expect, which means delivering on time when it matters, delivering the most throughput when it matters more, etc.

Some more ideas to try at home…

Before we conclude this long post – Some related experiments you might want to try at home…

• If you feel you are over stretching, For a few sprints try setting a very low forecast and meeting it and see how it looks like. Talk about it. Learn from it.
• Try limiting the amount of Features/Goals in one sprint. Talk about what it changes in the energies and focus of the team. If you cannot set a limit, that’s an interesting discussion in and of its own, that you should have.
• Use the Sprint Goal and Sprint Stretch more aggressively. Set a lower goal, and commit to deliver the goal first, and as much of the stretch as possible. Goal should be something you can consistently deliver 95% of the time. (Mike Cohn recommends basing that goal on the mean of the 3 worst sprints out of last 8, another way is to use 2 standard deviations below the mean if you want to take a more statistics oriented approach). whether 95%, 85% or lower is your call. But the expectation should be that if there is a difficulty meeting even this commitment, it’s not forbidden to pick up the pace a bit in order to meet a commitment. Learn from it at the end of the sprint and plan more effectively next time.
• Read about the XP Planning Game and try it… Seems the idea that iterations can be effective without a commitment is not a new one

Extra Reading

• http://damonpoole.blogspot.com/2011/08/scrum-no-commitment-required.html
• http://agilepartnership.com/blogit/2011/07/26/is-commitment-dead/
• http://www.coderanch.com/t/130421/Agile/Scrum-vs-XP-Planning-Game
• http://www.projectsatwork.com/blog/Dave-Prior/3740/
• http://jamesshore.com/Agile-Book/the_planning_game.html

Conclusion

Scrum has some good things going for it. The Scrum-style Planning Game and Sprint Commitment as currently understood and practiced by most teams and organizations is not one of them. I hope this post will help at least some of those improve their results as well as their happiness.

I recently had a short twitter chat with Catherine Swetel and Steven Holt about the relation between TOC Critical Chain and Kanban. This post will try to sum up my thoughts in a way that is a little bit more persistent, as well as add a bit more color and depth that is not possible in 140 characters. To start with, lets just make clear – I’m no expert at TOC or Critical Chain. I’ve done my share of reading over the years and have seen organizations using CC and helped them explore the Agile/Kanban world. I’ve read Critical Chain for the first time back in 1996 or so and also familiarized myself with the MPCC S&T tree in the last couple of years. With that disclaimer, here are my thoughts, for what they’re worth:

Multi-Project / Program Level

If you start at the project/portfolio level, I see the Multi-Project Critical-Chain and especially its Strategy and Tactics tree as very similar to the Kanban System for driving improvement. Both approaches start with Limiting Work in Progress at the Projects level as key to reducing unhealthy multi-tasking and improving predictability and effectiveness. With time, excess capacity can be used to shape demand and create new exciting business models. I think the CC world is more advanced in its view on this aspect, but the Kanban world is certainly going there. We would be wise to learn from Viable Vision and other great thinking in the TOC world.

The Feature Design Factory

Once inside a project, kanban advocates a feature driven approach to development. The understanding that product development is a knowledge discovery process where units of inventory start as options and end up being working tested validated features is at the core of the Agile approach. The assumption is that we are operating in an uncertain environment. Both the requirements/problem as well as the technology/solution has considerable elements of uncertainty. We welcome this uncertainty as it comes together with the opportunity for great returns. We also recognize that Integration activities hide a lot of the risk in our projects, and so we drive for early and continuous integration to minimize that risk.

The way to operate effectively in this environment is to have a continuous process of focusing on a few features, seeking feedback along the development process all the way to customer/field feedback, orienting ourselves based on it iterating thru the same or earlier stage of the process depending on the feedback, and at the end having a marketable/viable feature that doesn’t hid any more work behind it. Only then do we pull another option/feature and drive it thru the process.
Kanban realizes that we have a certain capacity of features we can effectively process at any point in time. Overburdening this capacity will mean the knowledge discovery for each feature will take longer and the feedback will be handled later at a higher cost. I’m guessing this will resonate with any TOC practitioner. And indeed, the realization that features can be handled as inventory opens the door to applying a lot of the pure TOC thinking.

This approach can be used for handling an ongoing product development context where there is always plenty of options that can provide business value, and we are a factory/studio choosing the best option to develop and deliver.

Managing Projects with Kanban

When the context is a major project comprised of many different capabilities/features, this approach works as well. There might be a stronger need to manage the overall project health, but the basic principles still apply. There was an interesting discussion about this lately in the kanbandev user group. I also covered this in my recent talk about Commitments in a Kanban world. In this area, I believe CC provides us with good practices and tools – Release Burnup/CFD charts can evolve to Fever charts for each project, and an overall Fever chart managing the overall projects portfolio.

Typically, breaking projects to features will result in quite a simple dependency graph/pert chart. This is because the network is comprised of self-sufficient features. Sometimes though, Features do have dependencies on each other, or dependencies on external groups, as well as need to be delivered independently before the major delivery. When this list of dependencies grows larger and larger, maintaining a Critical-Chain view of the project/program together with relevant feeding buffers might make more and more sense. This view should only care about Features with dependencies, so it is typically quite simple, ideally managed as a Big Visible Chart on a project wall, a Look-Ahead plan, etc.

Kanban’s view of Specialists

Kanban and Lean/Agile in general recognize specialization as a root cause for lack of flexibility and an impediment on the way to business-driven agility. We advocate generalizing specialists and the use of healthy engineering practices to make sure more of the work can be done by more of our people. While this is a worthy vision / desired state, many organizations cannot economically achieve that goal, not in the near term, maybe not ever.

So we need to optimize how we involve our Specialists while we are aiming to reduce our dependency on them, where it makes economic sense.

We start by recognizing that each person, including Specialists has a certain capacity for spreading his attention as well as for actual delivery. Once we overburden this capacity we are abusing our scarcest resource. When we limit the work in the workflow we align the workload with the capacity in the line. But specialists that hover above the work like busy bees flying between flowers require a separate approach. One way is to limit the number of cards a specialist can be involved in. Once that limit is reached, he cannot be asked to be involved in a new card. So either manage without him, or wait with starting that work. Visualizing this involvement will already drive some realizations and maybe some investment in reducing the dependency somehow by knowledge sharing, offloading, etc.

Another approach I touch on elsewhere (including the commitment talk mentioned above) is to classify the work based on need for shared resource and affecting routing decisions based on that. So if a specialist or any other type of shared resource is currently congested, consider pulling work that doesn’t require much of his involvement. Or even better, pull work that will reduce your dependency on him in the future.

Summary

Well, These are just some thoughts, an invitation for future discussion. I believe there is potential for a lot of synergy between Kanban and CC, especially in the world of complex programs/portfolios. I especially urge the TOC/CC practitioners out there to explore the “Feedback Oriented” view of Agile. What we all need to remember is that the main thing about the Kanban method is that it is aimed at catalyzing evolutionary improvement. It is similar to the aim of the TOC S&T trees trying to drive towards a Viable Vision. Don’t get confused by the mechanics. The key is to use the conversations that happen when it is painful to follow an explicit process policy, like maintaining a WIP limit, to learn something and improve.

And if you are currently using Critical Chain and would like to explore what Kanban or Agile might mean or how they can help you, I’d love to help.

• Classes of Treatment – not everything deserves the same kind of treatment…
• Kanban principles scales cleanly from team to portfolio
• Informing Team/Org Structure from Kanban thinking
• Context-specific explicit policies more important the higher you scale.
• Adoption Kanban – what happens in an internal consumer-producer supply chain inside large portfolios and how to use Kanban thinking to improve it.
• Stealth Kanban

I’d love to hear what you think, whether you attended my talk or not.

If you go through the prezi, would like to understand more, let me know. I might be convinced to do a webinar about this if several people request it. Easiest way is to contact me on twitter at @yuvalyeret.