Observing Replenishment

Replenishment (or commitment) meeting is an activity concerning the decisions made at the so-called first commitment point of a Kanban system. It is one of the seven Kanban cadences, which are all part of the Kanban method. Cadenced events happen, as the notion of cadence suggests, predictably at deliberately chosen intervals. They connect information flows (predictably) and thus close the feedback loops. The healthy feedback loops enable evolutionary change.

What if you don’t have a Kanban system? You’re still running some business. This involves making regular decisions about what you should be working on now versus what you should defer until later. When you design a Kanban system to model the process (as it’s actually practiced) of delivering a product or a service that is part of your business model, the Kanban system’s first commitment point will mark the point in the workflow where you make such decisions.

Making commitment points explicit is likely to bring some transparency and clarity to your decision-making process and stimulate improvement. This is one of the many benefits of introducing a Kanban system. Implementing a replenishment meeting takes this benefit one step further.

What are we looking for in a replenishment meeting? Some coherence, logical connectedness of the following:

  • Participation: Who are the decision-makers? Were they in the room?
  • Information: What did the decision-makers bring to the meeting?
  • Options: Before the Decisions were made, what options were available? Was the Information relevant to the options?
  • Decisions: Which Options were chosen? How did the Information lead to choosing some Options over others?
  • Timing and Change: When was the previous replenishment meeting? How did the set of available Options and the Information change since then?
  • Procedure: how did the decision-makers actually decide? Were the appearances compatible with their method?
  • Duration: How long was the meeting? Was its duration commensurate with the multitude of choice?

Now let’s go and observe an actual meeting billed as Replenishment. All names and timings are changed to protect privacy.

A coach's notes from  the replenishment meeting. Various problems are highlighted. See the text below.

It’s quite clear that no act of commitment or replenishment took place here. The obvious clues to that are:

  • The set of decisions (features to start) matches the set of options exactly
  • The metrics presented by the Team Lead relate to a different, lower-level work item type. User story-level metrics could be useful for sequencing user stories. Feature-level metrics could be useful for scheduling features. The information presented doesn’t connect to the options or decisions in this case.

We just saw pseudo-replenishment. We also saw several things that let us reasonably infer a number of things about the system. There are at least two work item types. The two form a hierarchy and there is a two-level workflow. Each level has a first commitment point somewhere. And somewhere, sometime, two groups of decision-makers, people with different rank in the organization and different boundaries of autonomy, meet and use some decision-making process to make their respective decisions.

Shortly afterwards, a design meeting is called and it goes on for two hours. People with higher titles are absent, but a group of business analysts and a Senior Architect join. The discussion is largely about some design of the solution, acceptance criteria and such. However, there are several scattered moments totaling maybe 10 minutes, when: the Architect surfaces some technical risks, the Business Analysis Lead does the same for some requirement risks, and people come to the conclusion that several particular work items out of many others should be started before all others based on these risks.

Those ten minutes were the replenishment meeting. Implementing the replenishment meeting, one of the Kanban cadences, means making this decision process transparent, connecting its elements logically, with the intention to improve the decision-making. As the decisions in this example involved sequencing work within committed scope, it would be more appropriate to call this activity proto-replenishment. Read more about proto-replenishment here. Proto-replenishment is to proto-Kanban (e.g. Team Kanban) is what replenishment is to Kanban.

As for the Kanban system replenishment, it is not in the cards yet for this particular service. They are, for the time being, only able to pursue localized, team-level benefits. When they design a Kanban for their multi-team service, implementing the replenishment meeting will come into focus.

Summary

  • Replenishment meeting is not a new ceremony to introduce in your process
  • Somebody, in some time and place, already makes decisions. Replenishment meeting is about making the decision-making method transparent, so that people can improve it. Transparency may even save them time.
  • Implementing replenishment meeting involves both observing how people try to make decisions now as well as designing improvements to the process.
  • It’s very important (to your business) to understand the logical connectedness of decision-makers, information, options, timing, and decisions.
Advertisements
Posted in coaching, Kanban | Tagged , , , , , , , , , | Leave a comment

Kanban Games

As someone with good knowledge of the Kanban method, people ask me from time to time about good games as learning tools to aid people in learning the method. Also, as an accredited trainer and coach, I must be using some interactive tools or games to help transfer my knowledge to the clients. So, which games do I use?

