Interesting Trends surfacing at Agile Israel 2015

My “Trends Keynote” is becoming a repeating feature of the Agile Israel conference. This year I chose to involve the audience by using a Kahoot survey combined with some insights that we (AgileSparks) have seen throughout the year.

First of all it was very cool to see more than 300 participants in the survey (out of ~600 in the audience). Kudos to Kahoot as well as the Israeli 3G network for surviving this onslaught :-)

Some interesting patterns/trends that are worth sharing:

The average agile experience among the participants was 2.4 years (with a healthy spread throughout the novice-expert range)

The time has come for the Agile Boost?


The majority of participants considered themselves to be already running some stable form of Agility (what we call Stable/Recharge) and the almost 40% of them considered themselves to be in the Improve/Boost zone – meaning they were looking to extend the benefits/depth of their agility.

60% actually said this was why they came to the conference – to find ways to Boost their agility and see how others have been doing it. There was still a healthy representation for people looking to learn how to lift-off towards agile as well as how to stabilize their new agile way of working.

The Glass Ceiling

The vast majority acknowledged there was a glass ceiling to their agility. Half could point out the specific glass ceiling and half couldn’t say exactly what was blocking them. Management Culture was pointed out as the main glass ceiling – Structure, Legacy Technical Practices/Tools and Real Customer Collaboration didn’t get nearly as many votes here. There’s a chance that this vote was influenced by David Marquett’s keynote which preceded my talk…

The Scaling Landscape – Only in Israel…

The majority of participants were working on agile groups of around 30-100 people.

When asked what Scaling approach they were using the majority actually voted “E2E flow using Kanban” with “SAFe or similar” coming in second and “Spotify style” coming in third a bit above “LeSS or similar”. This was a surprise but as I mentioned in the talk, Israel is probably one of the only places in the world where such an answer is even possible. And having many conference participants from one of the largest Enterprise Kanban implementations world-wide didn’t hurt either…

Preferred agile approach at the team level – A Usual Suspect with a strong contender…

Going down to the team level the results were more typical – around 56% said they were using mostly Scrum. 25% mostly ScrumBan and just 13% mostly Kanban. This is more or less what we’re seeing with clients that we’re helping. Scrum is still the mainstream but most of our new or boost engagements are either starting with or switching to ScrumBan these days.

Agile and Engagement/Motivation

When asked what was the impact on the level of employee engagement/motivation most said agile either helped or they weren’t sure about the impact. The reason we asked this question is because we’re seeing more and more interest in the humane aspects of agile and we love to work with organizations that care about these aspects. We also see a great connection between engagement/motivation and areas like Sustainable Pace, Technical Safety, Purpose/Mission and of course Decentralized Control/Autonomy. We even have our own modern take on Maslow’s hierarchy of needs to reflect that…


So – how different are those trends from what you’re seeing in your region?
If you’re interested to have a deeper discussion about these trends and others, you can leave a comment here as well.

PS If you’re interested in the presentations and videos from the conference – they are now available. Note that while all of the slide decks were in English some of the recorded talks were in Hebrew…


Agile New England Meetup on July 14th in Boston – Lean, Agile, DevOps, Flow, Enterprise Kanban – What’s the connection and how do they all fit together?

Agile New England and the Boston Limited WIP Society invited me to give a talk on my next visit to Boston. The SES group in Siemens PLM (my client… ) graciously agreed to host the talk in their facility in Waltham on July 14th afternoon.

I decided to talk about Lean, Agile, DevOps, Flow, Enterprise Kanban – What’s the connection and how do they all fit together? 

Looking forward to interesting discussions with Lean/Agile/DevOps folks from Boston metro area and New England in general…

Agile New England


DevOps/Flow and Agile Boost Camp workshops coming to Boston this July…

As astute readers are aware I’ve been coming over to Boston every couple of weeks the last couple of months to work with a client.

This time around on July 16-17th I’m bringing with me two of our hottest AgileSparks workshops: (Update: We’ll take a rain check until the fall… in the meantime subscribe to the blog mailing list or send me an email if you want to be notified about new dates)


The DevOps/Flow workshop which helps people understand what DevOps REALLY is about (hint – not just tools, and for sure not the name of a new team…)

Boosting Your Agility

The Agile Boost Camp (a.k.a ABC) which is a dynamic agile-driven workshop where we basically pick and choose from a set of agile challenges I bring and the participants add to and then explore various approaches for dealing with those challenges – sharing a lot from our enterprise agile experience as well as trying to apply building blocks to come up with new possible experiments you might try to deal with a unique new challenge. See a recent blog post summarizing an ABC class.

There are also discussions about a meetup of sorts with one of the New England/Boston agile groups on the 14th. I  will of course let blog readers know as details emerge.

So if you’re either interested to really explore DevOps or boost/reboot your agility, let me know by leaving a comment or subscribe to the mailing list to get notified when we are opening them.


A Minimally Valuable Agile Mindset (a.k.a Agile Mindset is more than one thing…)

Stickiness comes with Mindset

Today in our morning call the AgileSparks coaching team discussed what are some indications that a company/group has reached a stable level that they will continue to at least sustain and ideally improve from (which means we can sleep well at night knowing our mutual efforts are not going down the drain)

One of the indicators raised by my fellows was that everybody in the organization and especially the leaders are not just operating mechanically but also have an agile mindset and their de-facto decisions/actions show it. Examples that came up included “Letting Go/Stepping Back”, “Trusting the Team to pull”.

An Iterative/agile approach towards an Agile Mindset – It is NOT All or nothing

This brought up a discussion where I played the Devil’s advocate (Oh well, I didn’t play it) – saying it was a problematic indicator. Why? Isn’t agile mindset great? Yes it is. And examples such as the ones raises as well as “Fail Fast”, “Inspect and Adapt”, “Iterate”, “Accept incomplete information”, “Stop Starting Start Finishing”, “Treat inventory as waste”, “We can improve/grow” (a.k.a the agile/growth mindset) can all drive great decisions/actions.

My problem was with the position that all of these are required as part of a sustainable level. They portray a pretty ideal reality, but not necessarily what the organization/group chose as the goal of the transformation step we helped them go through. Some organizations will buy into the full monty and some will choose to break a waterfall process without moving to a real agile self-organization/decentralized control process. And for the latter ones just achieving a reasonable iterative flow of work can be a good stable/sticky level to grow from. Or they can aim for a reasonable level of cross-functional multi-disciplinary teams and the mindset that working together across silos is key to success in uncertain/complex environments. Or focus on decentralized control/self-organization. The focus can vary from organization to organization based on their pains/opportunities, their starting point and the transformation pace they choose to go for.

Mechanics vs Mindset

Many people are breaking Agile into Process and Mindset. I prefer to look at it as different areas where for each area you can go through the motions mechanically (Shu-level?) or at a higher level also have the Mindset to help guide you and sustain your strength during tough patches.

Said differently – It is not Process (Iterations, Commitment, Ceremonies) vs Mindset, It is different areas of potential agile value where for each there is the combination of Process, Structure, Mindset that together works to improve the way you work now and into the future.

Define the Mindset you aim for

Therefore, when you plan for an agile change/transformation (and probably any other change as well) make sure you are clear and aligned on which aspects of the change you’re seeking and what would be good acceptance tests to check where you are in terms of Process, Structure AND Mindset in that area.

Also when you talk about “Mindset” – qualify what “Mindset” you mean. This will also help you call for more concrete action/behavior and not expecting a religious like abstract approach to things.

I Hope this makes sense…. I’m already working on a follow-up post that will connect this concept with our approach to lean/agile depth assessment. Here’s a preview picture…1-mindset and mechanics spider




Flow-driven Product Development webinar w/ LeanKit

What a week. A full exhilarating week in Boston working with a product development group which I’ve been helping the last couple of months. They recently formed into 7 kanban teams and after a Management Workshop and a Team Kickstart week this was a visit to see where they got. We worked on team dynamics, change management, WIP Limits, Flow, established a health dashboard inspired by Spotify’s Squad Health Check, and even played a cool Kahoot in that spirit. More later…

It was kind of fitting that interspersed into all of that were two runs of a Flow-driven Product Development webinar as part of the LeanKit Webinar series.  The webinar summary and recording are now available. The Prezi itself is also available here.

PS a lot of interesting questions were raised in the webinar. If you want to get answers on them, let me know and will figure out the right approach. Considering an “Ask me Anything” follow-on webinar or just a couple of blog posts or both.



Flow-driven Product Development – Upcoming webinar w/ LeanKit

LeanKit asked me to host a webinar for their highly popular webinar series. I naturally accepted. And it was also just natural that the topic would be Kanban/Flow in Product Development as I have the privilege to be one of the people involved in using kanban in multiple enterprise-scale product development lean/agile initiatives the last couple of years, several of whom are enjoying LeanKit.

In this webinar I will focus at the group/program-level scale and present a kanban/flow scaling pattern which most of these clients have been using.

Note we’re hosting the webinar in two time zones to accommodate a global audience so regardless of where you live (with Australia/New Zealand as the possible exception, sorry guys) you should have a reasonable time to join us. We also plan some time for questions so if you have a question for me on this topic, now’s your chance…

See you there

PS As a side note I’ll actually deliver the webinar from Boston while working with a customer (an Enterprise Kanban Product Development customer – actually a sister unit of one of the case studies I will present).


DevOps and Lean in legacy environments – Continuous Discussions webinar

Last week, I enjoyed participating in an online panel on Devops and lean in legacy environments as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and Devops.

The discussion centered on if and how “horses”, legacy environments originally based on waterfall/ITIL, can become “unicorns” with advanced Devops-Agile practices. Questions asked included how to “inject” DevOps and Lean principles across multiple legacy product teams with different technology stacks; how to enable experimentation in legacy environments; and what differences panelists have seen in their production pipelines. Check out a full recording of the panel here:

Continuous Discussions is a community initiative by Electric Cloud, which I’ve been aware of for ages as a strong build automation and optimization tool and apparently has made the smart move of strongly supporting the DevOps movement both by providing test & deployment tools as well as being involved in the community.

Below are a few insights from my contribution to the panel:

How do you make the move from an ITIL/waterfall to an Agile/DevOps perspective in legacy environments?

“I think it’s not a technology issue. 22 years back, we were working with a mainframe in a mission critical places in the Israeli army and we were doing DevOps, deploying every week, dev and operations were talking closely to each other. Those Cobol guys knew how to do Devops, it’s not a technology issue. We didn’t really know about waterfall until we started to do client server projects and something got messed up”. I’ve actually been saying this for a while now. It’s like a pendulum where once upon a time the developer didn’t rely on ops people or testers.

“But today I see that the urge to go to Devops and Agile, at least for systems of innovation, is that people really want to do it, just not sure exactly how to go about it. Culture is not a thing you can implement, tools are something you can implement, but it’s not clear what kinds of tools would be the first to invest in. My approach is to look at things from a flow perspective, get people to look at end-to-end process or value stream from need to production, and see where things get stuck, where there is slow feedbacks, big batches, etc.”

“We show them how to visualize their process using Kanbans or flow diagrams, to get a picture of what is going on in the system, what are the bottlenecks. And when they become aware of those bottlenecks, a concept which is interesting for many people is a combination of different types of costs. Everyone is optimizing for lower overhead and transaction costs. The cost of releasing is high, so people try to release less often, because that will reduce the overhead of releasing. They’re not aware of the cost of delayed feedback or missing time to market.” Classic Reinertsen. Somebody had to represent his Lean Product Development thinking on that panel. Only natural it would be me I guess…

“Only when people start to combine those two costs they understand that maybe a tool that can help reduce transaction cost does have an ROI. The return comes from getting earlier feedback if you have problems in production, or learning whether this innovative feature is in the right direction, and it saves a lot of time later on.”

“It’s kind of trivial at small companies, but at big companies, we see examples such as one company that have been working on their CI for two years, investing millions of dollars going from monolith system that takes days across multiple applications, and now they’re close to CI for some fixed configurations. They’re still working on it. Getting to CD or automating the deployment pipeline is going to take a lot of time they need a lot of clear ROI for it.”

How do you promote experimentation in legacy environments?

“We promote using the language of experimentation whenever you talk about things. Start talking about experiments, MVPs, not just in the product area. At another one of our clients, a household-name enterprise, top managers started to ask people, what’s the experiment here? Can we try to experiment with something?”

“Another aspect is they started calling their business units “startups” – that’s another thing that nurtures entrepreneurial thinking, even in such a large organization – startups report to division leads and in their reporting dashboard, the way they measure of agility is to show the rate of experimentation. They don’t just talk about velocity of output, but also velocity of experiments, velocity of MVPs, whatever it is that they can get out there no matter the size. They can try as small an experiment as they want, the number of experiments they tried is something management talks about and asks about.

“Another thing they talk about is not product experimentation but process experimentation, which is important as well. Let’s make sure we experiment with how we work, retrospectives, can we try to do things differently? In each of these fields, product and process, management is interested in how much experimentation happens and that makes experimentation happen.”

Overall it was an interesting discussion. Hopefully the audience got some good ideas and pointers out of it. Looking forward to participating in another webinar in the future.

On the topic of webinars, I’ll be giving a LeanKit webinar about Flow-driven product development next week. See you there.


Agile Boost Camp Workshop

I just finished facilitating an “Agile Boost Camp”, a new AgileSparks workshop. In this workshop we run a truly agile-style 2 days where the participants pick and choose topics they want to address. We adjust the plan along the way, we ran short timeboxed Pomodoro style sprints and consider next steps after each.

After starting with a cocktail party where the participants pondered a long list of options and a lovely discussion about our options for release planning the two days (plan everything, plan each half day, continuous pull based planning while setting some baseline expectation about the number of topics we want to cover) we started going through some items, adjusting priorities and number of Pomodoro sprints per item along the way.

  • How to deal with infrastructure/shared teams – Both how to more effectively manage the flow in/out of the teams in a way that reduces the management/coordination pain and enables a more agile/pull based planning as well as how to reduce the cases where these teams need to be involved by enabling other teams to self-serve themselves.

