Category Archives: Uncategorized

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

Estimated Reading Time: 1 minute

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?

Estimated Reading Time: 5 minutes

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?


Impressions from Lean Systems and Software Conference 2012 Boston

Estimated Reading Time: 4 minutes

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 Scrumban?

Estimated Reading Time: 8 minutes

Background

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

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

Starting with Scrum

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

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

 

The basic principles of the ScrumBan Approach

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

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

Core Practices of Kanban applied to Scrumban

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

  1. Visualize – make the invisible work and its workflow visible – Some Scrum teams already visualize work and its flow. One of the keys to effective visualization of a Scrum context are making sure you see the flow of backlog items from early requirement to done. It is not enough to visualize the sprint backlog. It is important to make the flow of work into and out of the sprints visible as well, since many teams have difficulties exactly with this aspect. In addition, Scrumban is typically about visualizing the flow of Product Backlog Items (PBIs) or Stories, rather than Tasks. Tasks are created late in the game and don’t flow all the way. Some teams visualize tasks as well, but it is optional.
  1. Limit WIP – implement a virtual kanban system – Once you have a Kanban board visualizing the flow, the next step is to implement a kanban system. This calls for Limiting the Work in Progress, which in Scrum context basically means you limit the amount of PBIs in progress at any point in time. Once the limit is reached, the alternative to starting a new story is to go and help others deal with their story. This can mean helping others in your expertise area or going upstream or downstream to help (e.g. Developers help Testers, Testers help Product Owner, etc.). Limiting WIP introduces pain. The pain of not being able to do what you’re comfortable with and got used to. We want to channel this pain towards ways of improving the team’s process and policies so in the future the flow will be better and the WIP Limit will be less painful. Improving engineering practices, using techniques such as ATDD, Reducing batch/PBI size, Cross-training, or any other technique can be considered as a way to make the WIP Limit more comfortable. Over time as team capabilities improve, the WIP Limit can be tightened to catalyze even more improvement in capabilities. Limiting WIP is a great way to drive real collaboration at the team level.
    Side Note: that the “Sprint Backlog” itself is a WIP Limit – it limits the amount of PBIs that can be started during the sprint unless all of them are finished. It is a shame that many teams and even coaches miss this point. In any case even if you are treating the Sprint as a WIP Limit, Using granular limits on number of stories active during the sprint will help you improve flow even further.
  2. Manage Flow – with the virtual kanban system in play using WIP Limits, it is now time to run the system and manage the flow. Teams start looking at the cycle times of PBIs/Stories for information on where there is room for improvement. They monitor cycle time/aging in real time to see struggling stories and find ways to help them along. They care about the healthy flow of work (which within a sprint is not less important than whether the sprint forecast/commitment is met – but more on that elsewhere). They start using Cumulative Flow Diagrams which add information about the queues within the system to a Burnup chart.
  1. Make management policies explicit – Some scrum teams make their “Team Rules” explicit. This is a similar approach. You make your process explicit. Both so empowerment can happen – people on the Scrum Team cannot be empowered if they don’t know the process. Self Organized teams cannot work if they don’t have a shared understanding of how work is done. But making the process explicit also helps improve. With the “invisible” process now made visible, healthy discussions about “why we do things this way” or “how will changing this policy affect our flow/results” become easier and happen more naturally. Remember that here we are talking about the team’s policies for how it manages itself. Some of the policies might be driven by the organization and require management approval for changes. Many of them will belong to the team and should be evaluated and experimented with actively as part of the Retrospectives.
  2. Improve Collaboratively using models and the scientific method to implement a “guided” approach to evolution. Start treating your Retrospectives as the place to design experiments. With an idea of how something might improve your capabilities, Plan what you aim to test, what will be the validation that you are on the right direction, and in the next Retrospective review the results and decide whether another round of experimentation is necessary (Pivoting) or whether you can deploy the change as a standard operating policy for the team. Use improvement frameworks such as A3 / Toyota Kata for this process. Invite in models like Reinertsen’s Principles of Product Development Flow to understand the interaction of Batches, Cadence, Heartbeat, Teams, Variability, WIP, Cycle Times, in ways you never had before.

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

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

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

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

Rolling Finish/Start of Sprints

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

Sprint Planning-Lite – Deemphasizing Estimations and Forecasts

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

 

Summary

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

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

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

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

 

 

Go ScrumBan

If you’re interested in some help figuring out if ScrumBan is a good fit for you and how to go about implementing it, AgileSparks can help.

 

Kanban Training after Scrum Gathering Atlanta May 10-11 2012

Estimated Reading Time: 2 minutes

I’m proud to be on the speaker roster for Scrum Gathering Atlanta this May. I will be talking about why I think Continuous Improvement is broken and share thoughts, tips and examples from the field of how to fix it:

Avoiding Stalled Improvement Programs – WHY Improvement is broken and HOW to make Continuous Improvement more appealing to Management?
Yuval Yeret
WHY do many change programs take off with great energies only to stall mid-flight when they run out of management attention/interest fuel?
Something is broken in the way the improvement cycles scale in the organization. We will recall WHY Continuous Improvement across the organization is critical to sustainable agility and HOW to make it stick using Focus and Integration into the management routine, as well as WHAT you can do tomorrow in your organization to drive towards a more healthy improvement program.

I’m excited to be talking in an international Scrum conference for the first time. As most blog followers know I’m known more as a Kanban practitioner/thinker, but am trying to bring the two worlds together. One of the ways I’ve been trying to do that is to introduce people familiar with Scrum to the Kanban Method so they can add it to their arsenal rather than be afraid of it.

AgileSparks decided to take the opportunity that I’m already in Atlanta with lots of people coming to the Scrum gathering as well as several clients of ours who have big offices in the area, and we are opening our Kanban Training on the 10-11 of May just after the Scrum Gathering ends. This training includes a ScrumBan case study as well as comparison of Scrum and Kanban and some tips how to leverage the best of both. It is also an Accredited Kanban Training as part of the Lean Kanban University Accredited Kanban Program.

If you’ll come, we will have a chance to discuss my thoughts about Scrum Sprint Commitment, how Scrum and Kanban are similar in their approach to complexity and some other popular discussion topics. AgileSparks is a company mashing up Scrum and Kanban in almost all of our client projects so we have lots of real world experience to share…

 

Whether you are visiting Atlanta for the Scrum Gathering or local to the area and interested about this new evolutionary approach to improving how technology maintenance/development organizations deliver value, I invite you to join me on May 10-11 for an exciting two days filled with fresh ideas, exercises, and many actionable practices you can try back in the office the day after. Check out the workshop information page and let us know if you’re interested.