Tag Archives: קנבן

Check out a Prezi for one of my Kanban Training workshops

Leave a reply
Estimated Reading Time: 1 minute

Kanban Training on Prezi

I decided to get back to Prezi as an alternative to Powerpoint. Its capabilities seem to be a good match for my kind of materials – Visuals of boards, charts, etc. where you want to zoom in on details, show flows, etc.

A specific opportunity is coming up that is making that even a better idea, so I finally took the plunge 2 years after my last real use of Prezi I dove in again. So much fun, spiked with a few frustrations on missing features. But being a Lean coach, and someone talking about Lean Startups, I can recognize effective MVP (Minimum Viable Product) when I see it. The iPad viewer app is one… (don’t expect it show PDFs just yet 😉

Anyhow, I’m making this available to the world, with the hope some people will enjoy it, and might even become interested in kanban training workshops at AgileSparks

Want to improve effectiveness of Product Management? Here are some ideas for metrics to look at

Leave a reply
Estimated Reading Time: 1 minute

I recently worked on some measures/metrics that help answer the question "How effective is our product management process, and how is it contributing/affecting the overall performance of our product development line"

Here are some slides from slideshare about the topic. I might write it up in a more elaborate form in the future. 

If there are specific questions about concepts I mentioned, mention it in a comment (or on twitter or something) and I might write up a specific area. 

If you have examples of dashboards showing similar measures in practice, I'd love to see!

 

Want my elevator-pitch answer to what is Kanban for a Scrum rookie?

Leave a reply
Estimated Reading Time: 2 minutes

 

Our coaching team at agilesparks runs into this question a lot. 

Many of the teams we are working with are familiar with Scrum and using it. Other teams are just now going into Scrum. 
Since kanban is becoming a hot buzzword, we often get asked – so what is this kanban thing? How is it related to Scrum? 

We needed a good answer, that depends on the context, the amount of time you have to answer, and the maturity of the person/forum asking.

In this post, I will try to give the answer you give when someone finds you in an elevator, the last 2 minutes of a workshop, or on the way back from lunch, in short both you and him have a very short time to give an answer. 
Add to that that his knowledge is quite limited. 

Here goes:
"What you might have heard about kanban is that its scrum without sprints. 
I would say that Scrum is an agile approach where the container used to protect, focus and challenge the team is the time-boxed sprint. 
Kanban is another Agile approach! In Kanban the container used to protect, focus and challenge is limiting the amount of things we do in parallel – Limiting the Work in Progress. If you need to remember one thing – remember and lookup Limit the WIP"

If you are in a very high building, you can also add:
"Mixing the two can lead to beautiful results – called ScrumBan. Also one of the biggest differences is in how an Agile change usually looks like with Scrum/Kanban. Scrum is a revolutionary big change up front approach. Kanban is more of an evolutionary laser-focused approach where you find where to focus (using the WIP limit as the challenging force), do something there, continue to the next area to focus on. If you've heard of TOC, its quite similar in how it manages change. "

Now all of this is very simplistic, but probably concepts like Cycle Time, the Lean origins, and other Kanban goodies are too much for a rookie with very short attention span at the moment. 
The important thing is to grow an interest for what this WIP limit means and look it up. 

If productivity experts tell me to keep email closed most of the day – why shouldn’t I avoid looking at defects for most of the release?

1 Reply
Estimated Reading Time: 4 minutes

An interesting question was raised to one of our coaches at Agilesparks. 

Question: Isn't it more efficient to wait till the end of the release and then all together handle all the bugs?

One of us answered that same like you probably prefer to answer emails throughout the day rather than at the end, you want to deal with bugs during the sprints. 

I of course fully agree that you need to deal with bugs during the sprint/release, or in other words keep the Bugs In Progress number limited. (Anyone for Limited BIP society?)

But this answer doesn't convince me. 

 

 

many productivity experts (e.g. http://www.inboxoverload.com/time_management-partI.htm) will tell you to turn email off for most of the day, and open it in specific slots throughout the day, to avoid context switches, etc. This will protect your flow on the tasks you should be focused on. This is btw different between managers and makers, and is similar to how their calendars look like (see a great post by Paul Graham ). I would say that the more reactive your role is, the more responsive you probably need to be to email, and the less actual creative flow you can expect. When you do need to make something, TURN YOUR EMAIL OFF. 
 
I would add a caveat to this rule to say that in collaborative environments like Agile teams, care and balance need to be applied to allow both Flow to happen, as well as collaboration and fast feedback/osmosis in the team. 
 
Now what do we tell those makers of software, that we instruct to ignore their EMAILs for most of the day? that they need to deal with defects as soon as possible? Why?
 
The reason its different is that emails during the day don't really "ROT" like the vegetables in the market, do they? or at least a major part of them doesn't.  The cost of addressing an email a few hours late is not much different than addressing it a few minutes after its sent. 
Again, the caveat is those decisions others are making in our team, that they want fast feedback and collaboration on. We should find a way to allow those to come in (maybe by coming by and talking?), maybe by marking the emails from the team as higher priority, whatever. 
 
With defects or decisions in software development in general its different. the cost to deal with late feedback is exponentially higher as time goes by. Also, having the large inventory of those issues risks the release since you don't exactly know how long it will take you to fix all of them. 
 
 
Back to email – yes, if you keep all emails to the end of the day, you don't know exactly how much time it will take to fully address them. but you can decide whether you are scope-driven so you get to inbox zero every day (check out 0boxer btw for a nice gmail extension that makes a game out of this…), or whether you give a time-slot priority based and do what you can, and periodically deal with the overflow. 
For sure, probably reading your mailing lists (e.g. kanbandev, agile-testing) are all highly valuable, but can be described as intangible benefits to the day, so can be scoped out if necessary. Again, some of us actually see participation in the lists as a tangible ROI, but then probably the way to deal with that is put it on our schedule, think about the appropriate SLA, etc. If its important enough to answer in realtime – then by all means make kanbandev a high priority email in your inbox and let it thru. Have it SMS you, twit you, whatever. But be aware of the decisions you are making. This is similar to managing demand for a product development group…
 
The decision about the level of WIP and cycle time you are shooting for should be an economy-driven decision. both context switches as well as late feedback have a price, in the waste they create. you need to weigh the price and decide what is best for your context. 
 
The reality of product development in most of the projects out there, seems to be that its MUCH more economic to build quality in and don't let defects rot outside in the sun. 
 
PS If MY inbox was turned off, I would probably not see this email from my colleague and write this post. Now what would be the price if I answer him in the evening? Probably the cost of answering and dealing with the feedback would be the same. Thinking about it caused me to context switch and write this blog post. Now I usually just defer answering to such emails, and writing blog items (I use rememberthemilk.com and have various draft post ideas there that I get to at some point). If I was perfect, my algorithm for when to answer and when to defer would really be economically sound. Since I'm not, it's probably more about enjoying the moment and the journey. Which is something this colleague of mine especially appreciates 🙂 you know who you are!
 
 

Encouraging Feature-level progress tracking in Kanban

Leave a reply
Estimated Reading Time: 4 minutes

One of the key questions project managers and senior management in general ask themselves and their teams on an ongoing basis is – "Are we on track to deliver the scope we committed to, on time". In some environments "on budget" is added to the question.

If you are talking about a Release Scope, the answers are quite similar whether you're doing Scrum or Kanban. If you don't care too much about the budget aspects, a Release Burnup can show you the commited scope, the committed date, and the actual progress in working software towards that goal – Plan versus Actual. If you ARE interested in the budget picture – committed budget versus actual, and are we on track to finishing the release with the budget we committed to – use AgileEVM on top of that. (http://www.infoq.com/articles/agile-evm is a good place to start)

Basically for all of this – you are measuring the amount of done features work compared to the amount of features work originally planned for. Whether sized using effort days, story points, function points, the idea is the same. 

In a conference a couple of months ago I talked about Agile Release Management and covered this subject somewhat. You can check out the slides at http://www.slideshare.net/yyeret/managing-projectsreleases-using-leanagile-techniques

I would add that this expectation of management is what we call Predictability in the Kanban world, and based on some encounters I've had with senior management, we as the Agile community have not been doing a great job at connecting to the expectation of Predictability. In many cases its the opposite – we create the impression that Predictability is a lost cause because everything is Agile. 

In Kanban we try to better connect to this expectation of Predictability/Commitment to the important things. Senior management doesn't care about committing to a sprint goal and meeting it. They care about meeting commitments to deliver a release on time and with feature highlights communicated to the stakeholder community. They care about meeting commitments to deliver certain features on time to internal and external parties that count on this feature to continue and do something else. 

Predictability will continue to be important. The way its measured might change. For now, most teams/projects are indeed evaluated based on the answer to "Are we on track to meeting the release goal on time". We should support those teams with an approach that complements their kanban flow-based workflow. The methodology is all there if you connect the dots. 
The room for improvement is mainly in connecting the dots and providing a structured methodology that can be applied as a framework, as well as better tool support. 

What are the gaps?

First, The thinking around CFD needs to switch from history to also a forward-looking predictive chart. What do I mean? 

Most CFDs you see today focus just on an operational view CFD – what is the current state, as well as history, which can help you improve your process, operation. 

I'm Missing a view of the work needed by a certain date, and whether we are on track to achieve our commitments/goals. Tools that extend the CFD to a view that includes current trend, required trend to meet the goal, and trend of requirements churn can answer this question – you see whether the DONE trending towards the overall committed scope is on time or not. 

One more complication is that of course you sometimes want your board to reflect many releases, not just one. You're working to finish one release, and then you move to another. 
In this case, You probably want this view per-Release on the board. 
 

So we need visibility charts that can aggregate the status of several cards e.g. Feature, Release, MMR, MMF whatever you want to call it. In FDD Parking Lot diagrams are a popular way to convey the status of various features/aspects in a Project/Release. An extension of a Parking lot diagram can be to have a mini-burnup of that entity. So beyond just the status (which is basically the current point of a burnup), you can have a mini-graph showing the status of entities comprising this feature. See below for a sketch of how this can look. ( Note that the Warning Indicators box are taken straight from the organizational dashboard page of LeankitKanban. I recently started to explore the capabilities in this dashboard and find them quite useful to help bring a process under control, and the sort of stuff you might want to look at in an operational review). 

The color of each parking lot / feature can easily be derived from where the actual progress is compared to the expected progress curve. The expected curve can be defined to be Linear (yeah right), S-curve based as David Anderson is fond of, or whatever you think the profile should look like. Once you are below the curve, you start to gain reddish colors. Above it – you are green. With Agile approaches relying on Working Software as a measure of progress, you can really trust those colors… Its no more a watermelon (green outside, red inside – courtesy Kent Beck)

For those interested in the details, here is one way a CFD can be extended to provide burnup capabilities. 

 

 

With this in mind, the mini-burnup in the parking lot can be upgraded to a mini-CFD

Now, with a CFD, some more intelligence can be applied to help determine the color/state of the Feature. High level of WIP can be a leading indicator of problem (but knowing about Little's law and how a CFD looks like you probably know that it will be apparent in the burnup being quite flat as well…). I'm guessing that with time, we will learn to study and identify progress risks using a CFD, beyond the basics we currently use. 

Bottom line – my feeling is that in order for Kanban to cross the chasm into the majority of projects/development groups, who are quite concerned with delivering Releases and Features on schedule, not just with trusting the Flow, we will need to provide more and more tools and focus to support this use case. The core thinking is there, the hunger on the part of the IT world is there as well it seems, so lets go out there and make it happen. my 2c…