Tag: methodology

  • The Kanban Story: The Beginning

    So I found myself in this small team, part of a bigger company but working pretty independent of the rest of people here. Kind of start-upish environment. I knew every single person I worked with. Well, actually I’d chosen most of them and hired them here. The team was great (if you guys are reading this: no, it is not a reason to come for a raise) and personally I didn’t feel an urge to strictly control everything. On the other hand some order is always a nice thing.

    Initially I gave a lot of thought to project management practices and didn’t come with a solution I was happy with.

    I rejected PMP-based heavy-weight process which works for many projects in the organization. We didn’t need all the hassle they bring. At least not at that stage. A natural idea was Scrum which I didn’t like either. Scrum is pretty formalized methodology too and I wanted to avoid formalisms as much as possible. Actually with a lot of R&D work, pretty much prototyping and priorities changing all the time I needed something more flexible.

    I didn’t want to be time-boxed since we were planning to work simultaneously on a few independent small projects which would be hard to synchronize if we wanted to put them all in one team-wide sprint. Creating independent sprints for each of projects was a complete overkill since you don’t really need Scrum sprint for a one-and-a-half-person project.

    Actually I’d say we were at the point where we were too flexible for agile methods. Now, go burn me in flames for being iconoclast.

    After some discussions we collectively agreed we wouldn’t adopt Scrum as a whole but would use some of techniques used there and some other ideas we thought were good. In the next post in the series you’ll find more details how we initially organized our development.

    Keep an eye on the whole story.

  • There Is No Single Flavor of Agile

    Agile is such a capacious term. Under the flag of agile we do different things. Scrum is agile. And XP is agile. Scrum-in-the-name-only is also agile. We go with no plan whatsoever and that’s so damn agile is agile too.

    Yes, you say the first two are true agile and others are fakes just tainting The Holy Agile Name. That reminds me… wasn’t it exactly the same with waterfall and others bad, bad techniques? Wasn’t they tainted by poor implementations which got everything wrong so we had to come with new better methods? Well, just a food for thought.

    Coming back to agile. With all these good and bad implementations I can safely say that there’s no single flavor of agile. There never was. I believe it was never intended to be the only one. I recently read notes on the writing of the agile manifesto by Alistair Cockburn and one thing stuck with me:

    I came in through the doorway marked “Efficiency” not the doorway marked “Change” – because my background was in fixed-price fixed-scope projects. (…) Other people came to agile through the doorway marked “Change”, and that’s fine for them.

    So although agile gets billed most of time through Kent Beck’s “Embrace Change” moniker, I’m not happy encouraging people to just change stuff all the time – it’s more efficient to think for a while and try to make good decisions early – the world will supply enough change requests without us adding to the list by not thinking.

    Different experiences, different projects, different backgrounds. Different accents when talking about the Manifesto. I can’t say I haven’t expected that at all but still. There was never one universal interpretation of agile principles yet we see every now and then people selling the only right and proper method of being agile. How come?

    On a side note: I wrote this piece a few days ago. In the meantime The Big Ugly Change came and kicked my ass big time. “The world will supply enough change requests.” Couldn’t agree more these days.