GetKanban is, of course, the first game I should mention. Russell Healy invented it six years ago and many people around the world have played it ever since. (Russell won the Brickell Key award, the highest honour in Kanban, in 2011 for inventing this game.)

GetKanban V5 Example

The full version of the game takes about three hours to play. A shortened variant takes 90-120 minutes, which makes the game accessible to after-work community groups and conference sessions where many people have actually played the game.

GetKanban has evolved since its invention and is now up to version 5. I use this version, with a few rule modifications in one of my training classes.

The 2-day Kanban System Design (KSD) class, classified as KMP I-level training in the Lean Kanban University curriculum, is where GetKanban game is the most appropriate. Here we teach people to apply Kanban at the service-delivery level, not the team level, to understand and use Kanban systems, and to design Kanban systems for services within their organizations using the systems thinking approach. Students learn many Kanban system elements such as work item types, classes of service, workflow activities, commitment points, replenishment, delivery planning, explicit policies, visualization of risk, cadences, transaction costs, coordination costs, and so on. They learn what to observe in their unique business environments and how to incorporate their understanding into their Kanban system design. The GetKanban game within the context of this class allows them to actually learn these things by experiencing them. Much better than listening to a lecture!

Note that the game itself doesn’t deliver training in Kanban system design. The 2-day KSD class works and is effective because it includes the game and many other activities and they all fit together. Nearly all people who have played GetKanban at some point and took the class later reported that their understanding of the method and skill in applying Kanban increased greatly after the class.

FeatureBan. This is a relatively new game, invented by Mike Burrows. It is simpler, more compact than GetKanban, and takes less time to play: 60-90 minutes. It is a great fit for introductory and team-level Kanban training. I use it in the 1-day Team Kanban Practitioner (TKP) class.

FeatureBan Example

Playing GetKanban in the TKP class would consume more time. But time is scarce and we are better off using it for more learning outcomes. (Not a speculation, we have tried this approach.) At the same time, GetKanban is very effective and a better fit to the 2-day KSD class and its service-orientation agenda. As with many things Kanban trainers and coaches do, appropriateness for the context and coherence of problems at hand and variations of approaches to them are always considered.

Kanban Boat Game invented by Klaus Leopold. In this game, the players form a line and make paper boats. This game is superficially similar to various other flow games, where players make things out of pieces of paper and, when they start controlling work-in-process (WIP), their flow gets better and productivity improves.

Kanban Boat Game Boats

Klaus’ Boat Game, however, is different, because it actually teaches a different and very important point: the limitations (and in some contexts, futility) of the team-level Kanban introduction. As one of the modules in Team Kanban Practitioner (TKP) training is about students’ understanding these limitations, learning there’s more to Kanban and how and when to move up to the service-oriented Kanban system design, the Boat Game is a very useful tool in this class. Late in the class, to be clear — not before the participants have played FeatureBan and achieved more foundational learning outcomes through FeatureBan and several interactive exercises.

As far as I know, there are no written instructions to the Boat Game yet. Klaus did post a video. I found the facilitation tricky. There were many important nuances for the trainer to pay attention to that could make a difference between achieving the deep learning outcomes this game is for and yet another paper-folding game. Klaus makes it look easy. The best way for others to learn this game is to have been at the Kanban Leadership Retreat in Mayrhofen where we played this game and came up with the TKP curriculum. This should not to deter professional Kanban trainers who should by all means practice and learn it. I intend to use this game every time I run a TKP class, late in the class, of course.

Other games. There are many simple flow games, such as the dot game, the coin game, the name game, etc. They will teach people how to see the flow of work and how controlling WIP can lead to better quality or productivity. These games are entirely appropriate for Kanban and Lean thinking enthusiasts to show the basic concepts of flow to beginner audiences. However, in Lean Kanban University-accredited training classes, which are all tailored to meet certain learning outcomes (changes in what people actually do after the class as far as managing work in their companies), accredited trainers use appropriately different games that have evolved and are uniquely adapted to those outcomes.

Summary

  • GetKanban game version 5 in the Kanban System Design (KMP I-level) class
  • FeatureBan and Kanban Boat Game in the Team Kanban Practitioner (TKP) class
Posted in Kanban, training | Tagged , , , , , | Leave a comment

Billable Hours or Days?

Hi Alexei,

[Some reasonable proposal]

