Clients often come to me to ask how they should set up their instance of TFS ALM so that it will reflect their software development lifecycle.
My usual response is a question: What is your software development lifecycle?
Now, that is actually quite difficult to answer for most developers and development team managers.
Most people either say waterfall or agile.
It is rarely waterfallers who are asking for more process or tools. It is usually the neo-agilistas who want imposed structure . Everyone is doing agile or they did it once and it didn't work.
There are many tools out there promising to agilify your software development "process".
They will promise that it doesn't matter what standard your developers are at because the tool will raise them up.
They will promise that it doesn't matter if all you've ever done is waterfall with an avalanche of specifications and documentation because you can just stop doing that.
They will promise that if you sign with a little blood then everything you do will be faster, better and leap buildings in a single bound.
Let me tell you honestly and with great confidence that there is no software tool on the market that will do any or all those things for you.
Spending thousands of hours building, mentoring and empowering agile teams has taught me three very important immutable facts:
- You need to train your teams to be agile and that can only be done by introducing experienced agile coaches;
- No tools will ever save you. Tools will aid you in recording and tracking your progress but they will not set that progress in motion or maintain its momentum; and
- Communication and transparency are the keys to building great software, which means your teams must talk, you must talk to your business who set the requirements and you must be honest about what works and what doesn't.
When I start an agile team from scratch, I start with a bunch of cards, some Sharpies and a will to encourage people to talk to each other by creating a safe working environment.
Jira or TFS ALM or whatever silver bullet you have been promised is nothing if it isn't accompanied by experienced agile practitioners and an acceptance that you will learn along the way.
Start with paper walls and good people.
2 comments:
What would you describe as the significance of the paper walls? A reference to setting up lightweight structures, rather than going into constructing something heavy and inflexible? Or not constructing impenetratable silos between departments?
The paper walls are a reference to using cards or sticky notes instead of complex software tools that track the process. Start simply and then add tools.
Post a Comment