When a team is first adopting kanban, they do not typically have reliable numbers for cycle time, and will struggle to make commitments based on a Service Level Agreement. What commitment techniques help during this period, especially when other dependent teams will be at other levels of adoption?
What common techniques do Kanban teams use to make commitments to other teams in their organization?
asked Apr 5, 2011 at 18:55
-
1Great question. This can also be applied to new Agile teams who don't have a lot of past history for sprint velocities.– ashes999Commented Apr 5, 2011 at 19:04
-
Good point! I hadn't considered that, but this is the exact same situation. Perhaps Dean Leffingwell's hybrid model in his Agile Software Requirements book could be of use in the kanban situation as much as it is in the Scrum situation– Eric WillekeCommented Apr 5, 2011 at 19:27
-
I really desire some alternative answers before I accept Pawel's answer, it feels like there should be more to this...– Eric WillekeCommented Apr 18, 2011 at 3:22
-
1Me too. Let's throw some rep out there and see what happens. I'll start a bounty.– ashes999Commented Apr 19, 2011 at 3:08
-
Just so it gives another perspective: http://izlooite.blogspot.ae/2010/09/kanban-vs-scrum.html– KMånCommented Sep 25, 2015 at 14:44
Add a comment
|
3 Answers
Actually I'd say it isn't dependent on any given method you use. If you don't know how you deal with any given task than, well, it's just hard to say.
A few ideas you might use:
Use any information you have. Like you may have some estimates for some simple tasks done by the team and you may use them as early rough data to use while estimating a new project.
Estimate like you would if you had no Kanban process whatsoever. You would actually do that if you didn't have Kanban in the team, wouldn't you?
Just start working and use whatever information you gather to adjust future estimates so you have your final estimates better and better over time.
Ask other teams which are using similar techniques for help. Ask them how they would estimate such project.
Get used to the thought you will be guessing to some point, you want it or not. Make everyone around aware of that. With no historical data and little experience on similar projects it will always be guesstimate. Don't try to make it anything else.
Actually I wouldn't say Kanban changes here a process - unless you have some reliable data to base on your estimates will base on gut feelings, you want it or not.
answered Apr 5, 2011 at 23:32
-
1I'm hoping there's something emerging from the approach other than "do what you did before" that can be partially useful during the transition period as the system is stabilizing. I worry that reverting to "traditional" estimation techniques can slow down adoption in cases where over-estimation was a problem point. This in no way, however, detracts from the quality of your response! Commented Apr 7, 2011 at 4:18
-
You kind of limited available options in your question. If we have no reliable historical data, or at least some experience with similar work, to refer to you will always end up with the same few ideas. The trick with improving estimates is always: learn how you work, measure it, use it next time you need to make some estimates. The problem is it works only in the long run. If the question was about estimating in Kanban after some time the answer would be different. Commented Apr 7, 2011 at 8:20
Pawel's answer brings great coverage of the subject but as you wanted more thoughts on the subject as I deliver:
- I woudn't expect your new team to beat delivery rates of other teams with higher level of adoption (Kanban and/or work experience) unless you were allowed to hire top guns from outer space.
- SLA's are not everlasting, in fact, there should be some paragraphs about improvements and reevaluations as well. Make first cycle short and meanwhile grab all the measurements experience in estimations.
- If your team is already working on the project then introducing Kanban table doesn't change much in task estimation. New practices do change a lot. I.e: introducing a WIP limit means you can not promise (SLA) too much concurrent tasks but average task work time should decrease. If you suffered from unproper prioritetization of tasks before Kanban then you could probably expect to handle critical tasks better/faster and ofer better quality of service in such area of SLA.
- It is not so bad idea to ask team for an estimation or even a guesstimation of best- and worst-case scenario. You can ask as well for their preference: are they willing to take worst-case scenario, work in more pleasurable atmosphere, but suffer from not so well PR among other teams OR should you take rather best-case scenario and maybe work overtime in order not to break commitments. Make sure it will last only for the first period.
answered Apr 22, 2011 at 16:30
I would add that probably not all work is created equal when considering need for commitment. Take advantage of that. Use the work that is less sensitive to commitment as a sort of "buffer" that keeps you delivering on time, even if you underestimated somewhat.
If all of your work is under SLA, you definitely need to take buffers based on earlier estimation techniques like Pawel described... Some people would say that is a problem in and of itself. I agree. But if you are working at the team level, and you currently don't have enough trust/sway to convince other teams to move more of the work to Pull mode, then you will have first to deliver, then change the reality.
