Somebody mentioned that my design team had created a Trello board for themselves. Something to help them manage their workflow. I killed it.
Continue reading
Tag Archives: kanban
None the wiser after the stand up? Wrong stand up or chance to learn
Kim Daubney asked “What to do when stand ups leave you none the wiser”? What you do really depends on why you are “none the wiser”. Do you have a knowledge gap or is the wrong information being shared?
Continue reading
Is Kanban Turning Developers into Mindless Automata? Not necessarily
David shambles up to the Kanban board. He moves a card from “Dev In Progress” to “Dev Done”. No emotion cracks his blank facade. There is no celebration of a job well done. No acknowledgement from others in the room. David glances briefly to his left and then pulls another card from “Ready for Dev” into “Dev In Progress” before shambling back to this desk. Another burst of coding begins. This little scene has occurred four times already this week, 19 times this month, and 271 times since David joined the project 15 months earlier. Is David just a machine in the Lean-Agile software factory? A mindless development automaton?
Continue reading
Software Batch Sizes are Plummeting
When I said Continuous Delivery is Inevitable I cited shorter iterations as the main driver. However, along with shorter iterations we’re also getting smaller batch sizes. And from a Lean perspective it is the smaller batch sizes that are more interesting.
Continue reading
Three Amigos Meeting – Agree the tests before development starts
“Three Amigos” is what Matt Wynne calls the meeting to discuss the Gherkin scenarios before development starts. The Three Amigos involves the business, development and testing voices. However who turns up, where they meet, what they produce in the meeting, the homework to complete after the meeting, and who does that homework can all vary depending on the particular team.
Continue reading
The Lean-Agile Fanatics are all Wrong
When Kanban folk talk to Scrum people the conversation can often get heated with recriminations and finger pointing. Personally I’ve got a pragmatic, or eclectic, style of Lean-Agile. None of the published methods are the silver bullet. But they all have something useful to offer.
Continue reading
Kanban in Video, Post and Book
I’ve been using the Kanban method for several years now and I recently introduced my latest team to its joys. I do a lot of arm waving to explain the method but I also direct them to some essential viewing/reading. So I thought I’d share my Kanban recommendations – one video, two posts and a book.
Continue reading
Daily Plan: Stand up to Plan the Day
“Stand up please”. Old habits die hard and because I started Agile with Extreme Programming I “Stand up”, I don’t “Scrum”. Otherwise the two types of meeting are pretty similar. “What have you done since we last met? What will you do before we meet again? Any impediments?”
Great meeting. Wrong questions.
As Mike Cohn explained back in 2006, and Matt Wynne reminded me last year, the daily meeting is a Planning session. It is part of Mike’s planning onion because the aim of the “Stand up” is to develop the plan for the day.
Continue reading
When Meeting Madness Strikes
Some people and some organisations like meetings. If you drop Agile with its Agile Heartbeat into the mix then you might find that meeting madness strikes.
I’m a Kiwi living in the UK and I’ve noticed the British will form a queue if given the barest of excuses. Similarly, in some organisations, the people will call a meeting at the drop of a hat. People in coordination roles (e.g. project manager, discipline lead) seem particularly prone to this.
Don’t.
Continue reading
When To Measure Lean-Agile Productivity, and When Not To
Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.
There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.
Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.