shared resource load flow

  • Scrum-Fall – waterfallish big batch activities within the sprint and how to deal with them
  • How to enjoy benefits of agile development while living under the constraints of a waterfall/gated program/organization as well as how to break out of the overall waterfall towards business agility – and how to appeal to the concerns/risks from the perspective of Executives/Clients/Sales in such a move.
  • Tips/Tricks for Effective Agile Change Management in both an organizational as well as a team context.
  • How to energize people and teams in an agile context – both towards short-term goals as well as in the long-run

It is interesting to look at some of the interesting concrete takeaways/epiphanies people took as well:

  • Limit # of Work items in Process as well as their SIZE
  • Use an agile approach to implement agile – try, experiment, change
  •  Infra/Shared teams can enable other teams using a delegation model. We took some inspiration from Spotify’s Self-Serve squads model.
  • Release Planning – stop focusing on the small details, just start doing based on a high level plan
  • In order to effectively track an agile release  a few charts can give you a great picture – Feature status (with how many stories are done and in each other relevant life cycle state), Stories CFD, Features level CFD. (A nice tool we looked at that can help you dive deeper into your analytics and generate some actionable insights is ActionableAgile Analytics by our friend Daniel Vacanti)
  • The change resistance matrix (Overcoming resistance to change movie by Goldratt) – helps you prepare better for how to drive change, think about the different people and how they see the change. (we also discussed Speed Boat as a nice exercise to explore Strengths and Weaknesses of current reality). Fearless Change Patterns was another great resource we discussed. (I’m SO excited to have Linda Rising as our keynote this year in Agile Israel 2015!)
  • The importance of a good spread/flow of the PBIs/Stories throughout the sprint (to avoid the Scrum-Fall problems) and the power of Kanban/CFD/Limited WIP to help you identify and deal with the causes for Scrum-Fall.

  • Interesting to consider the cocktail party approach to planning presented by Chris Matts (Skype case study)
  • Fair Process – try to involve as many as possible in order to have better engagement/commitment rather than just compliance. We mentioned Delegation Poker by Jurgen Appelo as one way to explore how fair your process is and work on shifting it to a fairer level.
  • Virginia Satir’s J-Curve change model shows that in order to achieve change, there is almost always a costly learning curve (Investment and time is required before Return)


  • Commitment/Stretch as a way to manage the Waterfall/Agile interface more effectively. (We looked at Henrik Kniberg’s Agile Product Ownership in a nutshell section about managing expectations as inspiration for this)
  • Avoid starting all the features (MFs/MMFs) in parallel – keep as many items NOT STARTED as options for changes towards later in the release
  • When you have teams that can only deal with parts of the release backlog you need to monitor their progress/status and not just the overall status/progress (While expecting them to work hard to enable other teams to also work on their area)
  • Bank of Trust – learn how to create a positive balance with the team so that when you need something from them they will trust you. (Inspired by Speed of Trust)
  • Use Pairing in the right situations to improve versatility
  • Technical Safety as something we should start to evaluate in order to keep people healthy, happy and motivated. (Part of the new hierarchy of needs inspired by Maslow+Pink+Kerievsky). Another interesting way to show people/teams you care about their happiness/health as well as learn what to focus on improving is the Spotify Squad Health Check Model. Obviously we watched Lucy’s famous chocolate scene to introduce the topic of Unsustainable Pace and discussed my motivation-oriented retrospective approach



  • Start measuring historically to enable planning more predictably
  • Stacey Matrix – Uncertainty Matrix of Biz/Req/Tech – Explains why we do MMFs and why we do PBIs/Stories (See my post about Risk-aware Product Development)


  • We also discussed the #NoEstimates movement and the less extreme  option of stopping estimation at the stories/sprint level and moving to planning/predictability based on actual story count velocity while estimating bigger features as part of agile release planning or ROI discussion. Ideally by relatively estimating the number of stories a feature will turn out to include WITHOUT slicing it down to those stories first.
  • On the topic of relative estimation Team Estimation game is a great alternative/complementary approach to Planning Poker (See a great exercise to learn about the different approaches and good description of the team estimation game). When you do want to use planning poker remotely Hat.Jit.Su is a nice option. We re-emphasized that mature agile teams use this mainly for feature-level longer term planning rather than the sprint.
  •  change battlefield mapping can help you better prepare and manage any kind of change, including but not limited to driving changes in and around your agile team or championing an agile change initiative across a big organization.


  • Remaining task burndowns. Don’t do them. And people telling scrummers to use remaining effort sprint burndowns? Somebody should take away their license. Use stories done instead. That’s an indication of working tested software. Prefer Burnups to burndowns as they give you a better picture of changes in scope and are an easier starting point for moving to the real flow management chart – the CFD (Cumulative Flow Diagram).
  • Obviously Reinertsen’s Batch Size U-Curve made an appearance as well in the discussion about waterfallish processes and the change management around them.

Of course we also watched a couple of other short videos and looked at some stuff from the AgileSparks resource library

I’m still analyzing the feedback but so far it seems it is quite a hit (the word amazing got repeated several times in the feedback surveys we collected), with a strongly positive Net Promoter Score and comments like “We should repeat this workshop every couple of months as it allows us to keep boosting from where we are” and “finally an agile workshop which brings the theory down to earth and helps us understand what practical steps we can take to address our issues”.

Sounds interesting? Let me know and you can join the next public class or bring this into your organization. I had lots of fun and would love to repeat this as often as possible… I’m already interested to see what topics will be of interest to the next group…

PS Thank you Sagi and Ben (Coaches on the AgileSparks team)  for scribing the workshop, taking photos and sketching some of the concepts in real time.

The synergies of Kanban & DevOps

I believe Kanban and REAL DevOps are a match made in heaven. I really do. I know I’m not the only one. Leading into Agile India 2015 InfoQ interviewed me about this. This was also one of the main themes of my talk in the conference and the DevOps Flow workshop I gave before the conference. (Contact me if you’re interested to hear about the next opportunity to participate in such a workshop).

While we’re waiting for the video from my talk to be processed, here’s a trailer…


And an older variant of this talk from DevOpsDays Israel:


Risk-aware Product Development (a.k.a. Agile)

“There’s no predictability/commitment in Agile”

Over the years I’ve heard my share of these kinds of statements from various levels of executives:

“When my guys run a product development release I really want to know what I will get at the end so I can make business plans accordingly”

“In the old days when we ran projects we knew the timeline, we knew the scope, there were no surprises. These days it seems like the inmates are running the asylum. Product Management keeps telling me in this Agile way of doing things there is no committed scope, no plan, only ‘Responding to change’. I can’t help but think they are using it as an excuse for thinking short-term”

“When an important new/existing customer asks for a feature I really want to know whether I can commit to him that it will be delivered in the next release so I can get him to commit to a purchase”

“When you talk to people here, I want you to be very clear on the fact that agile will not take away the predictability they have so that they will not oppose the agile initiative we are trying to kick off”

This post is dedicated to you guys out there trying to make sense of the confusion surrounding predictability and Agile (Or as I often refer to it these days Risk-aware Product Development), whether you consider yourself one of the people quoted above or one of the people working for them trying to bridge the desire to work in an agile nirvana-like flow and dealing with those pesky executives stakeholders and customers bent on interrupting that flow.

Back to the roots

Let’s make it clear up front. I totally empathize with these executives. They are either already victims of “Bad Agile” or are basing their concerns off of a lot of “Bad Agile” going on out there. It is such a shame though because in reality agile product development actually maximizes the predictability you can have in your environment. Wait, That was a complex sentence. Why didn’t I just say “Agile provides great predictability” and get it over with? Because that won’t actually be true…

Let’s start from the beginning. Let’s talk about the contexts where agile approaches are required. One of the first things I discuss with executives is the concept of uncertainty and specifically Stacey’s Uncertainty Matrix.


Types of Uncertainty in Product Development

I explain the concept of Requirement/Business uncertainty as the chance that you are aiming at the wrong target and Technology uncertainty as the chance that you’ll have execution problems getting there. I then ask the people in the room to classify the projects they are currently working on and typically get a picture somewhat like the one above with different projects having different uncertainty profiles. At this point it is typically easy to get to the understanding that when you have low uncertainty predictability and success is a matter of careful and disciplined execution of greatly crafted plans.

Dealing with Technology Uncertainty – The Waterfall Passive/Buffered Risk Management Style

When uncertainty starts to mount, it is a different ballgame. Teams facing technology uncertainty with big batch waterfallish approaches only get REAL predictability (meaning the one that stays valid all the way through release of high quality product with the committed scope) through huge buffers.These buffers serve to hide those horrible big bang integration hells that are the source of statements like “We are totally on track all the way through development but when we reach the code freeze period all hell breaks loose and we don’t trust a word we’re told about when the product will be released”.

Dealing with Technology Uncertainty – The Agile Active Risk Management Style

Agile teams in this context should be able to provide predictability by weighing the amount of effort required to achieve the business expected outcome, taking into account the amount of uncertainty, and make some buffered plans at the high level before going into low-level iterative product development aimed towards achieving those high-level commitments. You not only get predictability of “If we said we will deliver this feature in this release then that is what we will do” you also get visibility of progress towards meeting that commitment by seeing working product frequently and getting reports based on real integrated progress.


Dealing with Requirements/Business Uncertainty

Here, definition of success is actually a bit different than what executives are used to. Success doesn’t necessarily mean delivering according to commitments. It means hitting the target if it is indeed a real target and alternatively learning as quickly and cheaply as possible if we are aiming at the wrong target. This is not some theory we’re talking about. Data from more than 50,000 projects suggests 50% of features developed are actually not used. (See Chaos Report 2013).

Is Predictability what we want?

So aiming at the right target is not a trivial task in Product Development, especially if you are in a more innovative space where it is not even clear that there is a market need for your product, but also when you are working on internal IT projects where this kind of uncertainty seems irrelevant… In the Lean Startup movement we typically talk about the “Build it and they will come” fallacy. Actually we are NOT sure they will come, so we want to be very careful with what we build without knowing. Predictability might be a dangerous thing to wish for in this environment.

The Risk Burndown Exercise


An exercise I often use to get this point across is to ask people in the room to draw a chart of the amount of risk/uncertainty in their projects from initiation all the way to the moment all risk/uncertainty has been exposed. the X axis reflects time or stages in their “Stage-gate process”. The Y axis is “remaining risk/uncertainty” in either the Business/Requirements/Technology domains. One answer I typically get is a line curving up at some point only to go down later on. That is impossible. Risk is there. If the line curves up what you mean is that you actually just become aware of the risk at that point. I guess this is the best indication of the fallacy of “predictability” people have. Others start with the maximum risk and then go down quite quickly – telling me that they learn everything they need to learn at the point of “Requirements/PRD/Design” and from then on it is a matter of execution. I then typically ask whether they find surprises/defects later on in the cycle and whether they actually know all of their features are in use. This typically gets them closer to the epiphany… Others get it by this point and draw a chart where a lot of the risk is there active until you finally get to have your software/product in the hands of real users. At this point the discussion very quickly gets to the main way to reduce the time of active risk – cutting projects/products into smaller pieces so they can get to be “Working product in the hands of users” faster. (Which is by the way one of the key differentiating factors of successful projects regardless of methodology according to the Chaos Report)

A reverse correlation between Business uncertainty and the need for Predictability?

Luckily enough it seems like Predictability is typically required when there is a strong business need on the other end of the line (if there is a partner/customer adamant on having that feature it kind of reduces the business uncertainty of whether it is a real need…). So effective classification of projects into the right uncertainty/predictability profiles will typically help satisfy the business executives without creating unrealistic expectations from the product development group. There’s still the need to understand you are sometimes running small “startups” or “venture capital” inside your product development portfolio, which might be tough for an execution-oriented IT/product development executive to fathom. Geoffrey Moore talks a lot about these kinds of struggles in “Escape Velocity”. Which is highly recommended reading by the way.


So, with all this in mind, what can you do?

My advice to executives is to make sure they and their teams understand the uncertainty profile of each of their projects and act accordingly:

  • When uncertainty is low, use whatever kind of process to deliver the desired outcomes with high predictability.
  • When dealing with technology uncertainty and medium/low requirements uncertainty (Sustaining Innovation) and it is desirable to be predictable, use effective agile release planning approaches to setup a reasonable plan with maneuvering space to account for some requirements/execution uncertainty using either a time or scope buffer (a set of features that are considered stretch / weight to be jettisoned in case of problems).
  • When dealing with serious business uncertainty (Disruptive Product Innovation space?) make sure that a fast iterative approach is used to minimize “building it before knowing whether they will come”. Learning needs to be  emphasized over predictability in these environments.



Don Reinertsen’s Cost of Delay Intuition Exercise – a facilitator’s guide


Don Reinertsen frequently talks about how surprised teams are when they first try to quantify the cost of delay on one of their projects/programs and an exercise he runs to help surface the wide range of intuitive estimates of the cost of delay amongst the team and how a little bit of analysis can help get a much better figure. Inspired by my “Cost of Delay”-themed last week (when I had a hefty amount of Don time spiced up by meeting Joshua Arnold face to face and spending some time with him) I decided to bring the Cost of Delay topic more explicitly into a management thinking workshop I had with a HW/SW Product Development company this week. When I tweeted about the experience it got a couple of retweets as well as a request for more details.

I couldn’t find a canonical description of the exercise so here is a short facilitation guide below. I hope this helps. And again, to be clear, this is just going through what I learned from Donald Reinertsen in the Lean Product Development 2nd Generation workshop last week.

Running the Cost of Delay Intuition Exercise

After spending a bit of time explaining the need and potential for thinking about product development as a flow-based design factory I explained the need to quantify the Cost of Delay in order to be able to effectively weigh the tradeoff of things like Holding Cost and Transaction cost when deciding upon Batch Size. I mentioned Don’s results when asking teams what would be the Cost of a 1-month Delay on one of their programs and asked them if they want to try that exercise themselves. They were quite enthusiastic to try.

We chose a relatively big project in their portfolio. We had the finance people in the room so it was easy to get the projected total life-cycle profit for that project which was
around 16M$. I then made sure we all understand the scenario – the product will be delivered and available for the customers to integrate one month later than originally planned for.I DIDN’T hold any discussion with them about profit curves over time etc. since I wanted them to think fresh of their own assumptions.

I then asked each participant to think what the impact would be on the total life-cycle profit and write the answer to himself without sharing or consulting with his peers. We then collected the results by doing a round-robin poll of the group. The range was 0-16M$ (How’s that for a wide range???) with most answers ranging between 15