What’s your daily (or hourly) rate?

Regards,

All right, continuing the topic of consulting. That is, the art, science and business of influencing other with some sort of advice at their request. At some point, you need to measure your presence in time units and put a price on it. What units would you use?

A day is often billed as eight nominal hours anyway. Even though it is sometimes a bit shorter, very often longer and sometimes much longer. So, does it even matter, hours or days?

I contend that it matters a lot. First, to the client, and then somewhat to the consultant.

My firm, Lean A-to-Z, Inc. always bills its clients in days. Actually, even more to the point, if we’re talking say a three-day training class, we quote the price for the class, not some number to multiply by 3 or by 24. Oddly enough, a three-day class has exactly three days, so its price doesn’t depend on time! But it should probably depend on the number of participants! It is typically a flat amount that includes participants up to some number plus some amount for each additional participant. And that’s what we quote.

The only exceptions to this policy are when we partner with other firms and agree to use different units as a formality. We’re still in agreement on how we value time and presence.

So, why does this matter?

Let’s listen to the sound of 40 billable hours

Last week you sent us one of your consultants. He put in 40 hours of work. The consultant did [a long list of activities.]

Can you explain what value we received for the 40 units of work we were billed for?

And now, the sound of 5 billable days

We recently made one of our consultants available to your organization for a week.

  • What problem did you try to solve together?
  • What questions did you ask?
  • What questions did the consultant ask?
  • Which of those questions did you find the most insightful?
  • What advice did you receive?
  • What did you decide to do with the advice?
  • What was the result?

Does it sound different now?

Connecting to my previous post, what if the number of hours in the first soundbite was not 40, but 960?

Posted in Consulting | Tagged | Leave a comment

Is Agile Costing Too Much?

Hi Alexei,

I hope you’re doing well. I was thinking of you because we have a client in [location] and they have a 6-month opening for an Agile coach. Would you be available to start February 15?

Regards,
[Name withheld]

I have many similar messages in my email archive.

You may be a consultant or a contractor who receives such messages, a recruiter who sends them. You may know or work for or with someone who is. You may be a manager or executive in a company that decided to invest in Agile and engage an Agile consulting firm. This decision led to the creation of one or more such “openings.”

I want you to see the dollar signs in this message.

Most such six-month contracts involve on-site presence four or five days a week; sometimes three, but rarely. The typical batch size is between 90 and 120 billable days. Daily and hourly pay rates vary, but within a range. If you’ve ever received, sent or caused someone to send such a message you know what it is. The consulting firms’ markups can range from 20% to over 50%. Travel expense allowances are sometimes generous dollar amounts, sometimes not so generous, sometimes a percentage of fees and sometimes not offered at all.

What’s the total? Low six figures. Certainly over $100,000 and in some cases over $200,000. Some transfer of expertise (in this case, Agile) is taking place and this is the atomic unit of commitment and delivery to the client.

Let’s save for another day the incongruity of using six-month batches worth over $100,000 to teach people to deliver results to their own customers in small increments every two weeks. We should still ask questions, such as: is this the right price to pay for the benefits? Are client companies taking appropriate levels of risk? Is this delivery business model sustainable? Is there a better way?

David J Anderson, the Pioneer of the Kanban method, wrote earlier this week: Is Agile Costing You Too Much? I strongly recommend reading his article before returning to the rest of this post. (Spoiler: his answer is an emphatic “yes”, highlighting the key differences between Kanban and Agile, and illustrating the point with many real-world stories.)

I’m offering several such stories of my own in this post. I was involved in them directly. They support the same conclusions.

Story #1, a video software company, over 500 employees at the start, increasing by 20% in one year. Quality was a significant problem at the start. They expressed it anecdotally and it also showed up quantitatively in our demand analysis exercises early on. (Demand analysis is one of the Kanban techniques we teach in the foundational KMP I – Kanban System Design class, part of the Lean Kanban University curriculum.) Said the CEO one year later:

“Kanban didn’t solve our quality problems. It consistently led us to better decisions, which, in turn, led to improvements in quality.”

