Having problems with message search?
The problem with architecting and designing everything upfront
is that that architecture and design is in response to requirements. If you
take industry statistics that 35% of those requirements change, and that over
50% of them are rarely or never used, much of that work is a waste. In Scrum we
use emergent architecture and design. The non-functional requirements that
drive the architecture and design are usually high value, so high in the
product backlog. We have to build at least one piece of business facing
functionality every Sprint, so we only built enough architecture and design to
support that piece of business functionality with adequate architecture and
design to meet the non-functional requirements (stability, security, response
time, etc.). Then, every subsequent Sprint, more and more of the architecture
and design emerge, in response to more and more business functionality. The
purpose of this is only to build architecture and design in response to actual,
high priority business needs. As we do so, we meet three needs: we prove that
the architecture and design actually work, we have something to get feedback
from the user, and we start improving our estimating. As the project or release
proceeds, architectural and design work declines and business functionality
increases.
In order to employ emergent architecture, every Sprint must
leave behind clean, commented, refactored work. Otherwise emergence hits the
wall within six Sprints (or sooner, depending on how bad the morass is).
Ken
From: scrumdevelopment@yahoogroups.com
[mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Wolfgang Schulze
Zachau
Sent: Thursday, June 12, 2008 6:32 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Scrum and Architecture
Hi Sue,
seeing that nobody else has responded to this
yet, here's my 2 cents worth:
The whole idea of doing your architectural/design
work as you go along comes from the experience of projects that are so big and
complex that any attempt to do all the design as BDUF (big design up front)
will stall the project completely. In those situations it is much better to
just do a little basic architectural design and then start implementing
features in an incremental fashion. You should then develop your architecture
as you go along, i.e. as the additional features require it. And this works
well under the following two conditions:
a) you use TDD, refactoring and automated
regression testing RUTHLESSLY FOR EVERYTHING.
b) you have experienced people on the team
(i.e. people with experience in all of the items in a) above, plus experience
in architecture and design)
If you don't have these two things in the
team, then you will need to either have to get them from the outside or you'll
have to accept some deficiencies when it comes to architecture.
So why is this a good idea? Well, for a
number of reasons:
1) It avoids stalling the project when the
BDUF would be extremely complex or large. Often in large projects there is a
tendency to go around in circles at the design stage, because the requirements
keep on changing and/or the stakeholders can't make up their minds and/or new
requirements/acceptance criteria/etc are discovered.
2) It avoids waste. You only build as much
architecture as you need, at any point in time. When you need more, you
refactor.
Having said all of this, nobody says you
should't do any planning at all. That would be just plain stupid.
Regards,
Wolfgang
From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of sue.bramhall
Sent: 11 June 2008 15:37
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Scrum and ArchitectureYep we are now working Just in Time i tell my new converts to Scum,
but they cannot grasp this concept initially having had previous
experience of planning, analysis, solution design docs etc. So does
anyone out there have a good simple example on how to explain why this
is now a good idea, bar actually having to go through the experience?
Offline 
Send Email