0K and 2M$. So even ruling out the 0 the range was 1-100. At that point we asked some of the extremes to explain their assumptions and way of thinking and I drew some accumulated cost of delay  curves to help picture the different alternatives.

After a bit of discussion it became clear that the 16M$ was based on a “lose the opportunity window entirely” which can happen if you’re aiming for a big design win without any other market opportunities for that product (Think aiming to deliver the iPhone display and delivering late… ). This came from one of the senior guys in the room. The other extreme of zero impact basically assumed that the sales/evaluations ramp-up was slow anyhow and they could make do with hand-waving and expectations management to avoid losing any deals due to the delay. The finance and product management people estimated the number to be around 1-2M$.


That was it. The exercise took around 15-30 minutes I believe and was well worth the time. In the retrospective at the end of the two days Cost of Delay was mentioned as one of the A-Ha moments. I found that having this discussion was also a great way for me to gain insight into their ecosystem and way of working. It surfaced issues around customer expectations and interfaces very quickly.

I’m glad I used this exercise and will probably use it often moving forward.

Addressing some myths and misconceptions people have when considering Kanban

I frequently get contacted by people who like Kanban in general but are worried that it might not be a good fit for their context. In some cases the concern is legit but in many others it is just a result of basic misunderstanding of Kanban. We need to figure out why this happens so often but in the meantime here is a short FAQ:

Q: Is Kanban just for ongoing maintenance or also complex product development?

A: Short answer – No. Kanban is applicable in complex product development as well as most other knowledge work contexts.
Longer answer – This myth/misconception is based both on the roots of kanban in the IT world as well as the fact that early on kanban was quite popular in teams that did ongoing maintenance/support where scrum sprint-based planning wasn’t a good fit. It was so popular that a lot of people made the association that kanban should be limited to this use case. (Scrum people who tried to protect their turf didn’t mind so much and probably helped this misconception propagate). As a coach actually most of the teams/organizations I work with use Kanban for complex enterprise-level product development involving SW and sometimes even embedded/HW development.

Q: We heard estimates are not used in Kanban? How is it possible to plan and predict then? (also asked as “We heard it is forbidden to estimate in Kanban?”)
A: Short answer – you can use estimates with Kanban and many teams do that.
Longer answer – Actually Kanban says to start with what you’re currently doing and evolve over time so many teams/organizations continue with their legacy estimation approaches initially. The source of this legitimate question is the understanding in the kanban community that estimates only reflect the work part of the overall delivery time and don’t take into account the delay/queuing time which we learned has a major impact on the overall delivery time. When using SLA-based predictability approaches therefore an accurate effort estimate is not that useful. It is sufficient to ensure the work going into the system is granular. the exact size is not that important.
Having said that, Many kanban teams/programs use  a more classic bigger-batch planning approach like “Agile Release Planning” and in those cases some sort of estimate is useful in order to have a prediction of the Time/Scope/Capacity required to deliver the Release/Project. These teams typically use classic agile estimation approaches like Story Points, Ideal Days etc.
Q: How do we deal with dependencies in Kanban?
A: The answer is not Kanban-specific but more of a “Feature Driven Development” question. The answer is that when moving to a Feature-driven-development approach using good independent stories/features most dependencies go into the specific cards themselves. The remaining dependencies are typically “This story must be finished before that one” and reflecting those cases in the priority order can be enough. Some teams block cards that are dependent to give better visibility to the situation. And some tools even provide a dependency mapping capability. I have to admit though that while I hear this question often from people coming over from the waterfall task-based gantt-based world, once they go into feature-driven/story-driven world most of them just understand they don’t need anything special.
Q: Are same sized stories really a must in Kanban?
A: Short answer: NO.
Longer answer: Kanban actually lives quite well with variable-sized work items. Most teams I worked with have not reached the nirvana where their stories are the same size and even those teams that have are working on features that vary in size. Kanban cares more about making sure the work is granular so it can flow effectively than having same-sized work items. The main advantage of same-sized work items is that it simplifies prediction, analytics etc. But most tools and teams deal fine with variability in the work size by taking size into account when making their prediction (e.g. in their CFD) or their analytics (e.g. in a size-based cycle time control chart)
I hope this helps…

How to limit WIP when you cannot block arriving work requests?

A concern that comes up frequently when you start talking about applying a WIP limit is:

“So, what I understand from you is that at some point you will block incoming work requests if the WIP limit is reached, yes? Well, we cannot do that. We cannot tell people we will not work on their items. That will not fly around here”.

I think that is a reasonable concern. In Don Reinertsen’s Lean Product Development workshop this week in Paris (highly recommended btw…) he frequently used the Emergency Room (ER) metaphor. So let’s borrow it.

In my view both the waiting hall and the treatment area are WIP since they both affect the overall service time.

You can apply a limit in at least two ways. The first can be to apply a limit to the overall WIP. Once this limit is reached you will indeed turn away patients. Fans of ER themed TV series will recall episodes where the ER closes shop and turns ambulances and walk-ins to other hospitals. This happens very infrequently though. Their WIP is set to a high level and it is understood that the waiting area might have a very high occupancy leading to very long service times before the situation is so dire that you start blocking people. (A client that attended Don’s workshop with me commented that you might want to invest in stronger security if this happens often as it typically leads to some violence towards staff…)

The second way is to limit “Treatments in Process” to make sure that once patients are in treatment they go through as fast as possible and staff don’t multi-task too much and the treatment area is not too crowded. You will notice this style of WIP limit DOESN’T turn away patients. It accepts them and queues them. Yes the service time might be high if there is a long waiting queue but you will still be serviced. I don’t know what ERs actually do since my personal experience with them is quite limited but I think they either explicitly or implicitly do a mix of both.

To return to our knowledge work environment I advocate using this approach as well.

Yes you should have some WIP limit on your incoming queue. That WIP limit might be high if you want to minimize blocking and prefer to provide long service times. That is probably what the evolutionary resistance-minimizing approach would be.

More importantly I would start with a limit on the actual work in processing. This will achieve a more sustainable and effective processing both for the work as well as for the people doing it. This will also have the effect of reducing the average waiting times and overall service level of your system.

Now, in your environment you might also have a better chance of shaping demand and occasionally blocking work in a way that is acceptable to your clients. But that is a higher maturity level of Kanban. (Klaus would call it a higher flight level) Don’t give up on starting with WIP limits just because you cannot do it early on in your journey or if you think you will not be able to do it even later on.


How to replace the timebox-based motivation when using Kanban/ScrumBan

I recently pointed a customer to a discussion around motivation when using Kanban compared to Scrum and other timebox-driven approaches. This blog post is a slightly edited version of my comments on that discussion, since I find myself getting into similar discussions quite frequently.