The Kanban initiative involved not only the software engineering department. The impact was company-wide. Finance, sales engineering, training, HR, marketing, you name it. Their director of training created the first organizational feedback loop with Kanban. When asked to name their the most impactful Kanban implementations during one of my visits, the executives started with the Accounting department. The total number of employees receiving some form of Lean Kanban training was about 100. It may seem like a small number (less than 20%), but Kanban training is not about imparting knowledge and teaching every team member various practices. It is management training for those making decisions in their business and it is designed to help them think and act in new, pragmatic ways.

Twenty-seven people (about 5% of the company) received training up to the Kanban Management Professional (KMP) credential level. This number included the CEO, the CFO, the VP of Engineering, the manager of every key department and several experienced technical specialists. I’ll save the KMP credential discussion for another day. It will suffice to say today, all Lean Kanban University credentials have a story and signify something. A short KMP story goes like this: if you are a leader of an organization of several hundred and two dozen KMPs work for you, you’ve got a great chance to run a modern, adaptive, resilient business.

How much did this cost? Four consultants were involved. Don Reinertsen and David Anderson paid one short visit each and the rest was done by me and Dave While in a series of short visits, totaling about 25 billable days. The per-hour cost to the client was certainly more than the number you’d hear or give a recruiter looking to fill an six-month Agile coaching contract. But what was the total? How did it compare to one or two Agile coaching “atoms”? It may have been approximately one and was certainly less than two. If the company decided instead to invest in one Agile Coaching Atom, the effects would have been most likely confined to a small number of engineering teams adopting Agile rituals.

Story #2 – the life sciences company where Evgenia Ovchinnikova was the Operations Directory until recently. I taught her to be the company’s internal Kanban champion and only made a few visits for training and consulting and several conference calls. The company’s CEO, CFO, VP of Sales, and the director of almost every department all received the Kanban System Design (KMP I) level training. Evgenia went on to “kanbanize” about 30 different services within the company, employing over 700 people. STATIK (the systems thinking approach to introducing Kanban), which is taught as part of each Kanban System Design class, was key to designing many context-fitted systems with consistent quality. The top-level Kanban system was a Portfolio Kanban of the company’s entire product pipeline. The newly introduced Kanban systems led to substantial behaviour changes within the management ranks. This is about all I can say about this company. Details of their Kanban implementation have become a closely guarded secret as they view it as a source of their competitive advantage. We’re very happy for them!

How much did this engagement cost? Well, the money would not be enough to buy even one Atom. If the company had somehow retained an Agile coach for fewer billable days, that would have bought them coaching of a few teams through formation, chartering, kick-off and the first couple of sprints at the most.

Story #3 – now on a somewhat smaller scale. Kazakhstan is not backward as Borat would make you believe. But it is a remote country, far from the centres of methodological thought in the USA, Western Europe or even the emerging ones in India and China. Good advice is not easy to get. Natalia Li came from this place to the Lean Kanban Russia 2015 conference to present her software company’s case study. She didn’t coach multiple teams on adoption of rituals. She didn’t try to fix the teams of workers scooping red beads in a broken system. She instead designed a Kanban system, negotiated its introduction with the stakeholders, and used it to reduce the wait times and blockages in a workflow spanning four corporate departments. These systemic improvements caused throughput to double and the lead time to reduce by 40%. The first iteration of her Kanban system was designed — you guessed it — one year earlier, in 2014, in the Kanban System Design class I taught together with Askhat Urazbaev.

The investment Natalia’s employer’s risked in 2014 to get these rewards was to send her on a week-long trip to Moscow to attend a Lean Kanban conference and take the post-conference training. The registration cost about $1,500; travel expenses, take a guess. At her company’s smaller scale, tens of employees rather than hundreds, sending one person turned out to be enough. Again, service-delivery Kanban is not about teaching or coaching every team member how to perform practices and rituals. Could the Agile Borat coach one team to its first sprint retrospective on this budget?

More stories to come. The six-month contract vehicle, which I started this post with, continues to be a fact of life. I’m seeing some progress however. In the last year, I have been able to negotiate down the batch sizes, dramatically in some cases and arrange schedules that allow me to visit and deliver consultations and training to multiple clients. This has already saved clients money and made my advice more effective. But it wouldn’t have happened without actions of key individuals responsible for designing these consulting engagements. I appreciate them for their courage to think and act differently.

Posted in Kanban | Tagged , | 1 Comment

Return to Blogging

The New Year 2016 is upon us. Now may be the time to tally up 2015 results and make some new year resolutions.

