Tag Archives: Continuous Improvement

The Scrum Sprint Commitment/Forecast as an Expectation

Estimated Reading Time: 3 minutes

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.



“We are already Lean/Agile” – Really?

Estimated Reading Time: 3 minutes

These days more and more organizations think they are Agile

A couple of years ago when you talked to people about agile a common response “why should we”, “it won’t work here”, or “so this is the new fad? What will come next?”

Times have changed. And a sign of the fact that agile is becoming more mainstream is that it being diluted and a common response these days is “but we are already agile!”. I want to share a couple of questions to see if you are indeed agile.

What does it mean to be Lean/Agile

At a very high level what does it mean to be agile ? At a first level agile is an approach to development that embraces the complexity and uncertainty in both demand, specification and implementation implications by working in short cycles on small batches of work, constantly seeking fast feedback, and empowering people to work together focused on clear business goals, at a sustainable pace.

A second level of lean/agile is about embracing the complexity of the systems/processes used to take software from idea to realized value and using an inspect and adapt approach to let better approaches emerge. This is a much more pervasive aspect of lean/agile. Organizations fail to realize the real power and improvements are as a result of multiple iterations thru process experiments, always aiming to achieve goals of better delivery capabilities.

Are you delivering in an Agile way?

When you hear someone talking about being agile ask them:

  • Do your users/business stakeholders consider your delivery cycle fast enough?
  • Are you developing the Right things? Do you use your agility to drive small features to production to validate the value of a certain direction and then continue to deliver a pipeline of more small features while constantly evaluating feedback?
  • Are you doing things the right way? How much rework is there in your work? How much of the demand is generated by not doing things right the first time?

Are you improving in a Lean/Agile way?

And then ask some more questions that will dive deeper into the improvement aspects of lean/agile:

  • How often do you stop to reflect on our performance/capabilities?
  • Do you have a capabilities goal/condition you are striving for? How many people are aware of it?
  • How do u know your current state compared to that goal?
  • Do you run process experiments aimed at improvement towards a target condition we are focusing on?
  • How many of these process experiments do you try in a month?
  • What is the cycle time from deciding to work on a process improvement to finishing an iteration of the experiment on it?
  • What are the current main obstacles to improving towards your goal? How long have you known about them?

What it means

You might find that you have an “agile” organization that is not so agile when considering the service provided to the business.
In many of those cases when you dive deeper you will find a weak, unfocused or even nonexistent improvement engine/culture and a static process/system.

Doing scrum sprints, user stories, or kanban boards is just the starting point of the agile journey.

The main event is improving. Practices such us limiting work in process or focusing on a single sprint help with that.
There is a whole set of approaches beyond that – A3, five whys, retrospectives, operation reviews, statistical process control, the Toyota improvement kata, solutions focus, theory of constraints and many more – all used to improve.

Are you ready for the real world of lean/agile?

You might find this recent prezi useful to look at these multiple layers of improvement and the various approaches used.


Israeli Culture and the Evolutionary Revolution

Estimated Reading Time: 3 minutes

Yesterday I was listening to David Anderson on Joe Dagger’s Business 901 Podcast. One of the interesting points were about the differences in Cultures driving to different attitude towards the Kanban Method between the US and Europe. Basically what David and Joe were saying is that there seems to be more traction for Lean and evolutionary change in Europe. The speculation is that Continuous Evolutionary approaches are more aligned with corporate and national European cultures. Europeans think they are more patient than Americans. Americans look for fast results and are more revolutionary. Go hear the discussion – it’s around 03:30-05:00 in the podcast.

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

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

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

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

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

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

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

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

Change Program Stall Avoidance 101 & Policies Kanban

View more presentations from Yuval Yeret

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