Is there room for good/tested design in "Agile" setting?

Question

I just came out of an "Agile" team where the sprints are 3-weeks long, and during this same time, about 12 hours of that time is spent on exercises such as Scrum grooming, reviewing, Scrum, and retrospective, and the team works to develop and test within the time left.

Of course, this is the typical Agile implementation you find in many small/medium sized companies. You hear talks of avoiding code smells etc. in many of these settings, but the fact is many Agile teams I have worked with rarely spend more than 1 hour thinking of the design for the story/tasks on their plate. My question is, to ensure you do not end up with spagetti code, how much of the sprint-time should be allocated to ensuring that each and every new feature, new tweak,patch, passes the "good design" test?

I came across this article on Martin Fowler's blog, Is Design Dead?. I do believe that is an excellent read however, real-world implementation of these methodologies (XP, Scrum and Agile included) tend to throw design out the window. My question is, is there really room for good design in today's 2-3 week sprint "Agile" implementation world?

Maybe I should re-state that nowhere have I suggested that the Martin Fowler article included above says there is no room for good design. That article actually argues otherwise. My question here is simply to understand where 'good design' fits into real world implementations of the various "agile" methodologies. In a typical agile team, you may find that some of the stories where created long before many of the team members were brought on board. When you have a team of ,say, 10 developers that pick up 30 tasks to work on for the next sprint, how do they ensure that each piece is correctly designed to integrate and scale with the rest of the application?

Answer 1

The Development team is in full control of how to do the work that's included in the sprint, and that includes deciding how to deal with design and overall conceptual integrity of the product you're building.

One way to do that is to split the Sprint Planning meeting in two sections: an initial selection part where you pick the work to allocate to the sprint, followed by a second part where the team as a whole looks at that work to see how it impacts the design, and how the design needs to evolve to accommodate the new functionality. Based on that discussion, you'll add design and refactoring tasks to the sprint backlog. Other teams hold design meetings during the sprint, or have quick design sessions with the architect each time a team member picks up a new story.

There's an assumption behind this, though: that the stories were framed from a user's perspective, and that they don't imply a particular technical implementation, which is then left for the team to decide. Perhaps what you saw in your project was that the stories in the Product Backlog were really defined as implementation tasks, with a particular design in mind.

Answer 2

This question is predicated on the idea that design is somehow a separate activity to coding.

Agile methodologies view, "a design" (i.e. documentation of how to build your software), as less valuable than working software.

read[sic]-world implementation of these methodologies(XP and Agile-SCRUM include) tend to throw design out the window.

I think you may have missed the point of, "Is Design Dead" article. Fowler answers the question himself, for XP, with:

Not by any means, but the nature of design has changed.

I'd suggest you re-read the article and consider raising new, more specific, questions

Answer 3

Design is a necessary component in any Agile implementation. However, where and when design work is done depends on the team.

You'll see all kinds of design practices from the very formal, "lets task out all our stories at the beginning of the sprint (if you are doing Agile-Scrum)" approach to "hey, I'm picking up a new story; maybe I should have a chat with my architect or tech lead."

In Agile-Scrum, the planning ceremony is not a great place to do design. Its not relevant to participants such as the PO or QA resources. If you need to, have a formal design meeting with the dev members shortly after planning. Try and keep design out of planning since it will (usually) turn the ceremony into an arduous 3+ hour journey.

If you think your team is struggling with getting their design nailed down, steer toward the a more formal approach of taking stories and breaking them into documented implementation tasks through a formal meeting or check point.

Very high maturity teams may be more comfortable with ad-hoc design sessions throughout the iteration (if you're doing Scrum) and only a very high level architectural discussion at the beginning of the iteration to make sure everyone is headed in the right direction. These type of teams generally don't rely heavily on tasking stories in their agile tracking tool as its seen as a documentation overhead rather than planning/learning activity. They will rely more on code reviews and ad-hoc communication to ensure they have sustainable designs.

Keep in mind, any story that does not convey the customer perspective or underlying business value is also likely to make design activities harder for the delivery team.

Answer 4

The short answer: Yes there is: use tasks in your sprints, use code reviews (or pair programming) and use print reviews.

The longer answer: The aim of a sprint planning meeting should be for the whole team to take one or more stories from the backlog and decompose them into a set of tasks. As such, we partially go from just "what should it do" to "how will it do it". Every member of the team is involved, so everyone on the team should have an understanding of how the tasks interrelate and thus how the design of one might affect the others.

Each task is only then done when someone has implemented it, another has reviewed its quality and another has tested it (though the last two may be performed by the same person). Finally, should ideally be reviewed by the product owner too. The purpose of the review is to consider the quality of the code, as well as how well that solution fits into the overall design of the product. If you adapt a pair-programming approach to developing code, then the code review is implicit in the development itself.

Lastly, in the sprint review, the results of the effort for that sprint are presented to the customer. At that point, they then get the right to reject the efforts as not having achieve what they (thought they) wanted, thus ensure the product is not only high quality, but actually does what's needed too.

(Edited to address inaccuracies pointed out by Venture2099)

Answer 5

TL;DR

Agile frameworks don't do away with design. Instead, effective teams treat design as an integral part of each potentially-shippable increment; this keeps the design work narrowly-focused on—and temporally adjacent to—the implementation of each feature.

In my own experience with agile methodologies like Scrum and XP, I generally find that:

• Some high-level design work naturally happens when stories, specifications, or requirements are decomposed into tasks for the current iteration.
• The bulk of the remaining design work happens during the development of unit or acceptance tests.
• Integration work is more often about validation than design (although reasonable people might disagree about definitions), but either way integration should be part of the Definition of Done.

Just-in-Time Design

Agile methodologies certainly support design as part of the development process, but the iterative development model lends itself to "just-in-time" or "just enough" design rather than the big, upfront design one finds in traditional waterfall projects. When done correctly, a team will do just enough design during the iteration to support the current development effort; extensive engineering for features that may or may not remain in scope during future iterations fall under the YAGNI rubric.

Driving Design with Tests

Agile practices such as Test-Driven Development (TDD) and Behavior-Driven Development (BDD) can also provide design within the iterative development model. When done properly, test-driven approaches provide a mechanism for driving implementation directly from the design process. A test-first approach can also help a team limit its design efforts to the features actively in development during the current iteration.

Design as a Deliverable

In the rare case that a design is the deliverable, rather than something that is implicitly estimated as part of the level of effort for a given feature, it can be treated like any other increment within the framework. For example, in Scrum you might:

1. Write one or more user stories describing the design work to be done.
2. Prioritize the design stories on the Product Backlog.
3. Estimate the level of effort for the design work during Sprint Planning.
4. Accept the design work into a Sprint that has sufficient capacity.
5. Decompose the design work into tasks on the Sprint Backlog.
6. Deliver the design artifacts during the Sprint Review.

Accounting for Design Costs

Note that design work is never free. Design consumes time and resources during each iteration, and this work must always be accounted for and factored into the team's estimates. Design work can be estimated:

• Explicitly, such as when using design stories.
• Implicitly, when design is part of feature development, the Definition of Ready, or the Definition of Done.