My undergraduate research looked at how we could apply advances in artificial intelligence to project management. It was an odd area — I daresay I was possibly the only person in the intersection of that particular venn diagram — but it was really fascinating.
At the time, if you spoke to project managers about IT projects, they believed that everything could be fixed with two things: greater rigour around requirements (i.e. nail down WHAT needs to happen in advance) and greater rigour around planning (i.e. nail down WHEN things need to happen in advance). In fact, this was similar to the approach that had been taken in artificial intelligence.
But it failed.
The world is uncertain. When we tried to just get very detailed about exactly what and when things needed to happen in AI, we created agents that didn’t react well to changing circumstances. That froze when the situation didn’t meet their programming. That didn’t seem very intelligent at all.
For a while, we focused on planning — perhaps if we re-planned whenever there were changes we could keep up with uncertainty? But trying to re-plan your full plan of how you do things each time something changes turns out to be a fool’s game.
We see this in people too — the projects that are permanently starting over in terms of planning never get anywhere, the same as the student who repeatedly redoes his revision timetable in glorious technicolor, but never actually gets any revision done, necessitating more time spend creating & colouring the revised timetable, which … oh well, you get the idea.
I won’t give you the full history of how artificial intelligence approaches evolved, but the summary was this: we had to accept uncertainty, focus on only planning the immediate future, with broad direction in place to ensure that immediate next steps went in the right rather than the wrong direction. Then, learning from the experience became essential — making sure that course corrections were possible when needed.
This is why I love agile.
Agile approaches don’t just let you react to change — they are designed for it. Rather than trying to get better at nailing things down, they free you to accept that things will change, that customers won’t know exactly what they need, that requirements can’t be defined in huge detail upfront. Your detailed planning focuses on the immediate future, with broad direction still in place, but you don’t waste time pretending you can see into the future. You stop spending so much time trying to nail jelly to the wall.
Like many new approaches and techniques, there is a certain zealotry amongst some proponents of agile that can be off-putting. There are also a lot of different approaches, some overlapping, some distinct, some actually incorporated into others (for instance, XP (eXtreme Programming) is used in many agile approaches, but is also an approach in its own right). It can all be a bit confusing.
The key lies in remembering that people are at the core of everything. Make your processes work for you — don’t be a victim to the One True Way of doing something. Embrace what works, inspect & adapt. Part of being agile is continually evolving how you do things.
So, if you (like me) find that changing requirements, clients that don’t seem to know what they want (or need!) and ever-changing timelines feel like nailing jelly to the wall, consider looking into some of the agile ways of working. They can help you deliver more, faster, in a higher quality way, able to demonstrate progress to your clients in a much more tangible form. It is an adjustment, but wow is it rewarding when you get it working!
For an introduction to agile and scrum (a specific flavour of agile), see my new course on Learnable.
For a limited time, you can enroll in this course, and all premium content on Learnable for just $9. Plus, you’ll also get two SitePoint ebook downloads of your choice! www.learnable.com/9-month
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers
Form Design Patterns