The more I read on agile practices the more I hear some fairly edgy ideas about requirements gathering, design, and architecture in the agile world. While I understand the concept of embracing change, there has to be a line in the sand somewhere of how your company performs its business and how you build software to enable that business. As I work with clients adopting Scrum I find different levels of the YAGNI (Your Ain't Gonna Need It) principle and the idea of building extensible software that gracefully accepts change. My struggle is that I need to find a happy medium with the majority of my clients. Martin Fowler's article "Is Design Dead?" makes an argument for something in between also, but he focuses more with contrasting against the more edgy concepts in XP. Unfortunately a large number of agile pundits have taken up the idea that design up front is a wasteful practice as is gathering any type of detailed requirements. These are not just the inexperienced newbies blogging from their soap boxes, but well respected and experienced thought leaders in our industry.
So is up front requirements gathering and design really dead?
I have never been a agile purist and I think that for my clients some hybrid is more prudent. In the past I have been on Scrum teams that designed on the fly and kept the YAGNI mantra. Sometimes this resulted in some patchwork architectures and some disjointed business themes in the application. While I do think it is a great idea to embrace change, a basic vision for both your business case and architecture/design of any software solution are needed to keep the smaller iterations on at least some common path. This vision should be able to change as well, but there are some fundamental things that most probably will ring true for the solution. Determining that line is a black art. Too little and you risk being all over the place in your deliverables. Too much and you start becoming too rigid and have lost the benefits of an agile approach.
So how do you know how much up front work to do?
If I had a textbook answer I would give it to you. And it would most likely be wrong. Every case is different. Each client's situation and environment is different. As a company's business evolves the line might have to move also. But I do think that forming a basic business case as the initial vision and some high level architecture and design is almost always warranted. Even Ken Schwaber, one of the originators of Scrum, advises to start as soon as you have enough backlog items to start a sprint. You do not need grand functional specifications and loads of UML diagrams. As is often quoted "The plan is useless, but the planning is essential." When determining if you need to detail a specific business case ask yourself how essential is it to our core business? Higher value requirements always get the most attention. As far as architecture/design, defining the basic components and their interactions at a high level should be enough to ensure your deliverables follow a cohesive path. When determining how extensible a given component should be, concentrate of the most probable changes rather than inventing all sorts of possible future scenarios.
So how can you gather requirements and perform up front design while still being agile?
If you are going to start a sprint with just enough product backlogs items then some of those product backlog items should be forming high level business cases and prototypes so that subsequent sprints will have the benefit of an uniform vision on both fronts. I also believe that you do need some level of documentation for these outside of just the backlogs. A wiki is a great place for them since by its very nature embraces change (and the good ones can provide history for those people who just cannot get over the idea of this type of change). To take that idea to the next step, Team Foundation server allows you to add links to web pages on backlog items so that you can tie the documentation to the user functionality and development tasks. If you want to go low-tech use flip charts and save all the paper. Post it on the walls of the room where the team is literally surrounded by the business and architectural vision.
Even if you are well into an agile project, you can always have the stakeholders redefine the vision if you feel you are straying too far because of only thinking about the next sprint. Change is inevitable, but your company's core business fundamentally changing in not very probable. And good design should elegantly accept change also. I do not think up front gathering of requirements or design is dead. I just think that in agile environments it has evolved and shed its more useless features.
2 comments:
I see both of these questions as largely old and tired (how much design up front? how do i handle requirements?). I wish people would move on.
There are good answers to both (even if they aren't simple or easy to explain).
Of course, there are a lot of "agile" teams that don't connect with the larger community, don't learn with everyone else, and therefore are stuck trying to formulate a whack dogmatic answer without the help of anyone outside their little team of inexperienced devs.
I find the same people are the ones that tend to think that testing is optional and that agile is all about not doing documentation and/or not doing design (or haven't a clue about how to do good design).
I think it's a bit naive to say that these questions are "old and tired" and that people should "move on". It's hard to learn anything if you think you already know everything. Each shop will have to find the approach that suits them best so there is no silver bullet answer (complex or simple) that fits everyone. And while I think engaging in the agile community is a great way to gather some insight; attending conferences, memorizing book passages, and waxing philosophic at the local coffee shop does not replace experience. While a good many of the pundits do have real world experience, many think they do because they have applied small agile mechanisms in isolated development shops with some degree of success. For the larger shops that I have worked with it takes more than a few developers with a handful of note cards and a few unit tests to start down the road to adopting an agile approach.
Simply dismissing any conversation on these topics as something left to “inexperienced devs” in their “little teams” sounds elitist and counter to the agile community that normally seems more tolerant. Most of the people I meet in the community talk about wanting to be the worst developer in the room so that they are always learning something new. I openly admit that I am no expert or purist. My goal is to find the best of what any and all development methodologies have to offer and try to fit them to each client’s needs. That often means wading through the rhetoric and finding the pragmatic applications behind the ideals. Every now and then I feel I experience some mixture of philosophy and mechanism in my daily work that could be helpful to others in the community. I can only hope that the community is not so inflexible as to believe only those full time community pundits can have an original idea and that all the questions have been answered.
Post a Comment