Some feedback I got from my previous post about the different approaches to project management is that I was a bit Agile biased, and that my modest expertise in this particular approach was visible. Well, it’s right, I am a bit biased, the reason being that I work Agile on a daily basis in my firm, both in terms of client work and internal work.
I discovered the Agile approach quite recently, a bit more than a year ago when I left my previous employer (one of the Big-Four) and joined the boutique I am still in today. At first, I was a bit sceptical, with the scepticism from those who discover a new way of working, which disturbingly challenges the way they have worked until today.
But, after a while, and after understanding better what Agile is all about and applying the principles in my daily work, I actually started to use some of the Agile patterns beyond the borders of my job, at home. First, it started with our wedding planning, where my wife and I had a very Agile way of planning for the very last details of the D-Day.
Then, as we were about to move to our new place, I used an Agile framework again : the Mad Sad Glad retrospective, as a way to discuss what we wanted to change in our new home compared to what we were having at the time. That had been very powerful as it permitted us to address multiple issues in our households and understand how each other was perceiving things that mattered for the other one and take a new perspective on them.
After the move and during our honeymoon, we decided that we wanted to be a bit more ambitious in making our personal projects move forward and reaching our goals as a married couple. Therefore we started to formalise those into projects as well as, and we incorporated as well all the stuff to do in our household in order to manage them altogether in an Agile way.
In my overiew of the various project management styles, I forgot to say something criticalIn mt revious article, in which I present what agile is about, I actually forgot to say a very importan in our new home agile about Agile : the whole point of the approach is to make ourselves more Agile, not so much to apply Agile. One should always keep in mind that Agile is first and foremost a set of principles, a mindset to embrace, or should I say a way to be, rather than a well defined project management methodology. Nothing else annoys me more than people trying to explain to me what true Agile is, as if it mattered to make daily meetings 15’ instead of 10’. Nobody cares, and that’s not the point. If we want to focus more on the methodology side of Agile, we’d rather speak of scrums, which is one application of Agile… among others. Some other people speak about Lean Agile, and others just about Agile. Well, I think you got the message : there are as many Agile methods as there are Agile projects and teams. But the only truth is that we only succeed in Agile delivery when we embrace the principles and embed them into our behaviour.
How can we become more Agile and how is it relevant for our home ?
I said that Agile was about a set of principles. The core principles are better explained in the Agile manifesto. However, let me try and reformulate in a less jargony language what I believe those principles are about :
- It’s better to do stuff than to wait – in Agile, we start to work, build, develop or deliver as soon as we know enough, not when we think we know it all. Therefore the work is executed in a linear way along the way, and not squeezes between two chevron of a project plan that wll never be right. Also, getting outcomes quickly helps to keep up the motivation of a team in moving towards the outcome as the tangible output is visible along the way
- Real progress towards a goal is made step-by-step – our brain usually has the vision in mind, the « end-product », whatever it is we want to achieve, in a very nice and polished way. And when there is excitement on top that, it seems very easy to reach. However, our brain has trouble to have a sensible and realistic idea of all the effort required to achieve this goal. Therefore, when we are excited about a goal, our first thought is « let’s nail it », and we think that the best way to do so is to spend 8 hours on it straight away and try to reach the outcome as soon as possible… and we rarely succeed. Why ? Because the key to achieve stuff is through consistency and steadiness, and to climb the stairs step-by-step, without rushing but by keeping the pace. That’s what Agile It breaks down the final output into incremental steps, and make each incremental step a little goal in itself to be reached in a relatively short period of time. It keeps up the motivation and allows stable and sustainable progress.
- I can do anything, but not everything – This is one of the key strengths of Agile: it assumes that any team or person is working at full capacity, and therefore the purpose of the project is to get the most value out of the resources available. Whereas in a waterfall mindset I would say :
I estimated that A, B, C and D should take about two months to be done, therefore in 2 months time I want to have A, B, C and D done and dusted. But committing on something doesn’t mean I can execute it. And if I work to deliver the full scope, I am likely to come to the end with a bit of A missing, a bit C as well, and may be also with a bit of B and D missing. The project is ruined if I don’t get more funding.
In Agile I’d say :
Ok, What is your priority order : B first, then D, then A, then C. Well, let’s go in that order and see where we are after two months. If we’re short of resources, C will be impacted (the lower value item). Not great, but my client is much more likely to provide me with some additional funding if I already delivered 80% of the benefits… - The most important items comes first – Agile focuses on what I should do NOW to get closer to the goal I want to achieve. What is going to make me closer to my objective is to get the most important item done first and foremost. Then the second most important. Then the third etc. And if Pareto is right, after spending 20% of my project resources, I would have reached 80% of my benefits.
- Short cycles of work allow continuous progress and improvement – Long phases of work are boring and are the worst way to keep a momentum within a team or even on our own. After a week or so, the initial excitement fades away and on any project, we are usually left only with big problems and a lot work to do whereas we don’t have much time available and we don’t even have the enthusiasm.
That’s why in Agile, the solution is to break things down and to re-create a new momentum every week or so on a new item. Small objective – plan – design – build – review – and everybody happy! Then start again with the next piece. It’s tangible, balanced, and it also allows you to visualise the progress on your project. And, last but not least, it allows you to improve at each new cycle. Oh, this week I did that wrong – let’s make sure I do it differently next week. You don’t only iterate your « product », but you also iterate the way you work. And that’s called continuous improvement. - Priorities can change, there’s no big deal – « The plan says that A should come first, therefore we should start to build A first ». Sounds familiar, doesn’t it? You don’t question the plan, because the plan is right by definition. Even though at this stage you know that the plan is rubbish, and you know that there is no point to do A without doing B first, you can’t do B because you are committed to do A by the next deadline, and the plan has been signed off by the whole crowd of senior execs.
Thankfully, in Agile, it is perfectly acceptable to change priorities on the way. It is even a must-do, because as your project goes, new information is available, which changes the nature of the project. And the priorities need to incorporate this new information and adjust accordingly. - Pull, don’t push – In the Big-Four (where I used to work before), when a project plan was produced, it was assumed that we would deliver what is on the statement of work, whatever the cost: long hours, working week-ends etc. We pushed the scope into the Work in Progress and the machine was just getting on with it, on the edge of burning out. In Agile, the team is in control of the work. We pull the stuff to do into our work in progress when we are ready and when we are done with the previous items. We therefore avoid bottlenecks and ensure a consistent progress on the project.
That’s it for the foundations. In the second part, I will explain why all those principles are well suited to be applied in a household.
The Home Geek 
1 Pingback