The question/context originally posed by Victor on kanbandev was: “We kind of dropped our previous Scrum process (or rather we decided to pay less attention to it because it was becoming less relevant once Kanban was in the picture. But one thing good about Scrum was that developers knew their story was due in 2 weeks so they paced themselves. With our Kanban system their isn’t an end date, so that motivator is gone. Can anyone suggest a replacement or remedy (other than Scrum, I really don’t want to go back)”

Here is my original response more or less verbatim:
When I was starting to advocate Kanban at AgileSparks, we were mostly a group of hard core scrum coaches/trainers, so we saw the sprint deadline and commitment as THE way to ensure high energies and self-organization within constraints and get rid of Parkinson’s law (work fits the container it is given). Over time, we saw that it is A way, and not necessary always the BEST way (due to the reasons quoted below, also see
What we saw through experience with different client environments were that there were some alternative ways:
  • A frequent delivery cadence on its own is typically enough to drive the right level of energies, even without a commitment to finish everything based on a sprint commitment. You can see this described in the case study in the Beyond Agile book.
  • A frequent DEMO cadence can be enough as well, believe it or not! not even delivery… It is sometimes enough to create too much pressure and technical debt, even WITHOUT any commitment to finish a certain package of work. People are motivated to show they are done if there is some opportunity to show and boast it. 
  • Continuous Delivery seems to be even a higher motivator. I’m not working with enough people doing this, but those that do report a kind of rush that creates great motivation to complete things just to see how they perform in real life…
  • Working with small units of value (e.g. Stories), Visualizing and managing flow is many times enough. But only if not, you can consider visualizing and managing “lagging/stale” cards more explicitly. I like for example the “Zombie Cycle Time” approach and talk about it and some of the other issues here in my Lean Kanban Benelux 2011 talk 
  • Purpose – clearly understood real external reason to deliver on a certain time. Whether it is a big deliverable built of many small things – where it is important to see whether you are on track towards that delivery using something like a CFD with release forecasting (trend lines/montecarlo/whatever), or a single value item that has a special delivery requirement. If people are aware of the deadline, realize the cost of delay, and ideally believe in the plan to deliver to that deadline, they will be highly energized.
Since you are coming from a Scrum environment, what seems to work for many teams as a starting point is to keep the cadence only relax the commitment to clear the table as well as to plan ahead exactly what will be the contents of the sprint. This is many times enough. You should look at the actual flow of work and determine whether there is a problem or not.
Regarding talking to the team – I would first try to go to the gemba and see what is going on, before bothering the team with it. If there isn’t a problem, even talking to them might create a Hawthorne effect affecting how they work, and not necessarily in a good way. Depends on the team. Only you know…

Upcoming conferences I’m speaking at – Fall 2014

I’ve been very busy the last few months working with clients and the next months don’t look any better (Not complaining though…). As a result I need to choose very carefully which conferences to attend. As usual, I only go to conferences I’m speaking at. But this year I went even further and dramatically limited the CFPs (Calls for Presentations) I submitted to.

Lean Kanban Central Europe 2014 specifically is a conference I’m skipping despite it being one of my favorite events. But I decided to prioritize for meeting new audiences and communities, and something’s gotta give…



In the Lean Kanban world I’m attending and speaking at Lean Kanban France 2014 which takes place on the 5-6th of November. I was invited to speak there and it will also be an opportunity to see what is going on in the French Lean/Kanban community. The fact that Donald Reinertsen is giving his Applied Principles of Flow workshop that week in Paris and I will finally be able to attend it gives Paris a couple of bonus points… I’ll be speaking about good and bad ways to kickstart agile the kanban way based on our experience doing it in the trenches in the last couple of years.

A totally new territory for me is Velocity EU conference which takes place two weeks later in Barcelona. This conference focuses on the web world – both the technologies and the people/cultural aspects involved in creating great companies/operations shaped to succeed in today’s and tomorrow’s world. Since we are doing more and more work in the Web space at AgileSparks – either with medium-sized startups or with full-scale enterprises we are investing a lot of energies and attention into the DevOps/Continuous Delivery world. I’m going to speak about what we learned about using the Kanban Method as a way towards DevOps especially in the context of legacy enterprises. I’m also looking forward to learning from others and exchanging ideas as well as reconnect a bit to the technology aspects which I left behind ages ago (I did develop Clustering/High Availability/Networking solutions some years ago and was on the Networking/Security Ops side some years before that…).
BTW, If you’re registering to Velocity, use FRIENDSPKR to get a 20% discount. And come say hi when you’re there!

Other than these two conferences I’ll have to track other interesting conferences from afar…

Making Agile Teams work in real life – The quest for Stable Feature Teams?


This post is inspired by ongoing discussions in the AgileSparks team based on our experience trying to help organizations make agile teams work in real life. It is heavily inspired or can even be called a revision of a post from a couple of years ago on the Lean/Kanban approach to teams.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs emerge from self-organizing teams”

Scrum, the most popular framework for implementing agile is quite clear about the topic (Quoting the Scrum Guide 2011)

“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”

The scaled agile frameworks popular today (SAFe, LeSS) also put high value on Scrum Feature Teams. All of this is with good reason.  As Al Shalloway writes Cross functional teams eliminate waste and manifest lean. I fully agree. So where’s the problem?

One of the big problems with cross-functional teams is that they require structure changes. Let’s assume though that we overcame this challenge. We get to the another big issue. As teams spend time together they gel and mature and get a chance to achieve higher performance levels (assuming we are doing the right things to nurture this performance and not kill it, but many have written about it before so let’s leave it aside for now). See for example Tuckman’s stages of group development model.

This is why Scrum recommends stable cross-functional teams. So, again, what’s the problem?

Well, if we have very high staff versatility meaning everyone on the team can do everything and all teams can deal with whatever is on the organizational backlog, we don’t have any problem. We can create stable cross-functional teams and they will just deal with whatever we throw their way (or whatever there is to pull from the backlog when they have capacity for it, if you want to look at it that way…). Very high staff versatility is a great idea. Extreme Programming calls it collective ownership. Others call it “Full Stack developers”. For some reason, I rarely see it in the trenches though. Maybe it is just the contexts I’m working with but the variety of technologies and specializations is such that there are very few “full stack developers” around. And as a networking/kernel specialist in my background I’m not sure I would have liked to spend lots of time coding mobile application UIs or SQL statements for that matter. So the reality we encounter is that of at least some variance of skills.

We can deal with this variability, right? We can simply build the teams in a balanced way that is tuned to what’s coming our way. Each team will take features of a certain “work mix”. Essentially this means we will have a product backlog for each “work mix”. The problem with that is that now we are dictating priorities based on the team structure. Let’s say we built a team that is Server-heavy (3 server guys 1 client) and a team that is Client-heavy (3 client guys 1 server). Both are cross-functional able to deliver end to end features but of a different nature. This constraints our capacity allocation to be 50% Server-heavy features and 50% Client-heavy features. Now what happens if we suddenly need to deal with a big need for features who require same amount of work in client and server? Yes we can force-feed teams this work and expect server guys to work on the client side and client guys to work on the server side, on both teams. Yes, this will be a good investment towards Collective Ownership and versatility. Hopefully it is something these guys will find interesting and useful individually. Hopefully they will feel it is a worthy cause. Hopefully the ramp-up time will not be too long. This picture becomes more complex the more skills we need to work on improving. This leads to many people finding it hard to create stable Scrum teams. They find it creates wastes.

Now, let’s pause for a second. In many cases this is just a symptom of fear of change. The difference between Stable Scrum Teams and Dynamic Scrum Teams can be dramatic from the perspective of management (especially those team/line managers managing people directly). In Dynamic Scrum Teams and surely when continuing to work without Scrum/Feature teams altogether people these team/line managers continue to “control” what is going on. They continue to “own” the people and move them around. They can continue to live in the illusion that their old style of management is the right style of management. The move to Stable Scrum Teams, even if it doesn’t change the formal organizational structure, leaves no room for doubt. The team/line managers are not in the loop of day to day work the same way anymore. They have to do things differently. They need to focus more on attending to the bigger picture, to the capabilities of their professional teams/lines (What Spotify call chapters/guilds and others call Community of Practice/Professionals). So one shouldn’t be surprised that they rationalize however they can the downsides of Stable Scrum Teams. (Thank you Chris Matts for sharing some thoughts about this topic of Staff Liquidity during our Feature Injection chat today).

With this in mind, maybe you are saying, the hell with it, let’s do this change. It is all political change resistance. We need to strongly communicate the need for it, manage the change correctly, sell people on being “full stack developers” and have the patience to deal with the lower productivity while we are investing in our liquidity/versatility. And in many cases this will be the right approach.

Maybe you are talking the “Start with what you have” approach of starting with dynamic cross-functional teams that are created and dissolved on demand with the rationale that it is a smaller change but is still a step in the right direction. And in many cases this will be the right approach as well. A word of caution though – Remember your goal in the long haul though – make sure that you are investing in improving versatility along the way and building the capability for improving the stability of teams without reducing the business flexibility. Invest in management skills and style that is more and more oriented around the “Community of Practice” and “Capability Building” so that managers don’t associate that strongly the “daily allocation” responsibility with their identity as a manager.

And one more thing – Regardless of whether you go to Stable or Dynamic teams but especially if you go for Dynamic – let people finish something before they start something else. Don’t put people on too many teams. Ideally a person should work on one team. There are exceptions. But if you find people are working on too many teams they should either work as a “shared services” team and not as members of all these teams or you need to stop some projects/features and wait until people actually have the attention for them. The fact that the Capacity Allocation Excel can find a way to squeeze that project in with fragments of a Full-time-equivalent to be there supporting it just in the weeks they are needed is a surefire recipe for overloading the system and affecting motivation, quality, velocity and cycle times. Jim Benson’s new book “Why Limit WIP” has a great section (Eldred’s story from chapter 7 onwards if I’m not mistaken) about this BTW. I loved the introduction of Learned Helpness as a result of this situation.


PS Sorry for not providing a clear-cut best practice. But hopefully I gave you some ideas about how to choose the right approach to start with in your context…





Time for feedback – Blog Readers Survey 2014

Amazingly enough, it has been 9 years since I started blogging, and about 5 years since I started blogging as an agile coach at AgileSparks. I think it is about time to hear what the readers think works well on this blog, what can be improved, and how useful it is to them. Retrospective, Inspect & Adapt and all. I’ve been looking at analytics all along trying to figure out what topics hit a nerve with the audience, especially when I curated the “Holy Land Kanban” book. But I never ran a readers survey before. Well – here it is. If you are a blog reader I would highly appreciate your input. And the benefit you might get from it is renewed energies to blog/write more…

PS I tried to keep it short, so it shouldn’t take you more than 5 minutes.

Agile Journey Map (AgileSparks Way) – The non-Mercator version…



Mercator Projection


I was just starting to listen to Senge’s Dance of Change where he talks about the Mercator map (I can’t comment on the context since I context-switched to thinking about what I’m writing here about… :-) and was thinking that our agile journey map (What we fondly call “The AgileSparks Way”) is kind of the Mercator Projection map:



This looks very nice, right? So why am I calling it a “Mercator map”? Maybe you’ve read my post from last week about moving from recharge to improve (If not, I really like it so maybe you should…). I think I didn’t emphasize strongly enough the real distance on the map… This version might be a more realistic map… The “mercator” version shows kick-off, stabilize, improve as larger probably for similar reasons to why europe is so big in the “mercator” version… (and Africa smaller than Greenland…) – we consultants are prone to care more about the phases where we see more action. While organizations spend more time in the stability between the punctuations.

AS Way - the real lengths

So as a token of empathizing with the people actually going through the journey… here is the real map…



How to “restart” your Improvement Journey – A facilitation guide

Previously on “The Agile Journey”…

So some time ago – maybe months or years – you decided to go for Lean/Agile. You went ahead and started to use Scrum/Kanban to break the waterfall and achieve a more agile operation. These were exciting times. First, that time of making sure you understand what you are trying to achieve, checking out all the options, building the plan. Maybe forming new teams, maybe not. Maybe you went for an evolutionary change or a big revolution. Then, training people and helping them start doing things differently. You probably had some help from consultants along the way or maybe you had enough experienced/process-curious people on staff to get through this on your own. You spent some months stabilizing things – taking care of all the impediments that surfaced to us the “Scrum speak”.

And then, after all this excitement, it seemed like things were actually working. Everyone felt that. It seemed like the journey was finally over. Maybe you even took a look at the goals you set to yourself and saw you achieved at least a major improvement. Maybe things just felt ok. Slowly (in some cases not so slowly…) everyone’s focus moved elsewhere. The retrospectives started to feel routine. The stabilization board started to grow rust. You reached a new plateau of performance. And it was ok.

(As external consultants we used to be frustrated by this plateau. It felt like there was a lot of value we could still provide the organization and nobody was listening. I talked about it back in 2012 in both the Scrum Gathering in Atlanta and the LSSC12 Lean/Kanban conference in Boston. When we defined our AgileSparks way we called this the “Recharge” phase – it comes after you finish “Stabilizing”. Naming it helped us deal with it – starting with the understanding it is natural)

At some point, you decided you want to get back to the journey. (Yes, you might notice there is a big question here of what are the triggers to get back to the journey and can we do anything as internal/external change agents to help organizations decide to get back to the journey at the right time – not too early but not stay stuck in this plateau too long? maybe in another post…). And you are wondering what are some effective ways to do that.

How to move from Recharge to Improve

(First, there are probably countless ways to do this. I’ve done it several ways over the years, I’m sure you have too. If you have a way you would like to share or already shared, please let me know in the comments, I’m really looking for practices people find useful for this stage of the journey. I just decided to share one of my favorites I’ve been using frequently lately)

ReStart with Why

One important step before doing anything is making sure you understand why you are doing it and what you are trying to achieve. This is especially important in the case of moving from recharge to improve because you are trying to nudge a system that is stable so you must understand the importance of moving it. A classic short movie that makes sense to see in this context is “Overcoming Resistance to Change – Isn’t it Obvious” (This is based on Dr. Eli Goldratt’s work in Isn’t it Obvious). You can show the movie to your team and follow it up by a discussion of how it applies to your current context. This is VERY similar to running a SWOT (Strengths Weaknesses Opportunities Threats) exercise, so you can do that instead.

An even more structured way I found useful in the lean/agile context is to give people concrete options for the Strengths – Reasons not to change/Weaknesses – Pains of not changing quadrants in the SWOT/resistance to change analysis. These options are based on the “Starting with Why – Goals for Lean/Agile Journeys” slide deck which we often use at AgileSparks.

If you are co-located you can do this by showing the slide and asking people to dot-vote on 2-3 goals they would like to focus on. If you have more time, start with scoring on all of the aspects to set a baseline for the future. If you used this to kickoff your agile journey you have the benefit of continuing the same language and getting the benefit of seeing the differences from the baseline you took when starting the journey. Even if you didn’t, setting a baseline now can be a good idea – you can get back to it a couple of months into your Improve journey and check where you are and what you should focus on next. In any case, the point is to look at where you are and choose areas you want to focus on improving – at the level of
Goals, not Means (That is important! As a facilitation tip – try to keep the discussion at the level of purpose/goal rather than means at this point.)

improvement goals sim2

If you are distributed or want people to prepare beforehand you can do this with the facilitator marking colored circles on a powerpoint slide (as can be seen above), work together on a google spreadsheet, use an online survey like the one here (I made the google spreadsheet used to generate this publicly available here) to get people to think about it either online during the session or beforehand, or use your favorite collaboration tool/approach.


1-Goals Survey - Mozilla Firefox 20062014 162340goals survey

In any case, at this point you should have 2-3 clear goals to focus on. Maybe these are the goals you originally decided to start your lean/agile journey for. Maybe they are different. The group from the first example above started the journey to improve flexibility, reached a good enough level and then moved to other goals.

Assess where you are (with regards to the fitness Goals you chose)

The next step is to assess your current reality and gaps that affect your performance in the aspects you chose to focus on. One way to do that is to simply run a focused retrospective with that goal as the theme. You can do it as a “World Cafe” (or your favorite subgroup based meeting design method) – in essence working in subgroups on the different goals and sharing notes and outcomes. If you are distributed or want to do this part as preparation to meeting face-to-face you can run this as well online as surveys using something like asking what is our current level, what are we doing well, what can improve our performance.

Another more structured way to handle this phase is to run a depth assessment. I like to use our own Lean/Agile Depth Assessment but feel free to use whatever you like.

Here you see a group that took our assessment. You can see their scores in each of the aspects of the assessment. After taking the assessment people understand more what each of the assessment areas mean and are able to map how relevant they are to the improvement goals they chose. In this case you can see for example that the “Empowered Teams and Individuals” assessment area was mapped to the “Engaged People” and “Sustainability” goals. After this mapping they could now choose assessment areas to focus on. We can see here “Empowered Teams and Individuals” was one of these areas. (You can ask “Isn’t this something they should have started with?” and my answer is that it depends. In many cases people don’t really understand what it really means when they start the journey so even if they try to do something they don’t get far. And others focus on goals that are lower in “Maslow’s hierarchy of needs” and then realize this is an area that they need to work on more. )

Now, within each assessment areas, look at the specific gaps you have and choose a few that are the most relevant for the goal you are trying to work towards. Take these gaps and add them to your improvement backlog.

Another approach is to look at something like the AgileSparks Way which has a catalog of options for the improvement stage and choose options that you feel as a team are most relevant to your choice of goals. This can be things like running the assessment, examining team formation, going on a WIP diet, going on a frequent releases exercise regime, etc.


From here on it is a matter of executing improvement/change. But you have strong forces on your side. You engaged people as part of this fair process (maybe it was your management team, maybe everyone). You started with why. You set concrete improvement goals that are mapped to concrete action items.

One last thing you might want to do is to run a vote of confidence with everyone who participated in the process to see whether they think the plan makes sense and is worth pursuing. And if not, iterate and fine-tune until it does.

As an interactive session I would recommend setting aside about half a day to a day for this activity. Ideally offsite as an opportunity to open your mind and think creatively. “Doing Food” never hurts as well.







Do Craig Larman’s Laws of Organizational Behavior really mean we always need to start with a structural change? What do they say about starting with Kanban?

I’ve been following Craig Larman’s work for a while now. I find the books he wrote with Bas Vodde on scaling agile to be very insightful and actionable.

I recently discovered Craig’s “Laws of Organizational Behavior”:
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
4. Culture follows structure.

And as a practical advice Craig adds:
i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.” “

So do these Laws mean we always need to start with structural change? With a move to Feature teams for example like Scrum prescribes?
I find the laws provide an interesting perspective about a typical challenge I see at my big enterprise clients. The structure is definitely providing a glass ceiling to improved performance. Sometimes the performance is at that glass ceiling but in many cases it is way below it.

At this point we have two choices (at least) – one is to do what Craig suggests and start with a structural change. In the cases where the organization is ripe for change that would typically be the right move. In many cases though the understanding of the need for a big change is missing. There is mistrust that the new language/approach/structure of agile/flow/feature teams will work and will address problems the organization cares about.

An alternative is to use an understanding-focused tool such as the Kanban Method to both improve the performance w/ the current structure but also to show its limits/glass ceiling. At some point the organization will have to decide whether the performance gains it got within the current structure is enough and whether it is stable/sticky within the current structure. If not, the leaders will now need to change the structure to break the glass ceiling and enable the next jump in performance.

I see this pattern a lot in the field in various sizes of organizations – Kanban used to show the way towards a real structural change towards an Agile structure of real feature teams. It typically drives a healthy leader-led change that eventually sticks.

Pull-based Change Management

A main theme of my work and thoughts recently has been Pull-based change. I noticed that I don’t have one place that I can refer people to for my work on this subject. Until I write a book about it, here are some links:

Lean Kanban UK 2013 Talk

Prezi from the Lean Kanban UK 2013 Talk:

Interactive workshop at Lean Kanban North America 2014


Coming soon – Amdocs SBG Case Study at Lean Kanban North America 2014

If you are interested to hear from me about this topic – let me know in the comments. It might urge me to write it up in a blog post.



Helping with Kanban – Thoughts from reading Helping by Edgar Schein

I recently read Helping: How to Offer, Give, and Receive Help by Edgar Schein (actually I listened to it on Audible and then read it again on kindle to better process/digest). I can highly recommend it if you are interested in ways to become a more helpful consultant, manager, person – one who is able to actually help people/organizations rather than just dispense advice/suggestions. I’m not doing a full review of the book here but there are a couple of points I found very interesting in the relation between the Helping approach and the Kanban Method, which I wanted to put out there. I will probably talk more about this in my Lean Kanban North America 2014 Interactive Workshop in San Francisco on May 8.

The key theme in the book is that in order to provide helpful help you need to be build the helping relationship – not jumping to the expert/doctor role of dispensing advise/diagnosing but first listening, understanding, working through what Schein calls Humble Inquiry which starts with Pure inquiry – understanding what is happening without trying to influence the client in any way. Only then moving to Diagnostic Inquiry which directs attention to other aspects in the story and Confrontational Inquiry which asks what-if questions thereby hinting at suggestions (which is close to the Doctor/Expert role).

“This kind of inquiry can best be described as accessing your ignorance and, because it is genuine inquiry, it is appropriate to call it humble. The helper becomes open to what may be learned through observation and careful listening. The helper’s expectations may be incorrect, and it is the helper’s willingness to accept new information that elicits trust and makes the client feel better about having a problem”

If we look at what we are trying to do with Kanban – it is quite similar. We start with understanding the system by visualizing it. Not trying to diagnose/probe too deeply before we understand – actually before the client/clients understand. Accessing our ignorance – we don’t know HOW the system is working, we don’t know how it SHOULD be working. Which is exactly what Schein is trying to do with process consulting – to build the understanding together, not be in a position to understand FOR the client but WITH the client. In Schein’s perspective this not only minimizes the chance we will dispense generic advise based on our experience of similar events but will help to equilibarate the relationship between helper and helped – listening and respecting the situation helps the client/helped gain back “face” that he lost by asking for help. If we don’t “bring the helped up” by doing this there is a chance he will “bring us down” by trying to be very critic and unaccepting of our suggestions by the way.

“Starting out in the process consultant role is the most likely to facilitate status equilibration and to reveal the information necessary to decide on what kind of help is needed and how best to provide it. Only when some level of trust has been established is it possible to get accurate information that allows the shift to the expert or doctor role. As the helping process proceeds, the helper may shift among all three roles many times as the situation demands.”

This humble inquiry approach is also aligned with our approach towards management workshops in AgileSparks. Our instincts over the years pointed us away from diagnosing and presenting solutions and towards a more humble exploration of the system/context in parallel to presenting some useful patterns like Kanban, Scrum, ATDD. I try to emphasize the diagnostic role of these patterns/frameworks and the fact that even when we go out of the room with a decision to do something, it is basically a continuation of this “humble inquiry” (I didn’t use the term until today obviously…). We are obviously shifting roles from process consultant to doctor and expert and one of my main takeaways is to be more conscious about the role I’m playing and whether it is the effective/helpful one at the moment. I’m definitely jumping to the doctor/expert one faster than I should – and I will try to work on that using some tips and tricks from the book.

To summarize – and as I answered Bob (Marshall) yesterday – this book leaves me: startled (discovering new perspectives of how I’m doing things), a bit ashamed (for being more of a Doctor/Expert), alert (to the potential of being more helpful using this approach) , curious (about whether I can actually leverage it and what will happen if I do), rejuvenated (by getting a fresh perspective to something so core to my work). So bottom line the Helping book was quite helpful.

Kanban FAQ: Should I FINISH what I’m working on or help the team READY new work items?

Once people start to get “Stop Starting Start Finishing” thinking (Kanban) or the “Focus on the current sprint” thinking (Scrum) a frequent question that comes up is how to deal with people who are required for different activities throughout the work life cycle.

Some example scenarios:

“I’m a tester who both participates in ATDD spec. workshop (upstream) and exploratory testing (downstream). The developers are free to start a new story, should I help them with the ATDD thinking for a new card or focus on finishing the one I’m working on?”


“I’m a developer who both analyzes new stories (you might call it backlog grooming if you’re a scrum team…) and develops them. I see our backlog of ready stories is running low – should I continue to work on my story or should I move to analyze some new ones?”

Stop Starting Start Finishing talks about finishing things and minimizing the waste of inventory. It seems to say always prefer to finish and not starting. Why would we even consider a different approach? And indeed on some rare teams it is reasonable to work in a pure “One piece flow” mode where we focus on one thing, finish it, and then move to the next. But this requires a very high level of collective ownership and collaborative concurrent engineering. This is seldom the starting point and rarely an early achievement of teams trying to set up a more healthy flow of work.

So in the majority of the teams the challenge is that in order to maintain healthy flow people are typically working on different things. And when the work process of these teams is such that it requires different members of the team to take part in the work in separate areas of the life cycle so they have to touch the work, leave it, and return to it, we have an issue. Maintaining healthy flow is now in conflict with Stop Starting Start Finishing because you would typically always have something to finish, so when are you going to move left on your board or go to work on things related to your next sprint?

One concept that might help is the “Lean Decision Filter” (see slide 16 from David J Anderson’s  Lean Kanban 2009 Keynote):

Lean Decision Filter

• Value trumps Flow – Expedite at the expense of flow to maximize value

• Flow trumps Waste Elimination – Increase WIP if required to maintain flow even though it will add waste

• Eliminate waste to improve efficiency – Do not pursue economy of scale 

So based on the filter what we can deduce is that if we need to start something new in order to maintain flow then this is what we should do even if it is a potential waste since we could have focused on finished something.

BTW In a lot of scrum teams this manifests as the heuristic to spend 10% of the team’s capacity on preparing for the next sprint.

A way to decrease the waste of context switching while maintaining flow is to use an ongoing cadence. For example hold specification workshops or backlog grooming sessions at a regular time each week. This minimizes the impact of the context switch since it provides some heads up for people instead of surprising them and pressuring them to move to something else (otherwise the rest of the team will be idle…).

Bottom line – one of the first steps to really getting Kanban/Scrum is to start thinking “Stop Starting Start Finishing”. But the Lean Decision Filter helps us apply the required common sense to real world situations where this seems to be in conflict with effective flow – which is actually what we are striving for.

Do you see this problem in other forms? Did you find other ways to rationalize the right thing to do? Do you have other tips/suggestions to people facing this problem? That’s what the comments are for…


Lean Kanban North America is coming to San Francisco but when will I have time to enjoy the city?

Lean Kanban North America a.k.a Modern Management Methods conference for 2014 is coming up. This year it will take place in beautiful San Francisco.  I love San Francisco and the conference hotel is smack in the area I love most – the waterfront… But I’m not sure how much time I will have to wander outside…

I’m expecting quite a busy week – As one of the two winners of last year’s Brickell Key award I’m on the selection committee this year. Legends tell of long nights deliberating the merits of the different candidates until white smoke rises. Looking at the strong candidates nominated for this year I don’t see how it will be any different this time… :-)

Beyond that I have two sessions I’m involved in this year. One is the Amdocs Case Study. Conference series veterans will recall an Amdocs case study Erez Katzav and I presented back in LSSC2010 in Atlanta. Wow, that was a long time ago… Anyhow this year a fine team from another division in Amdocs is coming to talk about how they are using Kanban to improve the agility of a business group encompassing thousands of people. For those of you keeping track of my work and talks – The initiative is based on a lot of the things I talked about in the last years and has been a source for a lot of talks/write-ups as well. It is a very interesting story with ups, downs and new interesting challenges every week or so. For anyone interesting in change management in a large scale global enterprise as well as how to run a large scale operation using kanban flow approaches, don’t miss this session.

And finally, on thursday, I’m running an interactive workshop about Crossing the Chasm and pull-based change. This workshop will be an opportunity to elaborate and go deeper on some of the themes in the Amdocs case study and other talks like Kanban – a SANE way to go agile from LKUK13. I’m still obviously working on the structure for the workshop but am excited to have a more interactive intimate opportunity to talk about these topics, answer questions, hear feedback and ideas as well as stories/experiences from others who are facing similar situations. The Amdocs team will obviously also participate in this workshop so it is a great opportunity to dive deeper into questions that arise from the track session.

And on top of that there’s a very interesting schedule of sessions, keynotes and other interactive workshops I’ll want to see… (Here is my current plan…)

Busy week. Where is the time to go to the wharf and enjoy some clam chowder bread bowl? To catch up with everyone? Oh well.

Having said that, if you are at the conference and want to talk, I’m sure we can find the time… best way would be to contact me on twitter.

See you there!



Kidzban/Personal Kanban 2nd grade elementary school class experience report

The purpose
As a parent to a 2nd grade school girl I want to deliver a personal kanban / KidzBan class in a school show & tell parents activity so that kids are exposed to this interesting approach to plan & navigate their activities that can help them take ownership. Desired side effect – for her princess to be proud of her father.
Well, I’m not a Kidzban or Personal Kanban expert. Far from it. We’ve played occasionally with Kidzban at home but we are certainly not practicing it on an ongoing basis. Far from it. I’m also much more of an Enterprise Kanban kind of guy. But since talking about Hierarchical boards, Expand/collapse patterns, various ways to Limit WIP, MMFs, MVPs, Feature teams, Classes of Service and cycle time control charts in 2nd grade might have been an interesting experiment, I’m not sure either I or my daughter would have been proud of the outcomes.  So I decided to take a shot at a personal kanban/Kidzban class, with the understanding that the kids will still NOT understand what I’m doing for a living afterwards…
As an initial structure I planned to start with why an approach like personal kanban is even interesting to the kids, and then show very basic Personal Kanban using an example and then let them experience it by building their own Personal Kanbans and doing dry runs on them in small groups.
Then, I consulted both with Danko (Danny Kovatch – my friend at AgileSparks) and Shirly (@ShirlyRonenRL) who together are advocates of this field in Israel and also wrote the nice ebook Agile Kids as well the online #PersonalKanban/#kidzban crowd ( @topsurf @ourfounder @maritzavdh and others like @YvesHanoulle @markusandrezak pitched in as well – isn’t twitter great when you have such great online friends?) for some tips about how to do it. Key insights were: Let the kids experience it themselves, Don’t talk that much – less talking more doing, Don’t show and tell, actually build it together, Use lots of colorful post-it notes, Let them draw pictograms if they want, choose themes like planning birthday parties, packing for a family vacation, chores mom asks you to do.
Based on all these great tips I decided to build the initial example together with the kids using the example of home activities mixing chores and wants, with the goal of navigating the chores/wants better in order to get to as many of the wants as possible not by neglecting the chores but by mixing them in and by using kanban to be more focused and responsible. I then planned to indeed let groups choose their theme from the list above or other activities the kids suggest as things they plan and do that might require something like kanban. I also planned to have a takeaway session at the end for kids to talk about what they like about the approach, and if they want to do anything with it at home.
Responding to Change over Following the plan
2014-01-17 08.26.44
Come friday morning this nice plan didn’t really survive contact with the enemy. Oh Sorry, the class :-) Actually the kids were lovely and engaged and we had lots of fun experiencing kanban and discussing the world of chores, wants, the connection between the two, while drawing boards and moving a lot of colorful post-its and stattys notes around. They were so engaged and excited that it was hard to push forward in the activity as everyone had to share their ideas, not necessarily in a way that is very related to Kanban itself but it is very hard to be an aggressive facilitator with kids, at least for me… Telling them lets park it was hard and I decided that as long as they are having a fun discussion and experience that is even more important than getting the whole point across (even though I actually had limited points to get across).
The key thing I would like to have improved outcome wise is to be more certain they actually understand how the actual operation of the kanban works on a daily basis. We exercised it in several scenarios, with them guiding me what card to move next, as well as volunteers moving them in several scenarios, but I still have a feeling that they mainly grasped activities like “map what you need/want to do” (a.k.a. create a backlog) as well as “plan your day” (a.k.a. pull to the “today” area) but that the whole flow of pull into “In Progress/Now” and all the way to “Done” didn’t really sink in. Maybe it is the fact they were so excited about discussing their wants/needs/chores that focused them on this area. Maybe it is something about the way I facilitated this discussion. But if I do it again I will certainly look for ways to get much faster to the actual act of pulling cards and experiencing the full flow and deemphasize creating lists, maybe by providing some initial ones, or by stopping this discussion earlier.
In addition I felt that the concept of dry-running was too abstract for the kids which was why when they exercised their own boards creating the plan resonated while creating the “In progress” lanes and actually playing to try it was very tough to get them to try. This repeated with almost everyone.
Another interesting area was the comparison with the calendar/timetable they use for their classes at school/extra-curricular activities. I felt it was non-trivial to get them to grasp the challenges with a fixed timetable that would drive them to use a dynamic system like kanban. I see this with my daughter for example. On several occasions I saw she feels much more comfortable planning a calendar/timetable rather than a kanban style pull system. Even the kanban board she and a friend created in class had some form of timetable swimming lanes in it. After talking to her about it some more she says she now gets why with kanban you don’t need those timetables and why it might be a better option sometimes, but I think we haven’t got to the root cause of this yet so definitely an interesting area to explore further.

