Kanban and Scrum.
Whilst I've been trying to do agile for several years, I've never been in a scrum team that I would consider as really working. I'm sure there are scrum teams out there that estimate well, sprint well ,and deliver great software. But I've never been in one, and I'm sure there are a lot of people out there that have had a similar experience as me in implementing scrum. The point of this post is to offer an alternative - something that might work for you, if scrum isn't.
There will be some people who read this that will argue that I've never done Scrum properly - that my pain-points are due to the fact that a lack of engaged product owner, or overzealous project managers, or an undisciplined team.
Whilst that might be true, I've tried to do scrum in 4 companies over the last couple of years, and I feel a theme is emerging (and yes, I know that theme could well be "you is doin' it wrong").
On paper, Scrum seems good - estimate some work, check your velocity, fit the the number of stories into the sprint as will fit that velocity in order of priority. Do the work; sprint ends, demo to the customer; accept feedback. Rinse and repeat.
Waterfall says analyse some features, work out how long it will take, commit to a deadline. Do the work, timebox ends; demo to the client.
But in my experience, Scrum often feels a bit like mini-waterfall.
Scrum's not exactly the same as waterfall - there are some clear improvements that exist in the scrum approach - quicker feedback, ability to change course & react to stakeholder input. Estimation of work is better because you're estimating every 2 weeks rather than once at the beginning.
But when I'm doing Scrum, I feel that its not enough - the feedback isn't quick enough, and the project managers start to treat it as a sequence of mini-waterfalls. They start asking why we didn't manage to fit in all the stories we put into the Scrum, and start micromanaging.
Now there are several reasons it feels like this - the main ones probably being that the PM's never really get on board with Scrum, and push the "feeling" of it to mini-waterfall. Coupled with that fact that the team is probably not very good at estimating, and we're not really engaging with the stakeholders, and still using PM's as proxy stakeholders.
But thats one of my problems with Scrum - its almost too easy to fall into mini-waterfall when you don't have available all the aspects that would make Scrum succeed - access to stakeholders, and either PM's that embrace Scrum (or dare I say it no PM's at all).
I'm also not particularly engaged with the idea of velocity or timeboxing.
When does a business care about velocity ? What does velocity mean to them ? Businesses deal in money and days. I've never been comfortable with this fibonaccian sequence of abstract points. I don't know what they mean. I'd rather say "small, medium, large, crazy big". I know that small is a couple of days, medium is a few days, large is a week, and crazy big needs to be broken down.
Timeboxing feels like overcommitting - in the same way waterfall is overcommitting. In most sprints I've been in, we've either delivered everything, and pulled in more work, or not delivered everything we'd estimated we would. I've rarely delivered exactly what we'd estimated.
Now that could be a problem in estimation, and I'm sure there are teams out there that are making it work, but I'm sure there are plenty of people who arn't.
So why do I think Kanban sorts out the pain-points I've experienced with Scrum ?
Scrum "pushes" work (a bunch of features) into a timebox. Kanban "pulls" work on a feature by feaure basis.
I like that for several reasons.
Firstly, it leaves little room for PM's to take control. Work is done when work is done.
The business just cares about delivering features - and Kanban gives that. The business doesn't care about velocity. The business knows if a team isn't delivering software quick enough - you don't need velocity to tell you developers arn't up to scratch. A business should employ developers that care - if they care, then you'll get good software delivered quickly. Its about trust, and respect.
Secondly, the feedback cycle from Kanban is immediate - you don't have to wait for the sprint to end. Couple with continuous delivery, the business sees immediate results.
The pipeline is simplified - get feature, clarify it, code it, push it.
I think Kanban can also work for PM's as long as they back of a bit. PM's need to engage in costing and timesheets - a fact that developers often don't understand, nor care about - but businesses often need. But with Kanban, costings and timesheets are done at the end of the pipeline - after the fact, not before it. They'll work in facts, not estimations, because the feedback cycle is so short (ie features get completed and signed off every few days, not every few weeks).
