EnergizingWhat do we mean when we talk about Energies of aKanban System?A Kanban system that is energized is a healthy system. Items floweffectively, and there is a feeling of engagement, focus andaccomplishment. How does a Kanban system that is low on energy looklike? There’s a feeling of being stuck in mud, of procrastination, of thingsbasically taking longer than they should have. Something feels verywrong.It is of course an analog scale with few systems in the perfectly healthy orabsolutely sick end of the range. My aim here is to start you thinkingalong these lines and give you some tips how to shift a system towards amore energized, healthier mode.Aspects effecting energies/health of the work systemIt seems that systems exhibiting certain properties seem to attract betterenergies/health. In my experience and research I found those to be keyattractors you might want to start with: Meaningful/Purposeful work with clear visibility to current progress towardsthe goal granular work items each with clear boundaries/constraints real-time clear visibility to the current health of each work item real-time and historical visibility to the health of the overall system Pull complemented by some time-driven self-accepted realistic/achievablechallenge Dynamic context-specific policies to deal with shifting context and demand Effective WIP Limits that provide enough space to maneuver but keep flowrunning Attractor for effective local cycle time compared to “Hurry up and Wait”This list is influenced both by these positive attractors as well as by somenegative attractors that seem to inhibit healthy systems. As we go overthe list of attractors, try to identify which of those exists in yourenvironment.
www.agilesparks.com - @yuvalyeretMeaningful/Purposeful WorkTeams that have a clear, achievable, business goal with a meaningful costof delay function they understand and believe in are typically quiteenergized and typically don’t rely on the Push system for their energies. Atone point in my time as VP Engineering my organization was working on arelease aimed at enabling one of our OEMs to really go to market with ourproduct. Time was of the essence as we wanted to take the next step withthis OEM and we knew a lot of the business case for the companydepended on this project. We used a Kanban pull system for most of thisrelease and didn’t have any energies issue. We actually delivered a verymeaningful release a few days ahead of time.Working towards one big goalSome teams are working on big things where the meaningful result is atthe end of delivering many small pieces. An example can be New ProductDevelopment (NPD), a platform refresh project, or delivering a newsystem. Despite our preference towards smaller batches, minimallymarketable features and minimally viable product, these contexts do existand will continue to exist at least in upcoming years. How do you energizea system when the finish line is far away?I believe you need to chunk this big thing to small pieces to generate asense of progress and finishing things, to provide you with some “progressbar” to see that something is happening as well as where are you in yourprogress towards the finish line and whether you are at a good pace ornot. In the world of Agile/Kanban we use Release Tracking techniques tohelp with that. We break a big release to small chunks, and use “ReleaseBurnups” or “Release Cumulative Flow Diagrams” to see where we arecompared to where we should have been. This is important not just forproject risk management. It is important as a progress bar for people aswell. If that is the finish line we are all trying to get to together, we needto be aware of where we are. But if the finish line is too far, we need tochunk into smaller pieces similar to stages in races and look at our “Splittime”.Working on a flow of itemsWhat if there isn’t any overarching goal? What if we are a support teamjust churning the support calls on a daily basis? What if we are a teamworking on a flow of features that each adds incremental value to thebusiness? This approach is the classic flow scenario and makes lots ofsense from a business perspective. We keep choosing the best thing to doat each point in time and do our best to deliver it.But there is a grave danger here. Where is the meaning? People andteams can get into a rut where they do things mechanically without apurpose.
www.agilesparks.com - @yuvalyeretTry… KPI TeamsIn Lean Kanban Central Europe 2011 the Prezi team presented a concept(S. Farkas, 2011) which I think is great help here. The Goal-orientedTeams. The concept is for each team to have one vision, one goal, withclear supporting KPIs the Team can use to verify it is on the right track. Sowe have purpose and we have clear visibility to progress towards our goalalong the way. Since those teams deliver small pieces of work using flow,after each delivery they can validate that they are making progress.Sample Team can be “Increase Registrations Team” with the KPIs beingincrease number of registrations and visitors.What about support teams which are working on cases/tickets not newfeatures? Here there is a real challenge. Beyond using SLAs as an attractorfor energized work I would experiment with engaging the team inimproving the overall results by setting Improvement goals/KPIs that areassociated with a certain class of service that runs in parallel to theexternal demand. I’ve seen several successful Customer Oriented RNDTeams (CORD) that mix SLA-driven work and Improvement/Innovationprojects as a way to engage and retain great people on those teams.Having Improvement/Innovation work that you can get to if you keep upwith the SLA-driven work tends to energize the system.The Right thing, the Whole Right thing and Nothing butthe Right thingStoryWhile not under oath, in knowledge work we are expected to do the Rightthings. What are the right things? Those that bring the best return on theinvestment in our efforts. We are expected to deliver the whole right thingasked of us and nothing but it. This is a Lean concept – delivering what’svalued by our customers. In Implementing Lean Software Development(Poppendieck, 2006) Mary and Tom Poppendieck map Lean’soverproduction waste to “Extra Features” waste – adding features that arenot needed to get the customers’ current job done. If there isn’t a clearand present economic need for the feature it should not be developed.They also talk about the waste of Partially Done Work. While they mainlytalk about Work In Progress, I want to extend it to work that wasdelivered but creates failure demand since we haven’t delivered the Wholeright thing. This one is tricky though. In Lean we try to learn what isneeded, and talking about the Whole Right thing can be interpreted as bigbatches. The concept of Minimally Viable/Marketable Feature helps ushere. We focus on the minimum thing that can get the job done or get usthe answers we need to learn about our next steps. Less than that and thejob won’t get done or we won’t have effective learning. More than that andwe have “Extra Features” waste.One of the situations I see very often is teams that have a hard timetuning to the right level of Minimally Viable Feature. This affects the
www.agilesparks.com - @yuvalyeretbusiness value they deliver but more pertinent to our context also theenergies. When the problem grows extreme people on the team start tolose the faith that they are delivering value towards a meaningful purpose.Think about starting to work on a feature, and while working on thatfeature being asked to add lots of functionality and capabilities that seemover the top. At some point teams get into auto-pilot/whatever mode.Think about a project to setup a new shipping center. The goal is veryclear – enable a new shipping partner by a certain date. If along the way itseems that a lot of the work we are asked to do seems like the personalfantasy of the business analyst or the product manager, the effectivenessof the purpose or timeline will diminish since it sends us a message thatnot everyone is aligned on the same goals.One of the successful projects I took part in provides an example of theopposite direction. At the time we were developing an OEM version of ourproduct. We were laser-focused on what we needed to enable this OEM –help him do his job of selling his product with our product inside. When indoubt we had direct channels to the partnership owner on the OEM sideand could collaborate on nailing down the details. The Product group wasrunning interference to avoid any unneeded scope getting into thisrelease. People felt like they were doing something with a purpose, andthat everyone is rallying to help them achieve their goal.Effective Work ItemsSo how do we help teams focus on the right things? We start with lookingat the work items/containers, also called Backlog items. These mightrequire different effort at various stages. We want our items to be sizedeffectively. Healthy team-level Kanban systems have items that rarelystay in one lane of the board more than a few days, ideally not more thaneven a day. In order to minimize the cases of unbounded work due to Pullmode we want the items to have clear scope boundaries. Exactly what is itthat we will have when the item will be done? How will we see and verifythat?Try… Defining work items using Stories and ExamplesApproaches such as User Stories, Behavior Driven Development,Acceptance-Test Driven Development or Specification by Example are allgreat ways to enhance the clarity of the backlog items that flow throughthe system. They all rely on having clearer conversations about the scopeas part of readying the item for pull.Try… Limiting and visualizing Work SizeMature teams find that they work much more effectively once the vastmajority of work items falls under a certain size. Try establishing a policythat sets a Maximum Work Size for items entering certain lanes – e.g.Only Small items can enter development. Every policy is a guideline andthere can be exceptions. The important thing is to discuss exceptions as ateam and decide you are ok with them, and think how to reduce thenumber of exceptions over time. In the graph below you can see a fewexceptions after limits were set, but the trend is clear.
www.agilesparks.com - @yuvalyeretSide Note: The smaller the items, the clearer they will be and the lesschance we will have for non-value-added work or lower priority work toride on the back of our work items.Good Enough QualityAssuming we have an effective granular definition of the scope we need,we might still have a problem. There are activities that are even harder tospecify explicitly than scope. Quality Inspection is one of them. How muchtesting should we do? Managers tell me that when deadlines are abolishedor taken on by teams rather than pushed onto them testing takes longer.The hunger for perfection that was held in check by deadlines andshortage of resources/time is set free.Try… Tests and Examples establishing Quality BoundariesTests and Examples establish the specific Quality boundaries of each workitem.Try… Establishing Quality Guidelines as Explicit PoliciesIt also helps to Establish general Quality policies that serve as boundariesto the work, but are not specific to each item. Some examples can be “Noopen defects”, “All tests running green, no disabled tests”, “90% testcoverage”. James Back talks about “Good Enough Software” (Bach,1995)11http://www.satisfice.com/articles/gooden2.pdf, Joshua Kerievsky, inhis LSSC11 presentation, talks about “Sufficient Design” (Kerievsky,2011). Both are examples of less than perfect Quality policies. Theimportant thing is the clarity among all people working in the system whatexactly is the desired Quality and why.Try… Establishing different Quality Policy Guidelines for differentclasses of workWhile having one clear Quality policy simplified things, in many cases itmakes sense to evolve towards a set of possible Quality policies, eachfitting a certain class/type of work. For example, Experiments in aSandbox might be released with lower Quality and Design thresholds thanupdates to the production workhorse features. These different classes oftreatment can help us deal with variable loads across the system – for
www.agilesparks.com - @yuvalyeretexample prefer pulling experiment work in case we have a testingbottleneck.Dangers of Pure PullReinertsen’s (Reinertsen, 2009) Expansion Control Principle claims that inproduct development we must control the expansion of work. Some workin product development can behave like the perfect gas of physics. Itexpands to fill the container, no matter what size of the container. Oneproblem with a pure pull system is for these kinds of work that expand, wedon’t have anything controlling the expansion.C. Northcote Parkinson (1909-1993) first published the "law" -- "Workexpands to fill the time available for its completion." -- in November, 1955issue of The Economist in an essay entitled "Parkinsons Law," republishedlater in a book of the same name, currently published by BuccaneerBooks.Try… Pull complemented by cadenceA lot of teams use Kanban Flow to complement or evolve theirSprint/Iteration based Agile Process. I’ve worked with several of thoseteams and in most of them there aren’t any energy problems. The factthat there is some sort of heartbeat and deadline, even though it isdefined just as “Demo all done stories and then deploy/release them”,introduces an energizing force into the system.Try using some form of team/group cadence to control the expansion ofwork. Use the cadence as an opportunity to review the items in progressand decide whether continued investment in them is preferable tocompleting them (or throwing them away) and moving on to somethingelse.Try… Pull complemented by a per-item timeboxIf you look at SLA-driven activities like Customer Support, work typicallydoesn’t expand even if there isn’t a cadence like Sprints/Iterations. Thereason is that each work item has a time constraint attached to it – theService Level Agreement. If your team is not under SLA, you might wantto try creating some of the positive constraints SLAs provide. If we couldpredict the exact timebox an item would need it would be great. Alas, inour kind of work there is too much uncertainty/variability to predict thetimebox. What can we do?
www.agilesparks.com - @yuvalyeretFigure 2 Standard Gaussian DistributionLet’s look at Figure 2 which describes a standard Gaussian distribution foractual cycle times in our system. We can see that very few items completein under 5 days, very few in over 15, most are somewhere in between,with 10 days being the most likely completion time.How should we define the timebox for a new item that is now starting? If we use 5 days as the timebox, most items will not be able to complete in thattime. If items do complete there is a very good chance that some price was paid tomake it. Typical prices can be unsustainable pace of development or lower quality. If we use 15 days as the timebox, most if not all items will complete, but theExpansion principle means that a lot of items that COULD have taken less than 15days would take 15 days just because we provided that timebox as theconstraint/guidance. If we use 10 days as the timebox, about half of the items will complete in thattime with some work expansion waste, and about half of the items will complete inthat time or late with some unsustainable pace/quality price paid.To sum up, none of the timeboxes suggested above are ideal. The problemis mainly with the way we define the timebox, and the effect it has onactual execution. Let’s now look at a couple of alternatives.Try… Theory of Constraints style Buffer ManagementThe Theory of Constraints and specifically its Critical Chain approach toproject management describes a good solution for this problem. Let’sassign a timebox based on the 50% point (10 days). We don’t consider ita commitment though. We consider it guidance of what we might expect ifall goes well. If an item is 5-10 days in processing we consider it greenand let it flow without any special attention. If an item is already morethan 10 days in processing we can consider it yellow and start paying
www.agilesparks.com - @yuvalyeretmore attention to it. If it’s more than 8-9 days in processing we need totake pro-active action to ensure completion. This attention to times that isDECOUPLED from commitments provides us with what I like to call “SoftConstraints”. It is similar to the effect of a demo/delivery cycle every twoweeks. We don’t HAVE to finish our story by that time, but it’s certainly anenergizing factor. Sometimes even a bit too much.Try… Learning from red itemsAnother thing we should do is learn from the items that spent the mosttime in processing. What were the reasons for that? Can we identify anaction item that will reduce the chance that a similar item will spend somuch time in processing?What we are nurturing here is a commitment to strive for shorter andshorter but still sustainable cycle times. This in and of itself will energizeour system.Try… Adjusting the constraints as the system changesOver time the distribution of cycle times might change. Pay attention andchange the boundaries of green, yellow, red accordingly. This will makesure the system continues improving.Add more stuff hereThe dangers of SlackWorking in real pull mode means that sometimes we will be signaled fromdownstream that the queue between us is full and we need to stop andwait until there is room in the queue. This should create some Slack in thesystem. Ideally, we should complete our work as fast as possible and thenstop and wait. That would ensure we understand where the constraint is,and maintain our capability to locally process the work as fast as we can.It doesn’t always work that way though. We tend to slow down when werealize there is no rush. David Anderson (Anderson, 2004) talks about thiseffect and refers to the “Road Runner BehaviourIn TOC language, this stop-goeffect is often called “Road Runner Behavior” after the Warner Bros.cartooncharacter who only has 2 speeds—full speed and stop. Road Runnerbehaviormay be bad for morale amongst the analysts. Hence, the Agile managermustbe aware that the subordination step in TOC is dangerous and needscarefulmanagement attention during introduction.Probably the best way to deal with this is to ensure that everyoneunderstands the Drum-Buffer-Rope principles and that they are aware of
www.agilesparks.com - @yuvalyeretthe current system constraint. If they know that they do not work in theCCR, theyshould be comfortable with their new role being only partially loaded. Thistechnique of sharing an understanding of the system process and gainingbuy-in to changes has been called “?Fair Process” [Kim 1997]” as it isknown in the Theory of Constraints. For example if we see a congestionbuilding up in deployment , We as the development team might anticipateour work being queued up as well and we will slow down. This means thatthe “local cycle time” for development will be slower.This has problem has several undesirable effects: When the congestion is solved, we might already have gotten used to theslower cycle time and it will be hard to pick up the speed again. These problems mightalso contribute to hiding congestion if the whole system just slows down to the lowestcommon denominator. People don’t like to have too much slack. It goes against their feeling ofaccomplishment/purpose. Being told to “not start” also goes against their feeling ofautonomy. It also affects their feeling of job security – I’ve seen examples oforganizations where people are afraid that prolonged slack will turn into layoffs. It becomes harder to see the real capability of the system. Constraints are beinghidden and it appears that there are no bottlenecks – everyone is working in the samepace. Now where do we focus our improvement efforts?Try… Exploiting Slack towards Improvement ActivitiesSince people on one hand don’t like to have slack and on the other handlike to accomplish things and move on, let’s give them additional workthat they will be able to pull even under congestion. Let’s look at somepotential activities, by order of preference:1. Ideally, help current work flow if you can (Help others in your area ofspecialty or downstream)2. If you can’t, pull activities that will increase the capacity of the currentconstraint (E.g. work on automated deploy if deployment seems to be a bottleneck).3. Pull improvement work directed at current improvement goals of the group –Learn skills that the group has a shortage of, Improve Quality, Research an upcomingactivity.4. Improve/Innovate as you see fitRegardless of what activity you choose, it is important to track andvisualize it as part of your work system (Kanban board) – preferably as adifferent class of work/service so it is clear it is in play and how much of itwe are able to process. This is important for people (who now feel saferknowing that they are doing sanctioned work and that those around them
www.agilesparks.com - @yuvalyeretsee that) as well as towards having a clearer picture of the system and itscapabilities and constraints. Local cycle time within each station shouldremain fast.Try… Establishing a better collective understanding and trustaround Slack and SubordinationHave a discussion including those managing the system and those workingin it. Establish a policy of how to deal with Slack. Emphasize the fact thatsome Slack is desirable and that we will aim to make the best use of itonce we recognize it. Let’s be honest, if we find that for some reason ourline is so unbalanced that we need to intervene, we will. But explain thebelief that through subordination and changes in the handoff/interfacepolicies of how we do work we can have a major impact on the balancingof the line, and that is the path we prefer. Intervening by adding/removepeople is the last resort. If we manage to generate the trust that this isindeed our intention, we will be able to see the actual system and work toimprove it together.Try… Measuring local cycle times AS WELL AS overall cycle timesThe most important thing is the overall cycle time for delivering thedesired value in the desired quality. This should be clear to everyoneworking in the system.We can also measure local cycle times within processing steps with thetarget of having the fastest possible local cycle time for delivering thework item to the next step queue in the desired quality that will help thenext steps downstream have a fast local cycle time as well. Measuring thatwill nudge us away from the local slowdown.Note of caution – it should be really clear that the global cycle timeoptimization is the important aspect. Pay close attention for what seemslike local optimization – e.g. delivering fast but with crappy quality thatcosts more downstream.Hurry up and WaitAnother problem is that the more inventory and slow-down I seedownstream from me, the slower I will become. This is what Reinertsencalls the “Hurry-up-and-Wait” principle (Reinertsen, 2009). In systemswith high or non-existent work in process limits this can be a seriousissue. People know that if something is important it will be expedited, andthere is less urgency to finish normal work because they know it willanyhow sit in long queues, so how important can it be to finish it?You might suspect this is a problem when you discover a huge differencebetween local processing times for expedited items versus normal items.Expedited items will not spend time in queues so for sure will finish faster.But the processing time should be comparable between expedited itemsand normal ones, and differences can suggest “Hurry-up-and-Wait” is ineffect.Try… Going to lower WIP levels
www.agilesparks.com - @yuvalyeretThe solution here is to go to lower WIP levels to reduce queue lengthswherever possible.Try… Go to where the work is done and pay attentionNot all information about the system can be gleaned from Kanban Boards,Flow diagrams or Cycle Time Control Charts. In order to sense thehealth/energy of the system and the people working in it you need tospend time where the work is done, listen in, pay close attention and talkto people outside of formal status meetings or operation reviews. Whileimplementing a pull system or any change in the way work is doneManagers should allocate a significant slice of their attention/time to whatwe call “Go See”/”Sensing”/”Go to the Gemba”.Sensing the state of the SystemSo far we discussed several possible energy/health-relatedpatterns/symptoms and experiments you can apply to try to deal withthem. An important ingredient in enabling this experimentation is theability to Sense the state of the system. As we are talking aboutexperimentation cycles we want to have the ability to quickly Sense whatis going on.Beyond that the ability of everyone to sense the system and work itemstate helps energizing the system. We want everyone to see strugglingwork and have a clear policy of how to deal with it.Seeing dynamics of the system in a static pictureOne of the challenges in sensing the dynamics of a kanban system is thatthe kanban board itself is static. Each time we look at it we see a snapshotof how the system looks right now. It is very hard to see which items areflowing ok, which are struggling.In order for the system of work to autonomously deal with struggling workwe need the kanban system to radiate this information visibly and clearly.Let’s look at a couple of ways to increase the visibility to the dynamics ofthe system.Basically what we are looking for are ways to associate certain indicatorson the kanban board with movement, similar to how we interpret whitespots in a picture of a river with areas of fast-moving water and dark stillareas with slower-moving water.
www.agilesparks.com - @yuvalyeretTry… clearly marking blocked itemsOne of the most common examples is blocked items (also calledimpediments/showstoppers by some teams). We typically indicate an itemis blocked by changing its color (typically to red) or assigning a specialsmall note to it.
www.agilesparks.com - @yuvalyeretTry… indicating when the blocker appearedProviding this information can help a team understand how long the itemis not moving and escalate handling, especially with a big board with lotsof tickets.Try… Collecting blocker items and learning from themWhen a blocker item is cleared, keep it. Periodically look at the recentblockers and look for common reasons. Try to find what is causing theseblockers and what you can do about it (You can use something like a FiveWhys root cause analysis exercise). Schedule work to pro-actively dealwith this kind of blockers. This is by the way risk mitigation activity asdescribed in (Tom DeMarco, 2003)Struggling/Slowed down workWhat about items which are not stuck but are moving very slowly? Thispresents a few questions. What does it mean that an item is movingslowly? How do we know? Do we rely on our feeling? On actual data?There are a couple of ways to address this. Let’s look at a fewTry… People indicate health of their storiesOne way is to let people indicate the health of their stories. The benefithere is that we bring the issue to people’s attention and give them a moreexplicit chance to report on slow-moving work. The downside is that it isnot a clear-cut decision when to mark something as healthy or sick.
www.agilesparks.com - @yuvalyeretExperiment with this approach. You might find that people’s instincts go along way, especially if it feels safe to report that something is strugglingand it helps people rather than earns them a micro-management policetail.Highlight cards based on lane-specific age thresholdOnce your system is running for a while and you know more or less howmuch time cards tend to spend in each lane (local cycle time) you canhave a policy of highlighting cards that are already too long in the lane. Anexample from Amdocs shows exclamation marks on cards that are alreadytoo long in the Requirements lane. Note that it makes more sense to trackthis for “In progress” lanes than queues. Queued work in “done” lanes is afunction of system health rather than specific work items health. It mightmake sense to show some indication of overall cycle time even whenqueued, but not local cycle time.Buffer Management Color SystemEarlier when discussing TOC style Buffer Management we outlined a wayof indicating a work item health/pace using a green/yellow/red system.Ideally work should be marked with those indications on a kanban board.Zombie Cycle TimesAn easy way to indicate item age is to mark that age on the card, ideallywith some cool metaphor that people connect to. Luke Smallwood(Smallwood, 2011) uses babyzombies. A basic way is to use stickers andfor each day an item is in play replace the sticker with the next sticker. Amore “green”” way to do it is to have a mini-lane for each age and movethe items between lanes as they age. This is an easier way when trackinglocal cycle times within one lane. Replacing stickers makes more sensewhen tracking age across the whole board.
www.agilesparks.com - @yuvalyeretAvoid… tracking progress percentageA word of caution. It might seem like a good idea to indicate progresssomehow. Effort hours remaining, % complete or similar indicators. Ipersonally don’t like this approach too much. The main reason is that weknow these indications are far from accurate, and an item is not done untilit is done. I prefer tracking progress by completion of work rather thanasking people to spend time estimating remaining effort.Try… rolling up status of inner workWhat you can try is rolling up the status of inner work. If a story requirescompleting 5 tasks to move to the next lane then you can indicate 3/5tasks done. If a feature is comprised of 10 stories and 2 of them arecomplete you can indicate 2/10 or 20% done. You can mark thisinformation on the parent card.Heat map exampleAnother way to visualize health is to put on some “Age Goggles” likeshown in the heat map here. With those “goggles” the main visualindicators from the board will be age of the card. This allows focusing onaging cards.Try… Time lapse moviesWith the advent of electronic tools and advanced gadgetry teams canshow a time-lapse movie of activity from recent days as part of theirreview of the current status. As few teams are currently using thisapproach, it is still early to say how much of an effective attractor this is
www.agilesparks.com - @yuvalyeretfor energizing the team. Try it out and let me know if you find it helpful oruseless.Why is seeing it so importantWhy do we spend so much energy visualizing the dynamics of the system?There are a few reasons. We will focus on late tasks which counteract the amplification principle whichsays that the more late we are the more we will prefer to neglect the late items andwork on fresh items. We will encourage whole team attention/swarming to late items rather thaneach of us focusing just on his own work. If we want to improve the system we need to sense/observe it. When trying toimprove how the system deals with work health/energies we need to visualize theseaspects as best as we can to improve the experimentation cycles.
www.agilesparks.com - @yuvalyeretWhat do we do when we see energy/health problems?Kanban talks about making the process policies explicit. How we deal withhealth problems is a great example for explicit policies: “Involve the expert” – e.g. normal items will by default be pulled by anyone,or even specifically by those learning a new area we want to increase our coverage of.But if item becomes yellow/red we involve the expert of that area to help converge thematter. “Stop/Continue Forum” – We can decide that once an item reaches a certainage, we start having a “Stop/Continue” discussion about it on a frequent basis e.g.daily. Uber-Slicing Mode – We can decide that we allow Small and Medium workitems into the system. But once they reach a certain age, we require items to be sliceddown to Extra-Small slices. This might be better than spending the effort for slicingand managing all items in this granularity. We can decide that at this point we startmanaging tasks for example. Pairing – decide the policy for pair-programming. Do we want to start pairingwhen work reaches a certain health threshold? Is there a point where we swarm evenfurther? Is there a point where we “stop the line”?Having the discussion around the process policies makes the actualcounter-measure when seeing problems faster and autonomous with lessdiscussions in-band to the work.Try… Breaking the flowWe keep talking about sustainable flow, sustainable pace, continuousdelivery all creating the picture of endless work at the same pace. Even ifthis pace is sustainable, everyone needs a change of pace once in a while.Think of physical exercise – we try to break things up by doing intervaltraining. In gaming we break things up by “Boss levels” and mini-games.In product development I recommend a change of pace every now andthen – Slow down, Accelerate, use a different cadence.In my 6-month programmer training in the Israeli army we had such achange of pace every few weeks. Whenever we reached a certain level wehad a few intense days exercising the learning so far in the program. Itwouldn’t be effective to work at this pace the whole 6 months, but ourachievements in those days and the energies they introduced into thewhole experience were unforgettable.You want to find those experiences that will bond people together. Theseintense changes of pace tend to serve such purpose. Luckily for us, eveneffective pull-based systems need to deal with the occasional expedite, sothere is plenty of opportunity to swarm around a difficult challenge. Justmake sure you make this a memorable experience not a painful one.
www.agilesparks.com - @yuvalyeretEnjoy the pressure and intensity. Get some pizzas together, go out for adrink to celebrate when done, whatever works.Conclusion - Start SimpleYou might feel overwhelmed by the catalog of patterns described here. Mysuggestion is to start simple. Sense for health/energy issues. If you dofeel there is some problem, choose one pattern and try it. See whether itimproves the situation or not, and then decide whether you need to tryanother pattern or not. Add visibility information if you feel you need it.Whatever you do, don’t go in all guns blazing and implement everythinghere…