Sensing and increasing manager engagement during an agile change initiative – guest post by Yaki Koren

Earlier this week I published a guest post about how managers need to change if they want agile to succeed by Yaki Koren. Some blog/twitter followers asked for elaboration and Yaki was gracious enough to comply. I suspect the fact that this is a really hot topic for him this week helped. Without further a due, here is Yaki with some explanations of what the coaching team in his organization does to sense and increase manager engagement in order to improve agile change depth and stickiness… (Note Yaki doesn’t emphasize it but we are talking about a Kanban Method style of change initiative here which affects the kind of activities going on).
I was asked after the earlier post how do we engage managers and making sure they captain the ship. Here is a try to explain what we do (or at least what think we should be doing and when we do it, it works well).

As we are internal consultants it is quite easy to engage us – there are almost no bureaucratic barriers. We have developed a few techniques to protect managers from harming themselves by going down a dangerous path (for them).

As mentioned above we realized that a key success factor for agile implementation is a manager’s willingness to captain the ship. So the first thing we make sure is that the manager contacts us and not the other way around. We may do marketing, we may do an elevator pitch but the manager should call us, the manager should set the meeting. It’s a “call us, we don’t call you” thing. At the meeting we let the manager run it, state their need etc.

We keep doing this all through our engagement with the manager. We are making sure someone is pulling us and no pushing is done. When they stop pulling we, again, may do marketing and may encourage them but they need to take the action. If it’s not important enough for them they won’t do the action.

So, many times there are initial calls that die off and there may be a session or two and then it dies. It better die early when not too much damage was done.

Our main problem are cases where for some reason the process did start to actually run and the group moved to Kanban and then they stop pulling. These are sad cases with bad public relations, though I must say that even then it usually works better than the alternative.

Another thing we do when starting is asking the manager to budget us. We didn’t do this initially (we got the budget from top management) and when you don’t pay you sometimes don’t care. So now we’re asking for some budget, usually higher than what we actually need – and this proves to be a good test for the manager, another sanity check for their willingness to invest in the change.

When they lead it and agree to budget us we make sure they understand what are the big challenges they are going to face:

· Progress monitoring is quite different than what they’re used to – we tell them they will feel a loss of control at the beginning

· They need to invest more in day to day management – less status reviews and more execution (some managers don’t understand it: for them the change is easy)

· The process of work will keep changing. There is no winning formula we can give them – They will start with something and need to constantly adapt. It’s not a one-time bang thing. I should write a post on this aspect.

Since our organization is big sometimes we are not contacted by the person we believe is the one who should actually lead the change. Sometimes it may be a subordinate, their manager or even a peer. So they may set the meeting, they may even budget us but still we need the person who should lead this to actually show they’re serious.

