Applying Scrum is not simple, especially for IT service companies. One of the main factors I’m currently struggling with is team stability. Production imperatives, themselves driven by financial imperatives, too often reign supreme, and that’s normal. It’s also a sign, you might tell me, that the processes and methods are not mature enough since at the slightest gust of wind (a large contract signed, a staff augmentation triggered for a key team member, etc.) they fall apart. I cannot contradict you. I haven’t had the chance to know a company that—regardless of context (the crisis for example)—is capable of maintaining at all costs the entirety of its processes while advancing them (these last words are important otherwise it’s fossilization that awaits you).

Today many IT service companies are jumping on agile methods because they’re in vogue. They encounter numerous challenges including, to name just a few:

• contractualization (the major problem currently, since it’s only the beginning of their offering in this area, and it’s a very foundational element), they need to find a third way between fixed-price and staff augmentation (thanks Christophe).
• the redistribution of roles: the client (product owner) is responsible, the team (team) is responsible, the Project Manager disappears, he was the one responsible, the fuse, Atlas who carried the project (incidentally with the project director); the Scrummaster appears, he is a facilitator, but in no way responsible.
• the stability of teams during sprints, iterations, is necessary.
• the maturity of clients and teams, no one is interchangeable, each collaborator is different from another, etc.

IT service companies are therefore embarking on a difficult journey. Today if I look at one of the projects I’m pushing toward agility, I run head-on into the difficulty of team stability. It’s not a client project, but an internal project. It’s all the more jerky. Its priority is difficult to establish. Resources flow in (end of client projects) and they flow out (signing of client projects). I myself can only have chaotic activity toward it. Applying the fundamentals of Scrum in this context becomes very complicated. But agility is also a dynamic of adaptation. So today I’m turning toward Kanban for this project.

Why? It offers me values that are in line with my needs (some are also associated with Scrum): not developing functionality that no one will use, not writing more specs than there will be code, not writing more code than I can test, not testing more code than I can deploy. Very concretely, not being able to build a stable team, not being able to guarantee a daily daily scrum, not having enough guarantees about the sustainability of my team, etc., I’m going to focus on what I imagine to be the essence of Kanban practice and from there rebuild an agile process (if it works). Let’s be clear, it mainly allows for an excessive simplification of the process, and if it works it will allow me to bounce back to something more powerful. This within the scope of this project.

I no longer know where (ah yes, here) I read this example but basically, figuratively speaking: I’m putting doors on a car (Kanban comes—again—from Toyota), I have a pile of 10 doors in front of me, when I reach the 5th door I see a tag on the car (tag = kanban in Japanese). The tag tells me I need to notify the person who makes the doors to make me 10 additional doors. I find this person and ask them for 10 additional doors. They stop the task they were doing, and start making 10 additional doors. They knew I would come by, but were working on something else. I return to my assembly. When I’m almost finished with my pile of 10 doors, the person I had asked for the new doors arrives, they put down the doors, and naturally, on the 5th one, in the middle of the pile, a small tag is present, etc.

Here, on this famous internal project, I have a backlog and a fluctuating team whose availability is fluctuating. My difficulty is the WIP (Work in progress). I must not have a team member who starts something and who unfortunately cannot complete it (for x reasons). Otherwise I end up with a coordination task (of the new member replaced by the old one), a knowledge transfer (of the new…), and potentially rework (the new team member approaches the resolution of their task differently). In short, 3 essential plagues that are sources of waste.

My objective is to define User Stories (or MMF: minimal marketable feature) that are compact enough and independent enough from each other so they can be approached individually and quickly enough: to avoid risking losing the person who took charge of it, so they can grasp the MMF quickly. Have enough visibility across all MMFs so they can chain together and constitute added value. Make deliveries more quickly, more rhythmically. When a regular flow is established I will have set up a first level of efficiency. The objective of this flow is to succeed in creating a rhythm and regulation between the different tasks related to the project, by limiting “work in progress” as much as possible because it’s what prevents me from delivering regularly and makes the project’s progress rigid. Each task fits with others, or can trigger others without the people in charge of these other tasks being impacted. They therefore have “free time” for their other activities (knowing that here the process is reversed, it’s when they have free time that they dedicate themselves to the “internal” project). Finally it’s easier to intervene on the project when each task is more compact (this is unfortunately not so simple and not so often true).

Between now and then, and if I reach this goal… we’ll discuss it again.

To learn more about Kanban, call on Google, or use this page from this excellent blog: targetprocess: kanban.