A lot of software projects end up getting tangled up in processes and paperwork – and a lot suffer from having no documentation or direction at all. So how do you strike the right balance between getting stuff done and doing it right?

Be Flexible

The best attribute any modern software team manager can have is to be flexible. While popping your foot on your head might help distract people from another timeline shift, being flexible in your approach to planning is what really helps.

The best way to encourage flexibility and adaptability is to instill this as a default behaviour in your stakeholders. Start them off with the expectation that things will change, and that it’s a good thing, as it means we are adapting to what we learn in order to get a better outcome. Classic project management can fall flat here, by sticking to a rigid plan and only accommodating new requirements and changes to priority by sacrificing a deadline or budget.

Be Agile but, Like, Properly

If someone asks me if I use Agile, Lean, Kanban, JIT…. I’m generally inclined to tell them (once I am done rolling my eyes) that I do whatever it takes to get the job done, and get it done properly.

Agile is a ridiculous buzzword in my opinion, as it’s premise is of flexibility and of course “agility”, and yet many people interpret it as a rigid and prescriptive framework. The point of an agile approach is to get things done quickly; to win quick, or fail fast. Try and adopt agile methodologies without getting hung up on following them to the letter.

Don’t Forget Documentation

In my experience, software teams find documentation a hindrance and it very rarely gets done. If this is the case with your team, you need to break the habit. Getting things done doesn’t mean you get to skip out on the paperwork, but there are ways of making this lean enough that even your developers will tow the line.

This trick is to do enough. You need to find ways to quickly generate simple, clear documentation that is actually useful to your project. Instead of investing heavily in something like a Project Initiation Doc, go lean with a requirements doc. Bonus points if you use user stories. Even if you end up covering a table in Post-It notes, photograph it and stick it in a shared drive. This type of documentation is brilliant in that it very simply captures what you need to do, and compiles enough reasoning to help your team understand why it needs to be done.

In production, a software team needs to work with the mindset that they might get hit by a bus in the morning. As well as encouraging everyone to always wear clean pants, you get enough documentation to explain what was done, how and why, in a way that someone else could pick up work mid-way and carry on with it. Always act as if you won’t be in work tomorrow, and leave enough notes to help the job still get done.


When everything else is flexible, at least one point needs to be fixed and stable, and that should be your timeboxes (or sprints, whatever you choose to call them). Set a time window, and agree a release time at the end of it. Everything else in your project can change, but this remains a constant.

Using timeboxes provides benefits to a team and to your client. In a team, everyone can focus on a goal in the knowledge that it’s not going to get moved (the number one cause of mutiny in software teams). Regular releases are good for a team’s mental health – things get done, look how productive and efficient we are! And if things go wrong? Well, worst case, you’re only two weeks away from a fresh start.

For a client, it means a constant stream of updates. Things are always moving and progressing, the two week release window generates a kick-off point for conversation, helping them to always be involved. It’s worth noting, that a release doesn’t have to be to a live environment, some jobs obviously need a lot longer. But by periodically updating your staging environments, and showing the client where possible, you create a sort of “save game” point in your project. The psychological impact of this is significant – the project feels secured, you can reflect on what comes next, and if necessary, pop back to a previous save point and have a do-over.

In Summary

There is no real right or wrong way to manage your software projects, because every project and every team is unique in its setup. It’s a case of setting simple ground rules that will scale to any project size, and being strict in sticking to them. For us, that’s gathering and prioritising requirements, using timeboxes, and accepting that things will change and being ready for it.

Tell us in the comments, what basic project rules work best for you?