This is more tricky.

You may find yourself in a room with a person whose manager asked him to do the change and the manager is not there at all. If they are not interested you are trapped. Suddenly it is you that wants this and you may find yourself pushing instead of being pulled.

What we do (or more accurately “try to do, really want to do, plan to do and sometimes it actually works”) is again to make sure this person wants it. We sit there, quietly. Many times they will expect us to lead this – however this is not ours to lead, right? So we may ask politely how can we help. You will get a deep frown doing this. And, by the way, it is fine if they tell you they’re there because their boss told them to. Then you need to understand together what is it they’re boss wants them to do. If they don’t understand why they’re there they need to get back to whoever arranged this to understand the reason.

Many times we have sessions with the project team. I like being in the center of things, giving a great performance, but it seems to be much more effective if the manager does this. I need to fight my ego and then do a good preparation with the manager (after explaining why they should do it) for the session. The more the managers lead the more effective it will be.

When we start the process we sometimes find we are becoming part of the operation. To avoid this we make sure we don’t attend all project meetings on purpose, we make sure nothing is dependent on us. This is the team’s thing, not ours. We are there to help, not do some of the job. Again, it is very tempting to do it – create the excel, lead the session, build the board – but every time we do this we skip a learning opportunity for the project team and increase their dependency on us. It is a matter of empowerment.

I believe there is more stuff but these are our main techniques for making sure only managers who are apt for the move to agile actually do it and when they do it to make it their thing, not ours.

The downsides of agile – guest post by Yaki Koren

This is a guest post by Yaki Koren who is the lead coach in one of AgileSparks’s clients – Amdocs Delivery who are going through a very interesting transformation leveraging the Kanban Method, crossing the chasm techniques as well as several key agile practices. It is also where I spend a considerable slice of my time the last year trying to help make this happen. And now – here is Yaki…


Last May I gave a talk at Agile Israel about the implementation we did in my company. At the end of the talk a guy from the audience asked what is the down side to agile. I must admit I never thought of it as it looked quite perfect to me. Eventually I answered that managers who like to micro manage will find the move to agile difficult.


Now after more than a year of implementation I think I have a better answer to this question.


We are doing the transformation to agile in many projects. Some succeed more and some less. In small projects (around 10-50 person months of development) it seems to go well most of the time.

The problem starts with the big projects. Here you see great differences. You come to the daily meeting and you think you are in a different company.


In some projects (where it goes well) you see the project manager leading the meeting, setting priorities, making sure all are working together. In other projects the project manager couldn’t make it to the meeting so some other person from the project management team is facilitating the meeting (less of a lead and more of a facilitator). In these projects the various parties of the project take the agile spirit to the direction of the wild west, including show downs when the sun is high in the sky.


The down side of agile is that managers actually need to manage. It is a down side to some and an upside to others.


It is not a simple task moving from playing the commitment game to constantly navigating the ship through the stormy seas of software development. Some managers get a new spark in their eyes when introduced to agile, feeling revitalized with new zest and vigor. Some try to play the old game under the new dress and there things go awry and frustration follows.


When we start an implementation we ask the managers why do they want to go through this. Now we are starting to tell the managers what is the expectation from them. What will be the change in their day to day. We believe this will help us better align expectations with the managers and to make sure we have better results with the implementation.

Lean Startup Blues

Yesterday I had an interesting session with a company who’s been a big believer in Lean Startup and the MVP concept but have lately reduced the amount of MVP-driven product development dramatically. Not because there is less uncertainty to iterate through but due to something we can call the “Lean Startup Blues” – the lack of faith that the MVP process works at scale over the long term.

The main challenge is that building MVPs is not enough. Some organizations don’t really close the learning loop as often as they would like to. They build MVPs but they don’t spend enough effort to really learn whether this MVP is in the right direction. What typically happens is that they move on to another idea after the MVP goes to production. Iterative development is dangerous when there isn’t a steady captain at the helm. The ability to shift direction brings back the classic dysfunction where the first phase of many ideas are abandoned or moved into maintenance mode where it is hard to have a serious impact. It is actually the fear of this that drives many Product Managers and business stakeholders to specify all they think they will need up front because they know they have a limited window in which to get it. After this window is closed most chances are their project will be abandoned. Several difficult changes need to happen to overcome this problem. First, people need to trust that MVPs will lead to learning and a wise decision between pursuing an MVP towards a real feature/product or killing it.Then, people need to trust that the right prioritization decisions will be made in the future and that if it is really a good idea to continue investing in an idea then this will happen. To make it harder, people need to think holistically – taking the chance that their ideas will not turn out to be winners and therefore will be abandoned – as opposed to trying to force implementation of their ideas by going for a full implementation instead of an MVP.

Using the right Kanban reality board can at least make visible the amount of this dysfunction going on by showing the size of features and the amount of MVPs that are left as is without leveraging the learning to drive further development and business value in that direction. Steps like “Deployed”, “Validate/Learn”, “Pursue” can help you see what is really going on. Having WIP limits on these stages will force some discussion about what to kill and what to pursue and end purgatory for the miserable MMFs.

Another thing that might be a challenge is actually learning whether the MVP hints at gold or not. Data-driven decision making is the holy grail but it is very hard to get there. Some organizations are giving up on it and don’t do any learning/feedback at all. Soft learning is better than no learning process at all in my opinion.

The problem with MVP purgatory is not just that we lose on the business benefits. It is also that since an MVP is typically an experiment, it typically leaves the product in a state of debt. Both technical debt – since we developed an MVP we allowed some shortcuts on the architecture/automation/clean code/etc. And Product Debt – We added a feature, it covers a certain set of use cases, but if we did the MVP right it is not whole. far from it. It was actually painful to go with it in the first place but since we were looking for the real minimum to enable learning, we did it. But the assumption is that we will either follow through or kill it. Letting the MVP stay in the product as is leads to usability issues, maintenance issues and makes future development more difficult.

Leave enough MVPs in purgatory and people will simply stop using the MVP approach. They will prefer to skip on the fast learning loop and get back to familiar ground of developing something cleaner and more usable even if it is not useful.

The way out of this mess is to have a clear policy that says you either kill it. really kill it. Or you clean it. really clean it. Please decide. And limit the amount of ideas that are in progress without a clear decision. And don’t allow starting a new MVP unless there is room for it. Make room for it by selecting another idea and kill it or clean it. Or pivot it. This is “Stop starting start finishing” applied at the MVP portfolio level.

By the way MVP is just one option of how to approach building something. It is a good option when there is a lot of business/requirements uncertainty. If not, just build minimal slices of functionality that are marketable (also called Minimum Marketable Features / MMFs) and release them. Don’t expect to do much learning and don’t skip on the technical excellence while building them. With MVPs you keep the option to kill it or grow it to later. But that option has a price. Refactoring to clean or killing a feature doesn’t come for free.  If there isn’t a lot of uncertainty that price might not be worth it. So define your policies for how to build different kind of risk profile ideas/features/products. assign the right profile to each idea. feel free to move ideas between profiles along the way as more information becomes available. Make the team building it aware of the profile. Explain to them the context. This will help them make the right tradeoffs along the way.

Another interesting thing to look at would be the “Killed Ideas/RIP” bucket. You would expect to see some ideas ending up there. That is a good thing. But you should also expect to see the cycle time until that area grow shorter and shorter meaning faster learning loop. (Just be careful to avoid setting it as a target otherwise people might not kill an item just to avoid increasing the time to kill metric…)

To sum up, there is nothing bad with the Lean Startup MVP concept. It is actually a great idea. Done right. And doing it right requires discipline & process maturity. attention to end to end flow from idea through validated learning all the way to kill/grow. Enterprise Kanban looking at the portfolio of MVPs/MVFs is a great way to grow this discipline and maturity. It also requires strong Product Managers who are able to define effective MVPs, guide the learning process, have the courage to hit the kill switch or to stick to something even though there is a lot of pressure to “start the new thing”.


Pixar Pitch for Kanban – a SANE way towards enterprise agility – my LKUK13 talk

This fall I’ll be talking at DevOpsDaysTLV, LKUK13 (Lean Kanban UK) and LKCE13 (Lean Kanban Central Europe).

If you’re interested in my talk for DevOpsDaysTLV about Kanban – a SANE way towards DevOps, check out the prezi.

My talk for LKUK13 is called Kanban – a SANE way towards enterprise agility. While it sounds very similar it is actually a 100% different talk… I finished a draft of the prezi and also wanted to share my somewhat “Pixar Pitch” which I’m currently thinking of closing the session with, as a treat for blog readers whom I kind of let down the past couple of months by not writing much…

once upon a time we had a great time going agile for single projects/teams
then once we grew successful we got the enterprises interested.
some of us forgot our roots and used waterfall to go agile
some of us just joined the party without even having an agile heart
and then it didn’t turn out so great. it didn’t stick. it created resistance. people fell back to old ways. if it wasn’t for the continuing stream of new “suckers” it would be a dark period for the agile movement.
and then some of us started realizing that we should use agile to go agile and that this is what we had in mind all along (whether Scrum or Kanban). We realized that concepts like intrinsic motivation, opt-in and self-organization should be used for the way we go agile not just as agile itself.
Some of us also recalled some cool marketing concepts like “Crossing the Chasm” that also apply in the enterprise change management world. And then we started treating the enterprise as a market for change and leverage the guidance of the “chasm” model.
We focused on innovators and early adopters. We focused on the leaders first in order to create the best improvement/change engine possible and validate as early as possible that indeed we are in the right direction.
We used success to create a beachhead which allowed us to pull in pragmatists.
We leveraged a catalog of patterns/practices, realizing that they shoudn’t be a “bible” but more a useful list of options, in order to help pragmatists which didn’t want to invent the wheel but just get return on investment fast.
We helped organizations drive the market by setting the right measures of success.
We saw a “hockey stick” and realized we need to manage the changes in progress or scale the team helping those changes happen or find ways for the change to happen with less involvement.
We started seeing enterprises that are really becoming more agile, not just due to number of certified scrum masters or SAFe practitioners or Kanban practitioners they have or the fact they run dailies or sprints or have kanban boards. But based on how a growing and influential group of people think and act and what kinds of changes they drive in their domains.
This is the next generation of enterprise agility case studies. Coming to a conference near you in 2014. See you then!


So – what do you think?

While you digest I will use the rest of the Israeli holidays downtime to make progress on my last talk for this fall – Avoiding the Ganttban…

Bootstrapping Agile (by yourself) using Kanban – My Agile Israel 2013 talk

Agile Israel 2013 took place yesterday. This year was they year of “Hands on”. Around 600 attendees came to get practical hands on advice on multiple aspects of the agile world. My talk was about running your agile journey on your own.

This talk was aimed at people looking into agile or exploring ways to go agile for “group level” and above. I presented a mind map I recently created based on work I’ve been doing in the field the last 2 years and some experiences of other coaches on the AgileSparks team. I also mentioned some aspects of the recent and excellent Kanban Kick-Start Field Guide. 

I also experimented with a hybrid delivery approach for this session. I started with an Ignite/Pecha-Kucha style run through the 37 frames Prezi using 20 second auto-advance. Together with a short intro to what I’m going to do took about 10 minutes. Then I allowed serious time (something like 20 minutes) to deep dive of areas the session participants found especially interesting or unclear. This felt quite good as a speaker, and I got some good feedback from people in the audience, as well as some people who didn’t really like the session (red dots – no explanation why…)

The first question was about where how to choose which teams to start with, how to deal with different approaches for different teams, which was a good chance to explain my “Starting with Managers Kanban” approach in more depth – basically starting with value streams rather than component teams, then explore real value-stream/feature teams, then scale to more and more value-stream/feature teams as you grow your maturity, understanding. I think it is especially useful when exploring agile on your own, as it ensures the leads/managers are into it before you go into deep painful changes that are beyond your pain/skill threshold.

Second came up another one of my favorite challenges – how to make sure improvement happens. I took this opportunity to explore this area of the mind map in a bit more depth, basically addressing 3 key areas:

  • The need for purpose/urgency (connecting the drivers for agility with relevant metrics)
  • The need for clear actionable steps beyond just “improving” and “retrospecting” (here I described the concept of “boosts” to use the term coined by the Sandvik people in their great Lean Kanban Central Europe 2011 talk as well as gave some examples like Maturity/Depth assessment, Learning about variability, Learning about bottlenecks and Theory of Constraints, Learning about Rightshifting and how to use it to energize further mindset shift.
  • The lack of progress on identified improvement actions. Here I talked about Personal Kanban for leaders and management teams as a way to create discipline of execution and Improvement Kanban Board to make sure improvement actions are first-class citizens in your execution routine

BTW, readers interested in this topic are welcome to look at my Lean Systems and Software Conference 2012 talk – The Improvement Journey.

The last question we had time for was about my favorite visualizations. Kanban boards obviously. But I also talked about the Talent Matrix and how to use it to grow versatility in a way that is collaborative and inclusive. I also mentioned dependency boards and hierarchical kanbans that can be useful when applicable.

One of the questions people are asking me is obviously do I really believe people can bootstrap agile on their own with Kanban? My answer is that it obviously depends. If you have a great leadership team, the need and motivation for agility is clear, there is the ability to invest in learning on their own, the time to spare for experimenting and taking time to recover from wrong turns, then probably you can make it on your own, at least most of the time. Having someone who knows what they’re doing around can reduce risks, help recover faster from wrong turns, avoid some unnecessary mistakes. This provides some “risk management” as well as acceleration of the bootstrapping and improvement process. Note that even if a coach is involved I believe great coaching still leaves most of the work at the hands of the managers/leaders of the organization and still requires experimentation and evolution by people on the ground.

While obviously attending a 30 minutes session is not enough to make this happen (dear attendees, don’t expect a Certified Kanban Boostrapper title…)  I believe we can help change agents use this approach to bootstrap agile in their organizations. If you want to learn more about this approach, we are considering a “deep dive” workshop that will get you to that level – including Kanban, the Implementation approach, the different Boosts and Models mentioned, and other tips and tricks we use at AgileSparks to help organizations improve.  Leave me a comment here or at AgileSparks if that is something that interests you.


Explaining MVPs, MVFs, MMFs via the Lean/Agile Requirements Dinosaur

In the last few weeks I’ve been using a new visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …)




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.

