Could taking design lightly be a pitfall of agile methodologies causing constant rework or is it a misunderstanding of the methodology?

Question

I've been working for a year now in an agile project to redesign an insurance application. I really like working in an agile environment, although management and analysts I work with still have waterfall thinking ingrained and makes it a little complicated to embrace the new paradigm shift to agile.

From a developer standpoint sometimes I feel like since we're doing "agile" we don't over-think or think enough our designs and just go with the flow and refactor later. Many times that ends up in rework because we never put enough though to certain pieces of the application. As far as I understand, agile is like having small waterfalls and deliver small pieces at a time (iterations), but sometimes we lose the big picture and end up paying for it later with rework.

Are agile methodologies encouraging or tolerating procrastination more than traditional waterfall? Is this constant rework for pieces of software with defined requirements acceptable?

Is anyone else experiencing something similar in their projects?

Answer 1

Part of this is expected and good, part of this is not, and we can't really tell you which is which.

The main focus of agile is delivering what is important now, based on what you know today. Take a little bit of time, implement this important bit and ship it so that you can get feedback on it sooner rather than later. Some of that feedback will be "ugh, this actually kinda sucks in practice!". This is the good sort of rework that agile promotes. Since you caught this early, you can fix it early.

The other side of this is that what is important to business people is rarely important to developers. As developers, you need someone to advocate for technically important things like infrastructure, training, and technical debt. This can help eliminate some of the "gaps" missed by most agile environments. But in the end, the discipline to do a good job rather than just slapping together a solution will fall on you the developer - agile or not.

Answer 2

Although agile is based on a minimum viable product and only delivering what you need, it is also based on making the best decisions you can with the information you currently have.

This means not only considering the user story you are working on, but what you know is coming, or likely to come. The correct time for design is whenever you need it - considering dedicating time to design when you think something you are doing might cause a problem in the future.

To me agile does not encourage procrastination or delay of design decisions, it allows you to remove the huge overhead of system design at the start (which is never right anyway), and integrate it into the project as and when it is necessary.

There is always going to be a degree of re-work in software and there will always be unexpected things cropping up, but if as you say the requirements are well defined and truly unlikely to change, you can consider them in design relatively early on and may still spend a reasonable amount of time on design work at the start of the project. This can be considered as part of 'sprint zero' as well - basically planning a framework for the project.

Answer 3

In the agile setup I am working with,It is what the team wants.The definition of team here does not include managers and business folks.I agree this may not be possible if you are working in a place where business people have a more say at technical issues.

In our case if the team feels that some feature needs a design discussion, we do come up with design documents and nice block diagrams.But this is sometimes an overkill for certain features and makes more sense to get it over with as quickly as possible.

It might help to have a tech person experienced with agile workflows to steer demos and retrospective where the respective business person can also participate and understand what working in agile actually means.

Every team is different so It is up to your team to figure out what is best for you,And I feel agile lets you do that more easily than other models open communication opportunities with demos,retrospectives which sparks discussions and improvements.

Answer 4

Agile its not about not designing, agile its about designing all the time!

In waterfall design is constrained to one phase, then programming, then testing... in agile you are designing/programming/testing all the time. If your problem its that your are taking poor design decisions that compromise the future extensibility or maintainability of the application learn from this mistakes and try to take better decisiones the next time.

but in agile you have a lot of time for designing, in fact, all the time its for design.

Answer 5

All mature engineering disciplines include a design/systems engineering style phase (or multiple iterative phases).

The problem with software is that the design space is not as constrained as most engineering problems, so there is a lot of uncertainty/many ways to accomplish an engineering task, this is why Agile was developed.

Agile is good for some things, like customers who want websites, but don't really have a good idea of exactly what website they want.

Test driven development (TDD) and Agile, are however, poor (or poorly implemented) at other things, especially things which require actual engineering like :

• Mathematical modeling
• Algorithms
• Constrained or task specific systems
• Mission critical systems

etc. Any engineering solution requires some iteration, this includes disciplines outside of software, but we absolutely cannot disregard design entirely. Design is necessary to achieve efficient, robust, and scalable solutions.

Agile has been useful for the problem spaces where constraints are not defined or are not even known, but even in these situations design still needs to be included in the iterative process. Recently I have encountered what I consider to be too great of a swing to minimize all design, and this is especially prevalent among Agile evangelists in my experience.

A parable of what can go wrong if you swallow too much Agile/TDD koolaid : http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html