Tim follows up with me for a new question. He would like for his client a sort of quick little manual to grasp agile project management. I tell him that this agile survival guide has existed for 10 years, and its last revision dates from 2017. But I realize on one hand that it’s not as concise as all that, that it’s riddled with errors (shame), and that it uses a lot of agile jargon. I think however that it’s even more relevant today than it was 10 years ago given the deviations we’re witnessing. But I want to engage in a double game: do something succinct, and without agile jargon.

Here is the very small agile guide without agile jargon.

Very small agile guide without agile jargon

How to lead a project or build a product with an agile approach.

First week, we define the key objectives of the project, of the product. It shouldn’t be about succeeding with the project or the product, or delivering the project or the product on time, which means nothing. But really about reaching one or several fairly concrete objectives. Concrete enough that we can ideally quantify them to articulate our conversations (the figure precisely in itself remains secondary). If I take the imaginary project of the island of Atlantis which wants to create the new digital tool for capturing and managing its civil registry, and especially prevent fraud (too prevalent due to the central positioning of the island between the Americas and Europe), the objectives are: a) capture at least 100,000 civil registry records in the first six months, b) reduce fraud by 60% on business registrations for non-residents of the island. Two objectives, three maximum, because without focus: no progress, no quick decision.

To complete a project (or a product, well you get it): five potential actors (do your best, but be honest with yourself: each time you degrade the principles, you degrade your results: yes that’s where it comes from). 1) Those who build the solution. 2) The one who defines what we want, why we want it and validates that we have what we’re looking for. 3) Those who sponsor the project (the requesters, the payers). 4) Those who will be at the heart of the usage when the project works (if this group doesn’t exist, we must get as close as possible to it, by observing, by measuring especially). And 5) fifth, the one who ensures that what the very small agile guide without agile jargon tells is properly applied (for example not ten project objectives, concrete objectives, quantified –not for the figure– but to articulate the conversation: if it’s 60% less fraud it’s not 10%, nor 95%, which would change things).

Then everyone has rights and duties. Those who build the solution decide how they build it, that’s normal, in return they show us every two weeks what they’ve finished (and that has been validated): we can manipulate, question. They build in the order proposed by the one who defines what we want and why. They must know how to explain well and must validate when a result is proposed to them. In fact they’re with those who build and when I talked about showing every two weeks, they’re in the team that shows, and we only show what they’ve validated. In fact it’s really they who decide what and in what order. Naturally those who sponsor (pay for and support the project) have expectations: this can become constraints to impose on those who build (including the one who prioritizes). For example: whatever comes out must precisely respect the anti-fraud rules mentioned, or whatever comes out must be compatible with our mobile phones. If there are too many constraints, everyone suffocates and nothing moves forward. These sponsors also have a request “I’m paying so that we finally have a proper civil registry” so normally the one who prioritizes and says what is aligned with this request. Generally sponsors have a bird’s eye view, this also means they must stay at a distance, they don’t come stick their nose everywhere, that would be counterproductive. For that they will only come every two weeks to give their opinion regarding what the others will have finished, validated, and will show.

Every two weeks, it’s a lot and a little (let’s say 1 hour every two weeks). During this synchronization every two weeks we also bring in the group of those who will use it (in our example those who will handle the civil registry or control fraud). They can alert us or congratulate us as things progress (1 hour every two weeks). Finally the one who ensures that what we’re telling here has the duty to properly apply it with neutrality, their right is that their action is limited to that to maintain neutrality and be effective.

We thus put everyone on the same screen or in the same room for one hour every two weeks to show what we’ve finished and discuss it, tell each other what will or should come next. We ritualize: it’s always the same time, the same day, every two weeks, otherwise it crumbles, it collapses. We take advantage of this to also do at the beginning of each two-week cycle a meeting (1 hour, 2 hours, 3 hours? No more) between those who build and the one who knows what they’d like to validate (and in what order) to define what we’re trying to finish in the coming two weeks. Generally (but this isn’t a rule) the one who says what in what order prepares one or two cycles in advance more precisely than in broad strokes, but not too much because things evolve and they would waste time or unfortunately freeze the project.

At times it’s worth it for this group to also sit around a table (virtual or not) to question changing one or two things about their way of working (1 hour 2 hours 3 hours? No more!). During the two weeks the building follows its course: the best would be to have a single central visual board that shows everyone how things are progressing and that allows the one who must validate the elements built for the end-of-two-week-cycle meeting to do so as things progress and not haphazardly just before the meeting. By the way if we have nothing validated, nothing finished, we still have the meeting to explain why and talk about it to others: it’s important, but maybe no need for it to last an hour. We can decide to have a synchronization within this group between those who build and the one who explains what they want and validates: every day? Every two days, 5 minutes, 10 minutes? And then really during this two-week cycle you do what is intelligent and useful.

Little by little the project will progress, and every two weeks all the actors will be aligned on the state of affairs. This will allow us to pivot, to clarify, to congratulate ourselves (make sure you’re in “production conditions, in a quasi-real situation” to be sure your decisions are founded, put it in the constraints). If the project isn’t progressing: you’ll see it soon enough and will also make a decision. To know what you’ll have in six months: you observe what you had during the last month or the last two months and you replicate this pace that appeared over the two-week cycles. Yes for the impatient one, you must wait for a pace to appear. They can tell themselves they saved the time usually lost making false estimates. Does that mean not making estimates? Normally it’s entirely possible if we don’t forget a few last important rules: we start with the most important, we advance in small pieces that make sense. Thus since we start with the most important: we know quickly if we’re going to have an impact or not on the heart of our subject. If we advance in small pieces that make sense: we can have a real look quickly at what we have (or not). We might even be able to use them before the end of the project in a real situation, in production, these pieces (right, no need to wait for the end of the project with this way of working).

You must think of your project like a termite mound. You know what a termite mound is but they all have a different shape that’s decided as things progress. So it’s good to have the vision, the objective (a digitized civil registry that prevents fraud), the termite mound, and then it intelligently develops over your cycles. We can live in the termite mound at different moments of its growth. But we prioritize by the most important: it’s what has the most value, usefulness, it can be impact, learning, etc. Breaking down into small pieces that make sense and this question of prioritization by value is key. But it’s hard, so be uncompromising with that while being flexible regarding the difficulty in expressing it, measuring it, breaking it down. During the first week that I mentioned at the beginning you can (there are plenty of tools for this) draw up a first projection of your main stages, you’ll adapt it as things progress as soon as it’s useful.

By seeing every two weeks for one hour the new finished elements and the state of affairs, we limit risks, and we allow ourselves experiments. By seeing each other regularly, we make decisions as things progress knowing more things and without taking the risk of deciding everything at the beginning, too early, without visibility. We sanctuarize all these events: they’re mandatory, we know they’re there, it’s a preserved space, on the other hand no need to make them last for pleasure, and especially they don’t exceed the allotted time, because in any case they recur regularly. If people don’t come, it’s because the project isn’t important enough in their eyes: it’s the signal that it must be stopped.

Moreover the project stops when the ratio between effort and value reverses, or becomes zero.

All scaling questions are approached by working on the division of need, demand, value, and the implementation of coordination between teams.

Memory

I remember Dan Mezick who told that before any start of coaching he would have people read and sign the scrum guide, at the time 19 pages. If the person (a decision-maker, an executive, a manager, at the origin of the request) didn’t read it and didn’t sign it was a very bad start, and very often that’s what happened.

The very small agile guide without agile jargon is 4 pages in pdf: very small agile guide without agile jargon, your turn to play.

I’m waiting for feedback from Tim for the next version.