IMG_0455In 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…

IMG_0456…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.

IMG_0457If 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.

IMG_0458There 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!





Recent Reading Lists

I’ve recently gone into Seal/Whale mode and didn’t have too much time to blog.  Sorry for that… To make the wait for new content easier, I’m sharing a couple of reading lists that I curated recently for use in client work. People often ask me for reading materials to help prepare for workshops/sessions so I decided to create a couple of bundles to serve as reading lists. – 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) – An initial reading list about Kanban (used to introduce AgileSparks clients to Kanban in preparation for an engagement) – Advanced Kanban Reading/Watching Materials – 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 –, 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

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…



May the WIP Games begin…


Hatsav (Maritime squill) – By Dany Sternfeld on Flickr

The day has come for FLOWer to bloom (maybe we should call it “Hatzav” (maritime squeel) after the flower that brings the autumn here in israel… btw we are in the middle of october and it feels like July, can’t wait for the Vienna weather next week in Lean Kanban Central Europe 2012 – you’ve got your tickets already, right?)

Introducing FLOWer


A couple of months ago I’ve written about experiencing Kanban system design and if you’ve been waiting to see what I’m talking about, today AgileSparks is soft launching FLOWer. Well, at least an initial version of it focused on experiencing the effects of WIP on flow and ROI/Profit of the business. You are welcome to go try FLOWer now.

A couple of notes about the beta:

  • Starting the simulator and seeing it in action doesn’t require any registration. Just open it and kick the wheels. Tweaking the settings requires registration which is currently done by simply associating your google account. We are assuming most people have a google account. We only keep your emails so we can be in touch, we don’t do anything else with your data.
  • We are currently in beta mode which means we limit the amount of users registered to the system. Hurry up and register. First come first serve.
  • We are still figuring out the pricing model. You can leverage that and enjoy it free at the moment. And we will make sure we take good care of early adopters that help us shape up the product.
  • We are trying to make the simulator and the game self-explanatory. We’re probably not there yet, so please comment or leave feedback on the site itself with anything that wasn’t clear, didn’t work as you expected, or points you just felt stuck at.
  • The simulator will run on any modern HTML5 browser. Chrome, Firefox, Safari… iPad Chrome/Safari… But that also means IE is NOT SUPPORTED. 

PS Participants of AgileSparks upcoming Kanban training (on 30-31/October) will also play FLOWer, including advanced scenarios that are “in the oven” at the moment…

So, what are you waiting for? Go ahead and play! (Sorry, we didn’t include a Boss Key… but maybe your boss would also like to see how intelligent context-specific and adaptive application of Stop Starting Start Finishing is a way to bring home more Benjamins!)


Art of Action by Stephen Bungay – Book Review

The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results

Before Lean Kanban Central Europe 2011 I never heard of Stephen Bungay. He delivered a magnificent keynote that ended the conference (you can see the slides here but the video is just for participants) and so I became interested in his work inspiring Business Strategy by Military Strategy especially as espoused by the Prussian Army in the 19th century. I recently finished his book The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results and wanted to recommend it to anyone reading my blog as well as share some thoughts.

A key concept in the book is that we are operating under increasing forces that obstruct our ability to predict what will happen, create total alignment on actions our organization takes and on the effects/impact the actions people eventually take will have. This is referred to as “Friction”.

A key model in the book and in Bungay’s work is that friction is caused by 3 gaps – see below.

The Problem

The Solution

I found a very strong connection between the different gaps and the approach to closing them and what we are doing in Lean/Agile world. I think this model brings a lot of sense into some of the key agile practices.

The strongest connection is to User Stories. User Stories provide a very strong focus on Intent (if you do them right, that is the “So That” part…). They don’t go into the details on purpose, leaving them to the next level to hash out. We start with very high level User Stories and then break them down level by level, sometimes handing down a branch of the User Story to a different team/group, similar to the way mission commands can be handed down to the different units participating in the mission. It is important for the team working on the story to understand the context. Bungay recommends two levels up is just right. So Be aware of the Epic/MMF this story is part of as well as the Product/Theme/MVP we are currently working on. More is too much, Less is too little.

I love the concept of Briefing and Back-Briefing so much that I want to experiment with renaming “Iteration Planning” into “Iteration Briefing” and “Back-briefing” and adjusting the format of the meetings accordingly. Good teams already do something like that I think, which is a good sign that this model is a good way to look at things and explain them.

Look forward to more concrete ideas for how to leverage Bungay’s work in Lean/Agile. In the meantime my full comments/notes are available on the Amazon Kindle site and best would be to actually read the book. I think you will enjoy it.

(If you are really interested in my conclusions from the book, comment here and let me know, maybe I will enrich this post some more…)


Looking forward to Lean Kanban Central Europe 2012

Lean Kanban Central Europe Conference OCT 22-23 2012, Vienna

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…
My personal goals are:
  • 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?

