I’ve been revisiting my earlier KFC Development work in light of my more recent focus on five primary practices. This blog post an brief overview of what’s changed, and what my mental model looks like now. Read it here.
Archive for category Karl Scotland
The next London Limited WIP Society meeting will be Thursday April 8, starting at 18:30. Please register at http://skillsmatter.com/podcast/agile-scrum/john-stevenson-kanban-for-just-in-time-training
The topic is “Kanban for Just In Time Training” given by John Stevenson.
It is not uncommon in IT projects that you are required to learn something on the fly or you see an opportunity to introduce a new technique or tool that would bring great benefits to a project.
How do you manage the learning curve required for something new without major impact to the project?
This talk will discuss how Kanban can be used to manage a training schedule, for either personal development or for team skills transfer.
Arranging the board so that the studying is planned and managed effectively
Discussing how to use of work in progress limits to manage the training schedule to ensure that learning is done effectively and avoiding study overload.
Using card design to ensure that the goals and measurement of training success are defined, so that the effectiveness of the training can be assessed.
Organising cards to enable a flexible training schedule and study topics can be picked up “Just In Time”
Adding the pomedaro technique to maximise your study time.
The next London Limited WIP Society meeting will be Thursday March 11, starting at 18:30. Please register at http://skillsmatter.com/podcast/agile-scrum/chris-pitts-migrating-from-scrum-to-scrumban/zx-548
The topic is “Migrating from Scrum to Scrumban – an Experience Report from a Kanban Virgin” given by Chris Pitts.
Last year one of my client teams was looking for a better way to work following some problems while running fairly standard Scrum. One change appeared to be to combine Scrum with kanban – “Scrumban”. So we jointly decided to give it a go.
This experience report explains how the team did it. It should help anyone interested in evolving their Scrum and other timeboxed iterative process to an interesting alternative. The talk will cover:
- Why evolve? A summary of how the team was working and the issues they were seeing.
- Practical observations of how using kanban changes timeboxed iterative develop process
- Some of the questions that you will need to address when you change
- Some concrete solutions to those questions Where next? Possible directions for further evolution.
Following on from his description of the Kanban implementation at Lonely Planet, Bruce Taylor has now made a related presentation available – Little Bits of Cardboard.
I’ve posted some thoughts on describing processes in terms of safeguards and ski-slopes, and how that can help teams decide an appropriate process.
One of the joys of working as a coach for EMC Consulting are the regular opportunities to have deep conversations on various topics with my colleagues when we are in the office together. For example, earlier this week myself and Simon Bennett began to discuss way of talking to our clients about process such that we can guide them towards the most appropriate choice. However much we may have our preferred approaches, they may not always be the best solution in any context. In the course of the conversation we compared various styles including waterfall, scrum and kanban, and looked at them on various scales, including risk, reward and control. None of these seemed satisfying as a language to use, until Simon suggested safety.
Read more here.
Claudio Perrone posted the following Experience Report to the kanbandev list:
Hi guys,
I’ve been using XP (and then Scrum/XP) for almost 8 years and I’ve fully embraced Lean and Kanban this year, with great results on all teams and organizations that I have been involved with.
As many claim here, I found that Kanban, in particular, has a lower barrier to adoption (I consider it a “non-disruptive enabler”, at least in apparence), it is applicable to a wider set of scenarios, and can be used to train teams on problem solving and root-cause analysis as soon as problems arise.
“Walking the board” on a daily standup (that is, focusing on work in progress rather than on the people doing the work) is an excellent device to enable this form of problem solving and team communication.
In my coaching experience, I found very effective to refrain to give all the anwers in advance. I often let issues emerge, and ease teams into “interpreting the board”. When a WIP limit kicks in, the typical initial reaction by some members is to ask to raise the WIP threshold. That is seldomly the right answer to the problem and soon other solutions arise (story too big or unclear deliverable, need more help, unaddressed impediments, etc).
As many people may agree, retrospectives can also be very effective to improve the way teams work (or even save entire projects!). I alwasy found very beneficial to stick retros within a cadence (in either SCRUM or Kanban) and never bought into the fad of JIT them or even dear considering them “waste”.
Is it all good? Well, yes. But I have one burning issue.
In sharp contrast with RUP or waterfall approaches that I used before embracing agility, I always find one specific benefit of SCRUM/XP timeboxes (when applicable): they boost creativity by forcing teams to find simpler solutions that can fit an iteration.
Yes, timeboxes are self-inflicted “artificial” constraints, but they are exactly the reason why, years ago, I learned to provide value by focusing on the needs and outcomes rather than simply developing what the customer asked for as fast as I could.
Now that I learned such good habits, I’m not going to drop this approach of course
Having said that, I’m not sure that focusing on improving average Lead Time alone automatically pushes a team into deliberately find cheaper/simpler/better alternatives.
Do you guys have any thoughts/suggestions?
All the best,
Claudio
Tim Wasson posted the following Experience Report on the kanbandev list:
Since there has been a thread recently about what to do with a failing project, I’ll share my story:
I was hired into this situation:
3 full time devs, 1 part time dev
6 different codeignitor (php web app framework) applications, all hitting the same db, all stored in a single 1GB svn repository
Code written by offshore groups and multiple devs without coherent architecture
Green team (oldest dev was 26)
Fresh team – longest time here was 10 months, then 6 months, then 4 months, then 2 weeks.
No processes of any sortThe “build” was going to be the be-all end-all attempt to fix all the design sins of the previous 12 months in just one month, while continuing to keep the business running with daily bill runs totalling about 20000 bills per month. Some of the tickets for the release had complete descriptions consisting of “Decide how to clean up the database and do it”
Yeah…. riiiiiight.
The original release date had already passed when I came on board.
85% of the tickets slated to be done in the release had not even been started.
The devs were spending 60-90% of their day on “fires”And management said “the build” HAD to be finished in December.
Yeah…. riiiight. I wondered what I had gotten myself into.
One month later, we have dealt with 65 individual “fire” tickets, completed 24 planned tickets, and we will deliver a build that has the most important things the business needed, while reducing error rates on bills from 15% to less than 1%, and 2 of the devs have rolled off onto the next batch of prioritized tickets.
Here’s what I did:
1. Got a white board
2. Got stickies
3. Make Kanban board with regular whiteboard pens. Figured the process would change, so make it easy to change
4. Started the morning meeting.
5. Identified fires with pink tickets.
6. Focused devs on one task at a time. Told them they were not to think, plan, or meet with anyone about anything that wasn’t in work or in their immediate queue.
7. Met with mgmt and convinced them of two things: If we insist on getting everything in the build, it will not ship until february, and two, I can’t promise any dates.
8. Had devs politely but firmly refer all questions from biz people to me. The devs stopped giving anyone else answers. Once bugging the devs is no longer effective, people stop doing it. Told the business that if they want status, come to the morning meeting. My guys were not going to answer status questions about tickets because that’s what the morning meeting was for.
9. Arranged to handle all “you need to go change this in the db” type problems at one time right after the morning meeting.
10. Convinced mgmt that we had to do a release in December of whatever we had in order to improve morale among the devs and the rest of the company.
11. Kept refusing to give a date for the first two weeks I was here.
12. After two weeks, I gave a rough idea where I thought we might get to in the queue of tickets if we wanted to release on 12/15.The biggest things that my devs have appreciated:
1. Focus – only one ticket in work at any given time.
2. Credit – Fixing fires is no longer just time the devs are supposed to eat in addition to their normal working hours.
3. Horizon – They were buried under a mound of hundreds of “MUST HAVES – BLOCKER – CRITICAL – HIGH PRIORITY” tickets. My devs only worry about tickets that are coming up in their queue.
4. Traction – Moving the tickets at the morning meeting is a moral builder. Seeing the stacks of fire tickets as real work that has been accomplished rather than things that prevented them from working has totally changed their attitude towards meeting the daily problems the business faces.
5. Root Cause Troubleshooting – If a fire is important enough to fight, then we’re going to fight it. We’re going to ask for good concrete examples, we’re going to track them down, we’re going to fix them, we’re going to get the testing that we need, we’re going to get the support from the business, and we’re going to put these things to bed.So take it from me:
Kanban works.
It is so much easier than Scrum.
With Scrum you waste time arguing over how long a ticket will take, you waste time arguing over committing to this one last ticket for the release date, fires still don’t count as “real” work, and the tracking of hours and burndown chart turns into a timecard game each time I’ve seen it. The hours and hours wasted making up numbers which will are guaranteed to be either too big or too small – it’s waste. The sprint planning meetings are a beatdown. You still feel pushed into promising dates when you don’t know. With Scrum, daily changes in priority are a problem, adding and removing tickets is a problem, because now you have to re-check your dates, renegotiate everything. That is almost all waste.You can start Kanban tomorrow. Just do it. Learn as you do it. Don’t be afraid to rewrite the process on the white board. Mine changes about every 3 days.
Prioritize work
Focus on one thing at a time
Manage interruptions
Create checklists, processes, and rituals
Show progressFunny story: When I arrived, the devs were routinely going into the master database and modifying records throughout the day in response to various emails from company people. This was leading directly to database replication problems, data corruption, and a willingness to continue to fix the data instead of fixing the code.
The entire business was upset that their database was unstable, but was contributing to that with constant requests to just fix the data. I decided to make touching the master database a bit more expensive: I created a “Database Ceremony” – In order to touch the master database, three people would be required to participate: me, the developer, and the business person who wants the change, must all participate. First, we read the famous “Holy Hand Grenade of Antioch” passage from the “book of armaments” from Monty Python’s Quest for the Holy Grail. I have a special round glass decanter that we take out of a special box, and we put on the desk with us. Then we recite the reading aloud together. Then we carefully log each and every query, check the numbers as we go, and at then end we say “amen” and we print the log, it becomes another “chapter” in our own 3-ring binder “book of armaments”, and we put the decanter back in the box.
Yes, it’s silly and unprofessional. So is messing with your master database all the time. If a biz person really needs the change, we’re perfectly happy to do it, but they’re going to recite Monty Python with the geeks. And using direct sql in your master database is like the holy hand grenade: a powerful weapon, useful and appropriate at certain times, but one to be used with an attitude of care and reverence.
But there is a sound psychological reason behind this: Reading the passage aloud puts us all in to a frame of mind that something important is going on, and the beginning and the end of it signify a period in which we must be extra careful The attendees are recorded in the log as well, so there is accountability that we actually changed the data that the business wanted changed. The standard for the log is simple: You must show ALL your work in the master db. Do selects and prove that the record you want to change is the right one, then change it, then prove it changed. The log must allow us to restore the db to a proper condition if needed.
I must admit that after a database ceremony, when I put the decanter back into the box and close the lid, I do breath easier because I know the db is safe and sound. And there is a “lean” angle to this as well: The decanter on the desk is an Andon showing that the group is engaged in a particular unusual activity.
Anyway, sorry for the long post.
Tim
Kanban at Lonely Planet
Oct 12
Bruce Taylor posted the following report on the kanbandev list and kindly gave permission for it to be reproduced here:
Just thought I’d share with you our implementation of Kanban work process at Lonely Planet in one of the teams we have here;
Here’s how I recently “summarised” our development process as it has evolved on Atlas 2:
This original summary was written by our lead developer, Simon Harris, and is a pretty good summary of what/how we evolved our process to. I have hacked into
his description without referencing where the change is, but I know Simon would be fine with this.This project was failing badly and we had large numbers of card clogging our board and impeding our ability to deliver, identify constraints and generally
get on with it.The process changes we put in place helped us very quickly focus on the immediate high-value stories and prioritise accordingly. We were also able to
observe where our constraints where and ease/remove them.Can I also refrence this post/site:
http://leansoftwareengineering.com/ksse/scrum-ban/ which was our original introduction and starting point.
**Follows is original description with editing by me.We’re currently running with a VERY lean approach to development which has been the result of two or so months worth of refining:
* No more than one card per pair in dev at any time
* No more than one card per pair in ready-for-dev at any time
* Nothing to be blocked; If it’s blocked we work to remove the blockage
* New cards are demand pulled into ready-for-dev as cards are moved from dev to ready-for-test
* We have big picture story card sessions as required
* We have planning meetings at the start of each iteration where we discuss what’s “planned”
* We give everything t-shirt sizes (S, M, L) – Bruce here: I than attach numbers 1,3,5 to these for my Burn Up Chart
* No technical stories; everything must be done because it delivers business value ( We are generally very good at this..)
* We don’t measure velocity – However I do measure our burn up to a date as we have this as a project constraint (Time)
* We aggressively split cards
* I repeat, we aggressively split cards
* Daily stand-ups
* Parking lot for post-stand up discussions
* Full-time pairing where possible
* We release when we have a MMF rather than around the sprint cycle. Essentially the Release Early/ Release Often. We sometimes release every 2 days if the option/opportunity arises
* We use the iteration cycle of two weeks for an opportunity to re-focus via Retros and increasingly lighter weight planning sessions.
* We try to focus on doing things as simply as possible
* We try to focus on building things correctly rather than as fast as possible
* We fight to have a REAL user available to better understand their needs
* We rally against the usual cries of “but I know we’ll need it”; We trust that by building things simply we can always add on the extra functionality later
* Trying to deliver everything to everyone leads to delivering nothing at all to anyone
* T-shirt sizes help the business prioritise not estimate delivery dates; Business value is a function of, among other things, time/ cost to build – As mentioned above – I translate the T-shirt sizes to points (1,3,5) for external reporting in the form of a burn – up chart. We use this solely to track releases.
- We have started using Cycle Time tracking to measure Start to Finish time on cards. Not really sure where this will take us, but if I remember I’ll report back on this if people are interested (Bruce T)
* Rolling technical stories into stories that deliver business value force us
to change course slowly and justify changes
* We usually have parallel implementations of some things as a consequence
* Minimal changes are allowed on “old” implementations; anything substantial requires a migration to the “new” implementation
* If we can deliver _some_ business value early by splitting the cards we do so as soon as possible; Eg. business can view existing data in the new form but editing is a new card because they can still use the old mechanism for that.
* It’s critical that the whole team is taken on the “journey” so they understand _why_ things are being built. Doing so brings the team into alignment and also allows the team to make informed decisions such as re-structuring work to enable splitting cards for aggressively.
* Bringing the team along for the journey can be painful, never gets easier, and is always worth the effort.
* Just-in-time stories really does enable the business to leave the decision as to what’s important to the last possible moment
* Implementing the smallest amount of code possible for each story is critical to enabling just-in-time development; less code == greater flexibility; E.g. don’t use a database when the data comes from a spreadsheet and presently only ever changes in a spreadsheet.
* We do as much forward thinking as possible/practical; We think of as many likely scenarios as we can and keep reducing the scope of the implementation so as not to preclude implementing them later on
* Almost nothing ends up looking as we thought it would when first envisaged.
* More important than writing the code is working out how to structure the implementation so that we get the job done without precluding possible future work; sometimes this means at least thinking through a strategy for migrating from one implementation to another later on if necessary.
* It’s amazing how splitting stories reveals just how little the businessvalue certain aspects of stories
* We almost never get through everything that was “planned”
* We almost always end up doing stories that weren’t “planned”
* At some point we hit a tipping point and development switched from a whack-a-mole game–where a change always seemed to make something else break/harder to develop–to delivering incidental benefits as a result of the normal development of stories–e.g. speed improvements that we knew needed to be addressed but hadn’t actually planned on looking into anytime soon.
* We’re motivated by getting things done; call that velocity if you will but we really haven’t found a need to measure velocity. (Caveat: Now that we have achieved good throughput, we have been using countback velocity – measuring cards completed previously, to produce a burn up when reporting to Stakeholders. However, I am hoping to use Cycle time to reducing estimation from Points on a card to “How long a card takes to get from point A to point B as a reasonable and useful measure. Not sure how that will wash with senior stakeholders outside the project team though)
* Delivering a constant stream of small but valuable stuff into production every week is VERY motivating.
* As developers we value delivering something over delivering nothing
* We actively plan for changeCaveats:
* We have a highly competent team
* We have a fixed budget
* We have internal and external users
* We have UI and data-only users
Karl has written a really great post on why kanban isn’t just a task board in response to the questions being asked in the last week on the kanbandev yahoo group about what kanban is and isn’t.