Are Agile methods detrimental to your design?
InfoQ has an interesting article entitled Are Agile Development Practices Detrimental to Architecture and Design?
I've said it before and will say it again TANSTAAFL - There Ain't No Such Thing As A Free Lunch (with thanks to Robert Heinlein). You can't expect to suddenly change to run an Agile project (e.g. using Scrum / XP) and expect miracles - that is a gain to your project without any associated pain or cost.
My feeling has always been that with Agile development you need quite senior people who can run the project fine without the heavier and better known "structure" of traditional processes. Also you'll hope that they'll pay attention to key architectural and design issues without a traditional BDUF architectural or design phase.
But regardless of the type of process you choose (BDUF vs Agile) there are three people (or three roles) you need on your project for long-term success that is release-after-release year-after-year.
You need
1) Someone who knows either the vertical area (e.g. Financial Trading Systems or the Retail sector or Cell Phone advertising) and where that field of expertise is going (e.g. more analytics for trading systems, SaaS / ASP models for Retail).
You also need
2) Someone who knows the users and their likes / dislikes ( e.g. they like responsiveness and dislike overly flashy apps but may be amenable to Web 2.0 technologies such as twitter more easily) also if there are any key users to watch for (e.g. head traders or your CEO's best friend!)
And finally
3) Someone who understands what all of that means for the Technical Architecture and Design
and who can create a roadmap to get there . . . . .
Where do you find such folks on your team?
- #1 and #2 are typically Product / Project Managers / Business Analysts
- #3 is typically the "Architect" / Technical Team Lead for the project
Labels: agile, Software Architect, software architecture, software development process, trends, usability, users
posted by Frank Kelly at 9:11 PM
View blog reactions
3 Comments:
I have to say, I typically enjoy your blog and find your posts rather interesting. This one though, seems rather... well, I don't think I get your point.
You mention that Agile is no silver bullet. No gain without some pain. Surely all methodologies have their issues around (re)training and getting everyone comfortable with a new way of working.
I just can't figure out if you meant that agile projects require senior people (I'd disagree) or just that your three personas are required on an agile development team (I'd agree).
Without the BDUF phase, we do need each developer on an agile team to be competent enough to design and build a small feature (story) within a release. I'm wondering if your worry is that this code may not fit into a big-picture architecture?
I think high-level agile modeling can and should be done upfront (a lightweight doc!) to lay out the big picture. This can include system interaction diagrams, component diagrams, high level use cases (stories), etc. This should be enough to get everyone on the same page.
With iterative agile cycles, code is designed, built, reviewed and refactored all in a small and idenified period of time. We get to check in and vet the software against the architecture often.
I'd argue that with BDUF, there is much more room for developers to "drift" away from the original design, because of a variety of reasons (some may be new/changed product direction, some may be technical).
In an agile project, we don't worry. We don't get nervous that the architecture will be blown away. We don't worry that less-senior developers will mess everything up. We work together, we review each others work constantly and we do our design work iteratively and collaboratively, and I love it.
Let go of the worry of a design running wild. Allow the design to be *improved* as a project evolves. Don't create another hundred-page "design document" after countless hours and weeks of effort. After all, your business unit are not paying for your design work, they just expect it in your software. Put it in there instead of in another document (UML or otherwise).
(and yes, I work in Financial Services too, so this perspective is likely to be relevant.)
7/25/2007 12:24 AM
Hi Brian,
I guess my main point is not in slamming agile (as the original article I reference does). It's that people are expecting too much from Agile processes - expecting that a good architecture will emerge somehow from just coding each feature/story.
I know Scott Ambler etc. have advocated "agile modeling" techniques etc. but you have to admit that XP as advertised pays little attention to overall architecting of the system compared to coding features/stories.
Someone has to be looking out for the overall design and architecture and ongoing adherence as well as adaptation to changing requirements.
But that's true even in BDUF world.
IMHO to do that you need you understand your application area (the vertical space and the users) as well as technology.
So I guess my point is - regardless of following BDUF or Agile approaches someone has always got to be looking to the future and preparing.
-Frank
7/25/2007 10:20 AM
I'd agree that overall agile and XP methodologies don't prescribe much in the line of high-level architecture.
What I think compliments agile/XP practices is an evolving target architecture that aims to address the concerns of the majority of all projects/applications within a development organization.
The concerns that need to be identified and addressed in that target architecture would include non-functional requirements, including perhaps multiple levels of sophistication for each. These architectural guides should frame the development efforts and do much to contain the breadth of technology solutions permitted within a team.
As long as the architecture is pragmatic enough to allow for some variation of complexity to solve the majority of the problems our applications face (caching, for example), the developers should feel more at ease working inside that architecture compared to facing a blank slate each time a story gets handed to them.
Back to your original post though, you're dead on that there is no free lunch. You don't get to forget about architecture if you "go agile" and agile projects without any architectural direction may devolve faster than BDUF projects that are more prescriptive.
On agile projects though, thankfully we don't really need to "know" our users as you mentioned. We don't need to determine if they like or don't like a particular interaction pattern (standard pop-up windows vs. ajax-enabled DHTML windowless windows, etc.). We don't need to know what they like at all. We ask them. Every day. "Product managers" or the like can help facilitate constructive discussions with a user group, but it's that immediate feedback from actual system users that sets this process apart.
As many of our business partners are finding out, "going agile" is more work for them during the development process. (going from no work to some work, really) What they get in return is an application thats exactly what they wanted. They opted for a particular interaction pattern. They specified how that data should be presented. In return, they use the app more than they ever would before. This has the added bonus of reducing training in some cases, and limits the need of evangelizing a new tool (a common issue when re-vitalizing a paper-based process with a technology solution).
7/25/2007 12:43 PM
Post a Comment
Links to this post:
Create a Link
<< Home