Working Software over Comprehensive Documentation. If you’re at all familiar with Agile, you know what that means. Sometimes, however, organizations and people have their own style and methods for how they work and you need to figure out a good compromise for the sake of the project.
I’m working on a distributed project involving 3 companies, one of which is the solution partner who has a more rigid process than we do. Perhaps that’s a bit un-fair, it’s more of a case of “big doc upfront for sign-off” and then an iterative process for the delivery phase. BRD’s, sign-offs, complex change management and internal process control are not things my company worries about, however our solution partner does.
Odds are we’re not likely to change how an enterprise company operates with this 1 project and have to figure out where to compromise. From experience, big documents, deliverables and timelines are generally bullshit. They take the focus away from building software and put the focus on politics and artifacts which can have a whole other level of un-intended consequences attached to them.
I won’t go into those gory details here, that’s not the point of this post.
The point is, your Agile isn’t my Agile, and any project that requires a “big ridiculous document” (BRD, thanks to Gil Broza for that!) I wouldn’t consider to be an Agile project however in some cases, is it what it is and I can try to convince everyone involved why big ridiculous documents don’t make much sense or figure out the best compromise to keep the focus on the project itself and not the process of how the project runs.
When I decide where to push and where not to push, context really matters. In the case of this project, these are some of the factors for figuring out where to compromise my principles:
- this project took about 4 years to come to realization
- this project is in an extremely conservative industry
- this project has conservative stakeholders
- there are contracts, budgets and other real-life stuff that MATTERS to these stakeholders who are PAYING for it
- the company building the solution have their own internal processes that are more rigid than ours
I remember a conversation I had with a couple of middle-to-high managers/directors at a larger company once and they were pressuring me to commit to a fixed scope, fixed date project with a brand new team, most of which had no prior knowledge of the system. After I finished telling them how wrong and stupid they were (nicely, of course) the project was no worse or better off and ultimately my failure to understand their perspective didn’t give me any opportunity to get future help from them or be thought of as anything but one of those crazy Agile know-it-alls.
It was a great lesson to learn. So this time, I have a much better understanding of how to be aware of what is important to the people who are involved in the project and I know areas where I need to compromise and areas where I can influence more.
It’s by no means ideal, especially considering this is now week 5 of the project and we haven’t got into the real meat of building it (it’s a bought solution with customizations so there IS some form of ‘working software’ already) but it’s the best we can do given the contraints we have at the moment. I fully expect that all to change when we start building…