Implementing the Kanban Method using Scrum (a.k.a Scrum with a Kanban spirit)


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.


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).
Every day of the iteration we will hold a short (10-15min) “Daily Scrum” standup meeting in which we manage the flow within the Iteration. In this meeting the Team and Product Ownership meet in front of their visibility board (Kanban / Taskboard). They talk about flow since last meeting (What I did last day, what cards I moved), expected flow until the next meeting (What I intend to work on today, cards I’m about to Pull/Complete) and mainly impediments. Impediments can be work item specific or flow problems (bored waiting for devs to deliver something, seeing too many defects in what was delivered feeling uneffective, etc.) Impediments can be solved quickly in this meeting or taken offline by identifying an owner that will deal with them until the next meeting. Items with impediments/blockers can be marked using a special indication on the visibility board. Systemic Flow impediments can also be marked (e.g. mark the interface lane between Dev & Test with a red post-it saying “Nothing ready for testing 23/9″.

Implement Feedback Loops

Note that since we implemented Scrum ceremonies we are already deep into Kanban Method’s “Implement Feedback Loops”. The Iteration ceremonies provide feedback loops about Product and Process. The “Daily Scrum” provides a tactical feedback loop. Some teams learn to use the “Daily Scrum” to have a tight light-weight process feedback loop as well and add “Kaizen Moments” as necessary when dealing with what appear to be systemic impediments.


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?
The Iteration ceremonies we defined are also explicit process policies. They answer questions like how do we replenish the system, how do we deliver, etc.

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.



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?


Starting with Managers Kanban (also called Product Stream Representative Kanban)

The short version

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.



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.


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.


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

Using card types and filters as “Virtual Horizontal Swimming Lanes” on a Kanban Board

After a serious break from Kanban Mechanics posts, here is one for you Kanban System Designers/Practitioners out there…

I’ve recently become a fan of the “Virtual Horizontal Swimming Lanes” style of Electronic Kanban Boards. These Boards don’t use physical horizontal lanes but instead use dynamic and easy filtering to show virtual lanes. Specifically I helped several teams come up with this style to represent a 2-level board – for Features and Stories (actually 3-levels if you count breaking each Story into Team-Stories or Tasks using a sub-taskboard). Since I get some questions about this, I thought it will be helpful to record a short screencast about it. So here it is.

These teams use LeanKitKanban by the way, which does a very nice job, especially with the refreshed UI and filtering capabilities. I’ve worked with simpler designs in AgileZen and more and more tools provide dynamic data-based horizontal swimming lanes these days (Atlassian GreenHopper RapidBoards seems to have a good one that some teams like but I haven’t worked with it too much myself). In order for the tool to support this you will need a way to filter/split into lanes based on data attributes of the cards, ideally with the ability to setup a couple of identifiers for the virtual lanes that will be attached to the items moving thru the lane and then detached from it.

Kanban Board Hierarchies using Virtual Horizontal Swimming Lanes


Also, once you start using such a board, getting to a workable “Release Burnup” which shows you trendlines of your progress compared to where you need to be can be tricky, as it always is with multi level boards. A key trick is hiding the parent expanded Feature when its child Stories are in play as well as hiding the completed Stories from the CFD when they are collapsed back into the parent Feature. This way we avoid showing a piece of work multiple times in the CFD. This CFD is calculated based on card size since that is the way to deal with different levels of size on the board as well as the fact that Features in the backlog might not yet even be Minimally Marketable and so can be quite large. Not this is the way to track a “Release”/”Project” comprised of multiple Features. To track a single Feature you simply use the filter above to see how it is doing, or create a CFD focused just on the cards in this virtual lane and then see the burnup towards completion of this specific feature.

To generate this CFD in your tool you will need a strong CFD capabilities that allow you to expand/collapse lanes as well as ignore lanes and calculate CFD based on size.

If you are interested in the template for this board here it is. Maybe the LeanKitKanban guys will add it to their template library at some point…

If you want to learn more about this leave me a note, I might be convinced to elaborate some more…

Survey – Does adapting agile methods increase the chances of successful adoption and lasting change for the organization?

Does adapting agile methods increase the chances of successful adoption and lasting change for the organization? If you’ve read a few of my blog posts you will know my opinion is a strong “of course!”

I believe we need to be agile about how we do agile. But it would be nice to have some empirical evidence to support this belief. Marion Freudenthaler from Apple is undertaking an Msc research project with the Open University and is running a survey to collect some data. Will be interesting to see what she comes up with…

Suitability of Organisations for Agile Software Development  Survey

Who would have thought Personal Kanban would end up being the counter-measure to stalled Kaizen / Continuous Improvement?

Paying attention to Management attention

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?

Experiencing Kanban System Design

As a Kanban Trainer I often introduce people to the Kanban Method for evolutionary change and the aspects of evolving system design and how they drive improvement. I’ve been looking for ways to make this introduction and exploration of the Kanban Method a more interactive experience. I love Russel Healy’s Kanban Game both in physical and online form. It is THE best way to experience how to manage the flow of a Kanban system using a GIVEN system design. I see it as an experience of “Visualize”, “Limit WIP”, “Manage Flow”.

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.

AgileSparks Flow Simulator
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


Why Agile Testing


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.



What does Kanban mean for the Project Manager?

This post is for you Project Managers / Program Managers / PMOs out there, or to be more generic people focused on orchestrating the successful on time delivery of commitments to customers. I will use “Project Manager” in this post just for the sake of simplicity.

If you are a Project Manager, you might have a couple of questions about Kanban:

  • How does Kanban and its Flow-based delivery model help me do my Job?
  • Assuming someone is considering using Kanban how is that going to affect my Job? Namely my ability to make promises I can keep and my ability to know what is going on and act accordingly as well as represent the current delivery picture up and to the customer?
  • Why do I care about this Kanban Method of evolutionary improvement and what does it need from me?

In the last couple of years I worked with several organizations which used Kanban in a project/release delivery environment and had the chance to help Project Managers deal with those questions. While a lot of the Kanban lore focuses on management of capabilities, I think we need to have good answers for those focusing on delivery as the lack of clear answers/knowledge in this area can impede evolution towards Flow while having the delivery/project leadership on board will help accelerate the evolution.

This is why we are creating a Project-Management focused Kanban Training offering in AgileSparks. This LKU accredited training provides the core Kanban knowledge any practitioner should have and goes way beyond it in focus on Project/Delivery management scenarios. In this training we will learn and experience:

  • The benefit of Flow-based delivery towards reduction of Risk, Planning Overhead
  • How to use Flow-based planning approaches to make commitments both for discrete deliveries as well as big projects.
  • How to track projects in a way that will visualize and drive Flow thinking WITHOUT making any change to the project delivery approach or tracking tools.
  • How to deal with scenarios such as new opportunities, changes in resources, dependencies in a Flow environment.
  • How evolutionary improvement using experiments and steady delivery on promises can coexist
  • What capabilities/parameters I as a project manager should focus on to improve my ability to deliver aggressively while honoring my commitments AND surviving healthy for the next round.
  • Sensing what is going on and what counter-measures to try in various situations

We will use scenarios and questions I and real world Project Managers had to deal with while working on Enterprise-level projects/programs, as well as your questions/scenarios!

If you are in one of the following situations, you should consider coming to one of our upcoming training workshops:

  • Your organization is considering Agile/Kanban and you want to understand what it means for you and how you can continue to deliver on your responsibilities or even do a better job at them.
  • Your organization has gone Agile/Kanban and you feel there are no real answers about Making Promises and Delivering, Planning and Tracking the Big Picture Project.
  • You feel you have a steady delivery mechanism but you are not maximizing the potential of the organization’s capabilities and want to see how to take a step forward without sacrificing the predictability and stability that you now have.

If you have questions or want to learn more you can either leave me a comment or contact us at AgileSparks.



Making promises you can keep WITHOUT Scrum Sprint Commitment using Classes of Service

How can we make promises we can keep without a commitment to the sprint content?

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.

The Scrum Sprint Commitment/Forecast as an Expectation

Disclaimer –  I’m a well-known Scrum Sprint Commitment basher. But in the last few weeks especially while processing the Lean Conference Boston Keynote by Steven Spear I have a fresh perspective I wanted to share.

There is no improvement without learning

One of Spear’s key points was that there is no improvement without learning. There is no learning without surprises. There are no surprises without setting expectations. Specifically challenging expectations that will be missed occasionally. See a quote from one of his Harvard Business Review articles about how Toyota really learns:

We argued that Toyota’s much-noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident. Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process, and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered.

I got a copy of Spear’s book the High Velocity Edge at LSSC12 and I intend to read it in the upcoming months to try and get more insights into this concept of Expectation-driven learning.

Expectation-driven Learning applied to Scrum

So one way to see the Sprint Forecast is as setting an expectation of how much work is going to be done before it is performed and committing to try working as effectively as we can to try and meet that forecast. Sometimes there will be a gap between our forecast and the real amount of work done, which is an invitation to learn about our real capabilities, our processes and our people and drive new experiments for how to deliver at a higher level. I see this as a healthy use of commitment.

This again explains why a team that meets its forecast each and every time might be a predictable team but not necessarily a hyper-productive team and for sure not a learning team. For learning you need hypothesize that you can stretch yourself a little beyond your current capabilities supported by an experiment for how to achieve that stretch. But hypothesis and experiments have this nature of sometimes succeeding and sometimes failing. So you would expect to sometimes miss your forecast and have to learn something from it. Again, no learning without surprises.

This frame of thinking by the way brings Scrum and Kanban even closer in my perspective. It re-emphasizes how working in a pull system driven by commitment to either WIP Limits or Sprint Forecast are very similar concepts of constraints and expectations – explicit process policies that drive learning. This learning is not less important than the ability to predict delivery outcomes that comes together with working in this pull system.

What can we do different tomorrow morning

Scrum Team? Make sure you set challenging sprint forecast, supported by clear hypothesis and experiments of how  you will reach that forecast while still in sustainable pace. Commit to try. Even more importantly commit to learn if the experiment fails. Remember this is a safe-to-fail experiment.

Working with Kanban? Make sure you set challenging WIP limits, supported by clear hypothesis and experiments of how you will sustain this WIP limit while still delivering. Commit to trying. Even more importantly commit to learn if you need to exceed WIP limits. Remember this is a safe-to-fail experiment.

Note the similarity between the two environments! same phrases chosen on purpose.

Manager? Give your teams permission to experiment. Expect them to experiment. Expect them to commit to trying and learning. DON’T expect them to always meet the forecast/WIP limit or you will slow down learning. Expect them not to ignore their commitments. Expect them to come to you with requests for assistance and ideas how to achieve lower WIP limits or higher sprint forecasts. Expect them to try some of those ideas on their own without any help. Finally and probably first thing to do – Teach them that there is no hyper-productivity without improvement. There is no improvement without learning. There is no learning without surprises. And there are no surprises when there are no expectations.



Do we need stack ranking in a kanban system?

I want to talk about a kanban system design issue today.

Do we need a way to portray full stack ranking of cards throughout a kanban system or is it enough to see stack ranking per lane ?

To elaborate – sometimes it feels necessary to convey the priority of cards and have a way for that priority to travel with the card throughout the system. A way to achieve this is to allocate a running priority such as 10, 20, 30, etc.  to cards. Those of us with background in the “Basic” programming language will understand the numbering scheme – it allows for inserting other cards between priority slots later on.

Since not many electronic kanban systems support this, I was forced to think again about whether this is actually necessary and reached a conclusion it is a bit redundant if a few key assumptions are made.

Assuming all cards are of the same “class of service”, it is typically reasonable to adopt a “FIFO after pulling into WIP” policy – which means that after a card is pulled into work, we should make all effort to finish it even if it originally had a slightly lower priority than other card options. If we pulled it we had a good reason and it is less relevant anymore – lets just get it over with. If that is the case, after pulling the card all we care about is FIFO – so stack ranking within a lane as well as lane position should be enough – just pull topmost card from the rightmost lane possible to obey the FIFO (or look at start date).

The plot thickens when there are more classes of service. The policies for Fixed Date and Expedite deal themselves with priorities and pull order so I won’t elaborate on them here as they’ve been covered elsewhere in Kanban literature in depth.

A class of service that is not often discussed is a “stretch” card from a release backlog. Essentially a card that is a “wishlist” but not something that was committed as part of the release, so we prefer not to pull it before committed scope for the release. The policy we probably want to have is to always pull “scope” cards before “stretch” cards when possible. Even if a “stretch” card made it into WIP we might want to bypass it if a “scope” card is catching up. (You might wander why a “stretch” card would be pulled in the first place – the typical answer is resource capabilities – “scope” cards were skipped because of lack of knowledge until a “stretch” card was reached – this is an indication of lack of capabilities versatility and should be monitored and improved on by the way).
So basically all we need to support this policy is a visualization of the fact that the card is “stretch” scope. It is possible to use a “low priority” indicator for this. Maybe it is better to have it as a different card type to make it easier to filter it out when tracking release progress using a Cumulative Flow Diagram Burnup Chart. You might want to display “stretch” cards as scope completed, or ignore them and just track completion rate of the “scope” cards. I would think that is preferable.

So bottom line seems like full board-wide stack ranking is not required in most cases. Classes of Service or a few priority pools can suffice for most reasonable pull policies.

What is your experience? Do you track priorities in a different way?

Impressions from Lean Systems and Software Conference 2012 Boston

As I prepare to check out from the Boston Seaport Hotel which was the venue of this year’s LSSC conference (and did a magnificent job hosting us!), here are my highlights/impressions of the conference.

The buzzword of the conference seems to have been “Lean Startup”. It permeated into many talks (including mine) in two main aspects – One was the classic product/customer-focused Lean Startup as an alternative narrative to Lean/Agile. The other was taking the ideas of fast cycles of Validated Learning and adopting them as a narrative for the approach to change. This came up in Jeff Anderson’s ambitious and thought-provoking or even provocative talk about the transition participation engine as well as in my attempt to “fix” continuous improvement.

So what is Lean Startup for Change – LS4CHG

Lets try to summarize real quick what we came up with in a short lean coffee session about this today in LSSC12.

Lean Startup for Change is applying the concepts of Lean Startup to Change programs. It comes real handy when you have a complex environment where you don’t know exactly what will work for the organization context (market) and you want to test it rigorously until you come up with an approach that can stick/grow effectively in a way that creates a sustainable change program.

The flow can look something like this:

  • You identify a problem/dissatisfaction at the capabilities level of the organization. This can be – we are not able to meet demand, we need to scale without increasing overheads, we need to improve quality, etc.
  • You create a change model (maybe using a kind of canvas – riffing on Business model canvas or Lean canvas or closer to A3 who knows – we need to find out what works best…).
  • You identify risky assumptions/hypothesis in this model and design experiments to test. The risks can be value risks – whether we actually know for sure that the change we are introducing will bring value ASSUMING it happens. Or growth risks – We know it will work but we don’t know IF it will happen/stick/grow. This is similar to the value/growth hypothesis and metrics in Lean Startup.
  • Some times Value hypothesis will be hard to test if there isn’t enough information/history about the system, and therefore a growth engine that brings the system to a level where it generates enough information (e.g. by having enough teams use kanban to manage their work) might be the first priority, as a MEANS to establish the Value experiment.
  • With the hypothesis you start with, design the Minimum Viable Change that will test your assumption about how things will work. If you are aiming at growth, your MVC needs to focus on how you will grow the system and measure things like virality of teams infecting each other (virality), how many teams infected actually get interested about this (conversion?), start using it (activation), and keep using (retention) and infecting others. You run this MVC and see what are the results by measuring them (How? separate and VERY though question – but it comes down to looking at behaviour in some way. need to do it in a reasonable and humane way though – e.g. how many teams contacted the local coach about a practice they saw elsewhere without being forced to start). You then start to tune the engine. Play with things that might affect growth e.g. the way you train, the way you coach, the way you present things, who’s in charge, etc. When you see you have a working growth engine you can stop experimenting and pursue the winning approach you found. If you see your experiments are not really getting anywhere you consider pivoting to another kind of growth engine altogether, or even to another kind of change engine.
  • When your growth engine worked well and you have a good population of people using the system you can start looking at the value hypothesis. You have enough of a sandbox to test your assumptions on what will bring value. You design MVCs that are aimed at bringing in value like improved quality, faster cycles, improved customer satisfaction, etc. You execute an MVC and then measure its effect. There is a challenge here because some of these will take time to see the results of (e.g. Refactoring?). Work real hard to defining the MINIMUM viable change. All these MVCs are not a test whether the “change approach” is possible, just whether it is a good fit for the organization’s context (so basically not solution-space uncertainty but problem-space uncertainty – the natural habitat of MVPs…)
  • After tuning the MVC until you see you are meeting your value hypothesis and have a strong change engine you can pursue it by deploying it elsewhere, and move on to testing new hypothesis that can improve performance further.
  • I’m feeling quite comfortable thinking about this in an A3 for each MVC kind of form. Maybe need to take some things from the Lean Canvas into this A3, but most of the stuff is already IMO.
  • Bottom line you tested uncertainty at the problem space – whether we are indeed solving the right problem for the organization, as well as the growth space – are we running the change in the most effective way.

One comment from the discussion was that several of us Lean/Kanban practitioners feel that we don’t really have to validate the assumption that Kanban will provide value to the organization. We are quite sure that it can serve as the diagnostic that will stimulate improvement. What we are not sure about is how to best take on Kanban in an organization. And that is why the growth engine/hypothesis is so important and why it might seem that we are focusing on mechanical implementation rather than a value driven one. We see Kanban as one way to enable the Value-seeking MVC via its fast method of installing a system which will visualize what is going on and invite potentially value-improving experiments.

Just initial thoughts from a very long day at LSSC12. We are keeping the discussion alive with hashtag #LC4Chg on twitter as well as on kanbandev. Join us and let us know what you think about this.


Experiences for a Kanban trainer in a Scrum Gathering

Stranger in a strange land

This week I attended and spoke at Scrum Gathering Atlanta

It was a mixed experience for me. On the one hand it was interesting to see the focus of the Scrum crowd on the other hand it was a bit hard for me to find content to connect to and it was a bit of a stranger in a strange land, mainly because I’m all the way from Israel and the conference was a very regionally focused one. I’m not someone who immediately makes connections in conferences and not many of my blog readers or twitter friends were there…

General Conference Highlights

I enjoyed the keynotes I attended, mainly Tanner Corbridge’s Accountability talk based on the “Oz Principle” model. I was familiar with the model but this keynote deepened my understanding and came at a time where it is applicable to several situations I’m thinking about. Tanner is also a brilliant keynote speaker. Engaging, Fast, just the kind I love. James Grenning also delivered a very good talk about Demanding Technical Excellence. It was well built and he is a good speaker as well, but it didn’t provide any new thinking from my perspective. Just emphasized things I already know and advocate strongly already. One piece I liked is the physics of Debug Later Development versus Test Driven Development. I missed Clarke Ching’s keynote but I heard it was good.

The track sessions were more of a mixed bag (as they typically are in many conferences). I found several time slots where I wasn’t really passionate about any of the topics, and some where I was interested in the topic or presenter and was disappointed from the level of the session or quality of delivery. It might be that I’m losing my patience for sitting and hearing sessions, but OTOH there are conferences where I’m glued to my chair (typically the hashtag starts with #L for those ones…). I found many of the sessions to focus on the technical aspects of Scrum and Agility, not enough talked about the big picture, systemic view. Ideas like Social Complexity Theory, Lean, Real Options, Risk, Dealing with executives were nowhere to be found, at least in the sessions I attended.

The sessions that shined were those dealing with the softer aspects – especially Embracing Conflict by Lyssa Adkins and Michael Spayd. I took several actionable ideas from that session – thinking about Positivity Deposit/Withdrawal model as well as using the constellation exercise more. I used it in a client engagement 2 years ago but then stopped for some reason. It is a very strong exercise done right. There was also a retrospective techniques session by Kate Megaw and Brian Rabon that was well designed and had the side effect of retrospecting on the conference itself (A trick I employed in my own session as well…)

The openspace was an active and engaging one in general. I ended up being a bit of a bumblebee though. The session I liked most was a Build your own Scrum session that Adam Weisbart delivered – it is an exercise for introducing scrum or refreshing knowledge of scrum, that can be delivered as 30 minutes or longer 2-3 hours for a more comprehensive version. Quite cool and I will try it next time I have a chance. I also suggested and tried some modifications to the way it is run (e.g. use team estimation game while building your own scrum to make it a more fair group collaboration process).

The openspace culminated with an hour of Kanban Q&A I facilitated. Finally I had a chance to expose people to the Kanban Method for Change. Room was quite full, people came up with questions, we prioritized and answered them, mainly with me leading it chalk mode but driven by questions and answers. People took many pictures of the drawings on the board but I didn’t have the time during the session so no examples sorry…

The topics that came up were:
  • What is Kanban – Did a 10 minute session describing the foundational principles (start where you are etc.) and the core practices (visualize, manage flow, make policies explicit, THEN limit WIP, improve collaboratively). People appreciated leaving the Limit WIP as the last core practice.
  • Experiences using Kanban alongside Scrum –
    Described Scrumban – Using Kanban to improve the flow/leanness of a Scrum instance – gave the story as an example.
    Described starting with Kanban and then using elements of Scrum using the an example of Discovery Kanban and then feature teams. I also mentioned that the value of starting with the Discovery Kanban was the involvement of managers in it up front, leading by example, experiencing, and that now when starting a feature team it is quite smooth and happening while I’m in the US. People were quite happy and nodding to hear about this.
  • Which is better Kanban or Scrum? I added WHEN to that question… and we discussed revolution versus evolution, that if you are REALLY able to do Scrum RIGHT go for it. But if you are doing Scrumbut including no real feature teams but chains of component or semi-feature teams you should consider Kanban.
    Emphasized the “its only the start of the journey” and they both are meant as inspect and adapt frameworks using my mountain sketch which people really liked.
I brought 25 books of “Holy Land Kanban” and all are gone and some people didn’t get a copy and I promised them an ebook by email. I was able to connect to several people after that session, some of them are also coming to Lean Conference Boston next week.

My track session

I delivered a talk about “Continuous Improvement is broken/stalled – WHY and WHAT can we do about it”. The talk was well received from feedback I got from people who were in the room. I was also encouraged that people really loved the Prezi format and didn’t find it confusing or sea-sickness-inducing. I’ve been focused on making it an easy to consume Prezi so it is good to hear that feedback.
This was one of the more interactive conference sessions I ran and it felt good, closer to a typical workshop session which is my natural habitat…

In an exercise of prioritizing the Improvement Manifesto people emphasized the Focus and Learning pillars of my talk, which are my favorite concepts as well. We did several kinds of discussions around what agile practices/choices are sure bets and which are hypothesis, we tried to design a minimum viable change, and we also talked about what is the Kanban Method for Change just in case… The Prezi is available below.

Also – Mike Vidzos and I had a short chat about the talk which was recorded as a short podcast


Bottom line it was an interesting experience. On a personal level I was able to reach out and spread some of my beliefs and knowledge which feels good. In spite of coming in as a stranger to this community I was able to make some connections that will at least continue on twitter I hope.

I also learned a couple of new things in areas I don’t typically focus on and refreshed the importance/usefulness of other practices/exercises I’m familiar with.

It was overall a well-executed conference and I’m glad the organizers invited me to speak and participate. I look forward to checking out future Scrum Gatherings to see where this world is going… Anyone for Barcelona in October?