The results don’t look very good! I neglected blogging for much of the year and published only two posts. This has to change in 2016. There is so much to write about: new stories, ideas, facts about how people work together, manage their work and their businesses as they try to deliver better products and services to their customers.

I also went through the blog archive and found several old posts that appear trivial and hardly useful to a visitor today. Some of them contained advice that I would not give today based on what I learned in the several years since. I deleted them! I also found several posts that touched upon important topics that were developed further since I wrote them. They deserve a proper follow-up and to be updated with the fresh facts and stories.

I also realized there is a scattering of comments and answers I posted on various media throughout the year. Somebody posted a question or a statement, I replied or commented, and somebody found that useful. Lessons from the past (LinkedIn Answers, StackOverflow and such) suggest that such content should eventually get a permanent home. And what better home for it than a personal blog.

Such are my blogging plans for the new year. Stay tuned!

Posted in Blogging | Tagged | Leave a comment

Cycle Time Revisited

The cycle time has been a hot topic for me lately. A debate is going on on kanbandev.

Meanwhile, someone at a client site has asked my advice on continuous delivery (of software) and whether “the cycle time” is a useful metric for it based on some article they found somewhere on the Internet and read over the weekend. The article was written purely at the practice level, without context and the author assumed whatever cycle time meant to them was “the cycle time” and didn’t bother with any definitions. That was a lot to sort out.

There is no such thing as “the cycle time”

It is an overloaded term and its uses should always be qualified.

In the manufacturing domain, where there is a stable definition of cycle time and where the term can be used without qualifiers, it means something very different from how the author used the term. It means the (average) interval between successive deliveries. For example, if the cycle time of a car assembly line is 45 seconds that means, on average, every 45 seconds a new car rolls off (actually, at nearly perfect 45-second intervals, because there is very little variability in the manufacturing process). A total of 60 * 60 / 45 = 80 cars are produced every hour. (Note that the lead time to manufacture a car is significantly longer than 45 seconds.)

If we’re to adopt this definition in the software development domain, the cycle time means the reciprocal of the deployment frequency. For example, if a team demoes their user stories every two weeks, but actually ships only after multiple increments are integrated into a six- month release plan, then their cycle time is 6 months. If they ship at the end of every sprint, then their cycle time is 2 weeks. If they deploy 50 times a day on average, their average cycle time is approximately 29 minutes. The average cycle time of the software delivery process at Amazon is reportedly 11 seconds.

The Software G-Forces

Kent Beck, one of the eXtreme Programming pioneers, proposed a model called the Software G-Forces. He showed the scale of deployment frequencies (cycle times), from yearly to quarterly to monthly to weekly to daily to hourly or less. He also showed how the distribution of where software companies fit on this scale changed over time. There are no best practices for delivery. Whatever the practices you’ve got are the right practices for delivering at the frequency you’ve got.

Speaking in terms of delivery frequency also avoids the terminological overload of “cycle time.”

Cycle time and continuous delivery

Beck further contends that if you want to double or triple your frequency, doing so will likely break your existing process. You have to figure out which new practices to add to your process and which practices to part with. Addition and subtraction of practices will always be contextual. For example:

  1. Delivering once in 6 months may involve little test automation, but, if you want to deliver every 2-3 months, you will probably need to invest in test automation. The full manual regression test may take too long.
  2. Going from once every few months to once every few weeks is likely to require automated provisioning of various testing, staging, certification and production environments. “Snowflake” servers may stand in the way.
  3. Delivering once a two-week sprint or more frequently generally requires a properly designed, unit-testable code base with good amount of unit test coverage. Are all developers fluent in SOLID principles? There will be no trivial bugs for testers to catch – are they trained in exploratory testing?
  4. Delivering more frequently than once a week tends to break processes based on time-boxed frameworks.
  5. To deliver more than once a day, you may need to solve the bottlenecks in your deployment pipeline.
  6. And so on – you can easily turn this into a very long checklist of practices.

What about local cycle times?

Other uses of “cycle time” are possible in the software domain, but they all mean the time through a local activity (or a continuous sequence of activities) and all need to be qualified where they’re from and to (something the author neglected to do). As it turned out upon careful examination of the article still influencing my client, its author didn’t mean any of the above definitions. He meant the time from the code commit to seeing it in production. It was the local cycle time of the deployment pipeline. (In the Kanban method terminology, his clock started at the second commitment point.)

