Category Archives: Scrum

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.

 

 

Experiences for a Kanban trainer in a Scrum Gathering

Estimated Reading Time: 5 minutes

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 FiftyOne.com 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

Conclusion

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? 

Do we need Scrum to get to Kanban???

Estimated Reading Time: 2 minutes

I just wrote a lengthy reply on a kanbandev thread about Using Scrum to implement Kanban and vice versa and thought I would share it here, especially so I can tweet it directly and try to spark a discussion about it in Scrum Gathering Atlanta (where I’m currently at…)

I engaged the conversation when Danko said:

Scrumban….
Well, another mystery regarding the above is whether scrum is an evolution of kanban (which means you evolve to a point that you can start implement scrum which gives you a lot of effectiveness)
Or
That scrum is only “scripting the way” to kanban (which means at the beginning , the company needs some strong guidelines how to operate and then we can leave scrum and start working in kanban since the “right” mind set was set.
My guts feeling is that the second one is the “right” thing thus at higher level of scrum we start to eliminate the meetings, roles and so on and start focusing on how to do things better while we are equipped with good technical and mind set tools
My take on it is that indeed as teams grow more and more mature they can shed away the scaffolding / learning wheels that Scrum provides and achieve better more effective flow.  But that is not to say they reach Kanban.
Kanban or at least the Kanban Method for change leadership does not define the destination. It is not something you reach. It defines the approach you take on the journey there.
You use Kanban to search for the process that works best for you. ( I recently started calling it the search for process/context fit – like product/market fit in lean startup)
I see Scrum the same way. A different approach to the search though. And scrum having more process and prescription confuses people into thinking it is the destination. I see the current attempt to move from Scrum-but to Scrum-and as a positive way to convey the message of searching and inclusion and emergence more clearly.
From this perspective one can ask whether at the early stages of the search it is more effective to use more perscription/change or minimum change possible. The answer probably is it depends.
But Kanban says to very critically examine every aspect of the change and consider whether it is a must.
I’ve seen teams that accelerate through the low maturity process very fast with Kanban without any sprints/roles. So have many practitioners on other case studies reported here on the list and in the industry conferences.
There are of course many cases of teams accelerating through low maturity using scrum.
As well as (too many) teams/orgs that stay in the base camp of low maturity and never continue the journey with Scrum OR Kanban ( I know a certain someone speaking about that today and next week 😉
At the minimum an understanding of Kanban should drive people to critically consider what is the minimum viable change for their organization when they start. If they choose to include Scrum they should be able to elaborate why and not just because Scrum says so

What do you think?

Guest Post – Is starting with Kanban really easier than with Scrum?

Estimated Reading Time: 4 minutes

Today I’m proud to host a guest post by another AgileSparks coach – Yael Rabinovitz. Yael has been working with several clients on Scrum implementations and has recently started using the Kanban Method (I wonder who gave her that crazy idea…) and is sharing her thoughts about the first steps into both approaches. Without further ado, here’s Yael:

 

Is starting with Kanban really easier than with Scrum?

Kanban is often described as a way to achieve evolutionary change in an organization, creating less fear and resistance than more “revolutionary” approaches such as Scrum. Kanban indeed respects current processes. For example, in its first steps it does not impose role and responsibility changes, but encourages continuous small incremental and evolutionary improvements to your current system. But is it really an easier way to launch a change process? Always? The last few Agile implementations I was involved with that used Kanban as a starting point made me contemplate this topic. Here are some of my thoughts.

 

Implementing Kanban seems to be simple technically. Just visualize your current process, build the Kanban board and describe your process as a pull system. Kanban does not prescribe specific practices, but the team is expected to apply lean thinking tools such as limit the WIP, focus on flow, optimize the whole, stop the line and fix (focus on quality), find bottlenecks, protect the team from external interruptions, etc. This requires high maturity from the team. Unfortunately, in many cases, teams find themselves struggling at the starting point, especially when attempting to apply the “limit the WIP” step. This can be extremely difficult and requires good collaboration and shared responsibility between the development team
and the PO in order to allow balancing demand and
throughput. When this collaboration is not mature, teams tend to get stuck and find it hard to move forward, which leads to frustration and increases resistance to the change.

 

Shape the path – Script the way

Scrum’s prescriptive nature is more suitable for such immature teams as it “scripts the way” (from “Switch” by Chip Heath & Dan Heath) and provides best practices and definitions of the processes to be followed (daily standup, planning, demo, retrospective, clear definition of the PO/team responsibilities). Scrum provides a practical framework that makes the mindset shift easier, as teams can rely on the framework in this “SHU” phase (“Shu-Ha=Ri see: http://alistair.cockburn.us/Shu+Ha+Ri). The clear definition of the PO role vis-a-vis the team provides the needed collaboration and WIP is limited implicitly by defining the sprint’s backlog, which I believe teams find more natural to grasp.

Small work units

Another point to consider is the need to break features into small pieces or user stories. This is a huge challenge that teams usually struggle with from day 1 in both Kanban and Scrum. This is fundamental to improving the flow in the system, thus reducing cycle time in Kanban, and creates the building blocks of the product backlog and sprint backlog in Scrum. I find that Scrum guides you more safely and clearly in this task than Kanban, as the framework and practices for creating stories are explicitly built into the Scrum process. Questions like: who is the owner of the stories? When should the stories be ready? What is a good story? Who approves the results and when? The team has built–in answers when it uses Scrum as a starting point.

The energy for change

It is also very important to consider the “energy” that the organization needs to have in order to change. Agile practically requires the organization to “reinvent” itself and, in many cases, the beginning of the process is an excellent opportunity to do just that. At that time, the right levels of energy exist, with the “buzz” created by training and management’s attention, as well as the willingness and courage to make a dramatic move. Scrum suits this “let’s make a revolution” mindset much more than Kanban, which requires stamina, patience and long term thinking. Most teams don’t have the time and patience for ongoing improvement cycles – they want results now. They are willing to risk, speculate and go along with revolutionary ideas rather than patiently wait for evolution.

Early success

Being able to achieve small wins early in the process provides a lot of “back wind” to the process. Scrum’s sweeping nature allows identifying these small wins quicker, thus injecting positive energy into the process at a much needed stage. The adoption of cross functional teams and creation of a rhythm in the organization, with demos and retrospectives quickly gives a sense of progress. It is important to pick low hanging fruits and produce results quickly.

I found that in many cases, if a momentum for revolution exists both in management and teams, Scrum’s constraints are much better for keeping the teams focused and accountable. Once you reach a point where you have a backlog with well defined stories and you are mature enough to go to the next leap, it is time to implement Kanban in order to optimize the whole and focus on the flow of value across the system, improving your cycle time from start to end.

So, should we start with Kanban or Scrum?

The only right answer is: it depends. It depends on the organization’s state, the scale of necessary changes, the desired outcomes and the problems and pains that triggered the Agile initiative.

What I attempt to do in this post is challenge the widespread myth that Kanban is always the easiest way to start. I have found that, when management is on board with the right mindset, starting with Scrum can be safer and easier. The Retrospectives in Scrum provide the evolutionary mechanism Kanban advocates that allow the organization to continue and make small incremental changes and continuously improve beneficial aspects and weed out harmful attributes

Start with Kanban or Scrum but, since you are interested in this journey, it is important to start! Begin, keeping in mind why you started and what you are trying to achieve .We don’t want to waste our time with too much upfront planning anyway, after we begin the journey, the steps we should take to move forward will unfold.

“The Road goes ever on and on

Down from the door where it began.

Now far ahead the Road has gone,

And I must follow, if I can,

Pursuing it with eager feet,

Until it joins some larger way

Where many paths and errands meet.

And whither then? I cannot say.“…

 

Hobbits walking song, “The Fellowship of the Rings”,J.R.R Tolkien

 

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.