With so many small software projects popping up, “Agile” project management is all the rage. But your specific Agile project is doomed, because you’re clueless. Here’s why.
1) Tools and Discipline are Different
Let’s use Trello. Or Excel. Or Rally. Or Pivotal Tracker. Or Jira’s Greenhopper. I know, let’s use all of them!
The tool you choose to organize your project matters much less than the discipline you bring to the tool. If you populate the tool with horrible user stories, you lose. If engineers don’t update the tool, you lose. If the meetings around the tools don’t run well, you’ve just lost your audience (and your credibility).
Your Trello board needs to flow from Left to Right – it’s primary visual value.
How to know if your discipline is right: Check your email. Are there more than zero messages in your inbox? Chances are your discipline needs work. Email with discipline is one of the best Get Things Done tools in the world. Without discipline, it’s a black hole of loose ends prioritized by recency, emergency, and your highly caffeinated recollection of other highly caffeinated moments.
Bring discipline to how you use your tools and you’ll find their limits rather than your own.
2) Thinking (and Math) Still Required
Agile Project Management is a tool set that has grown from other tool sets. Each of these has been highly tuned to the needs of its context. Lean, Six Sigma, Kanban, TQM, Waterfall – densely packed terms meant to solve specific situations. Software has specific constraints, and different software environments have their own nuances. Are you deploying to a large datacenter? Agile doesn’t make hardware procurement and setup (a very serialized process) very easy.
Take the time to understand why a certain tool is supposed to work and help your team understand it. In other words, Learn the Math about why these small, independently valuable, estimable, testable things result in more cool stuff for your customers.
This book is not about Agile at all, but it’s why Agile works.
I’ve seen Scrum Masters literally reduced to tears because they couldn’t convince an engineer that the Agile way was a better way. If they had read Reinertsen they would have chosen different battles and had a clear understanding of why the next step was the most logical one.
3) You’re Not Big
Most literature about Agile projects take the perspective of a big company. The big company needs to change, so they do Agile things to streamline their product management overhead, reduce their silly assumptions, and win. For them, Agile is a change away from too much structure, and the engineers rejoice.
But your developers aren’t being liberated and don’t love this idea, because Agile tools are increasing their overhead. Why do I have to drag this box? Why do I have to estimate how long this will take? Break down the project into smaller pieces? If your team has to ask why too many times, they begin to say no by default. And they should, because you’re very likely dumb.
Grow Your Project: Instead of showing people an empty burndown chart and expecting them to not freak out about your new Big Brother ways, start with the simple tools and grow structure as more structure becomes valuable.
Take the time to understand before you seek to be understood. Your team really would rather be high performing programming ninjas, so make sure your new collaboration-based approach starts with a highly qualified individual – you.