By optimizing the local cycle time of the deployment pipeline, the author was effectively solving the Problem #5 from the long list above. This immediately raised the question whether the Problem #5 was contextually relevant to my client. (The answer was, without giving away anything: to some teams, yes; to other teams, no.)

Conclusion

Back to the original question: is “the cycle time” useful metric to inform progress towards continuous delivery? Generally speaking, no, unless we can all agree on the definition, which is clearly not happening.

Meanwhile, using the delivery frequency can be much more productive you can avoid using it to rank your teams. Team A delivers once a month; Team B, once a day. Is Team B better than Team A? No. Is Team B working on what it will take to deliver three times a day? No, they’re just cranking out user stories? If so, that’s not so good. Is Team A working on what it will take to delivery every two weeks? If yes, great!

If you’re still looking for a best practice from this memo, here it is. It’s okay to deliver only twice a year out of a legacy codebase with mostly manual testing. It’s not OK to say, when we’ll rewrite this codebase in a few years, it will be more conducive to deployments at the end of each sprint. It is also not OK to say, we’re deploying every day and are far ahead of those dinosaurs and their twice-a-year deployments. Instead, it may be preferable that each team have a goal to deploy 2-3 times more frequently than they do now. The leaders can communicate and set such expectations with the teams.

Posted in Uncategorized | Tagged , , | 2 Comments

Introducing the STATIK Canvas

Update (2018)

For the up-to-date version of this STATIK A3 paper, please see this more recent post. You can also download the paper from my firm’s website.

The Original Post (largely relevant still)

I’d like to introduce a new simple tool, the STATIK canvas. STATIK is an acronym that refers to the Systems Thinking Approach to Introducing Kanban in Your Technology Business.

Kanban (in the knowledge work context) is an evolutionary improvement method. It uses virtual Kanban systems as a way to catalyze improvement and adaptive capabilities. A Kanban system is introduced into the environment which comprises the service delivery team and its customers and partners. This is a critical moment. Systems thinking is key!

It is not the goal of this post to explain STATIK, it is rather to introduce the canvas and let people download and try it. Therefore I’ll skip this explanation and encourage the readers to explore the key STATIK resources:

Instructions

The proposed STATIK canvas is roughly the size of an A3 paper. It is intended to be filled in by pencil and capture only the most important stuff. The following are instructions by section.

1. Context for Change

This section captures the internal and external (from customer’s perspective) sources of dissatisfaction and variability. Stories collected in this section often contain words that reveal work item types, hidden risk information, odd patterns of demand, unmet expectations (used in Section 2 – Demand Analysis), external and specialist dependencies (Section 3 – Workflow Mapping), implicit classes of service (Section 4).

2. Demand Analysis

This section contains the demand analysis template introduced by Dave White. The following information is collected for each work item type:

  1. Source – where the requests to deliver this type of work item arrive from
  2. Destination – where the results of work are delivered to
  3. Arrival rate. This must be a number of requests per unit of time. (“We have 300 items in the backlog” is not good enough. If you get this answer, ask where they come from and how.)
  4. Nature of Demand – note any patterns.
  5. Customer’s delivery expectations, even if unreasonable.

3. Workflow Mapping

Map the workflow for each work item type. Note the similarities and variations. Pay attention to concurrent and unordered activities, too. Note external dependencies, specialist risks, etc.

4. Classes of Service

For each work item type, specify which class(es) of service are being provided, their policies and delivery expectations.

5. Input and Output Cadences

Specify them for every work item type.

6. Kanban Board Visualization Design

This section is intended to be a simple sketch helping the delivery team, manager and coach figure out the major outlines of the visual board. These may include swim lanes, two-tier structure, use of colour, etc. There should not be any need to make this section a miniature replica of the actual board.

Learning

Here is a number of things I hope to learn by trying out this canvas. I expect its design to improve as a result.

  • Whether the canvas is helpful to capture the thinking process of introducing (or updating the design of) a Kanban system
  • Whether it is helpful to hang the canvas near the Kanban board to help remember why certain visual Kanban board elements are the way they are
  • The relative proportions of the sections
  • Level of detail or instructions needed in each section
  • Whether the “Roll Out” section belongs in the canvas
  • Any surprises, things I don’t expect to learn
Posted in Kanban | Tagged , , , | 6 Comments