Does agile agree with traditional software development lifecycle

Question

I've seen many companies that once used to follow plain old waterfall process claim to have switched to scrum and to be now doing agile development. But their software development process does not differ that much from what it used to be:

• Marketing/sales come up with an idea for a new feature
• They pass their ideas and requirements to a business analyst who works with them to create a detailed implementation plan
• The analyst passes the completed specification to the head of the development team
• The development head works together with the analyst and marketing/sales to clarify the requirements and implementation details
• The development head splits the task into parts and schedules them to be done at a certain short-length sprint (usually between 1 week and 1 month in length)
• When the sprint starts, developers are assigned individual tasks
• If necessary, developers communicate with analysts/marketing to clarify requirements (if at this stage requirements change so much that it becomes impossible to complete the feature within the current sprint, it is removed form the sprint and passed back to the analyst for clarification)
• When developers are done with all the tasks, a release candidate is assembled and passed to the QA team
• Testers are assigned to test individual tasks
• At the end of the sprint the QA-approved release candidate is published to production environment
• After publishing marketing/sales take a look at how the requested features were implemented and, if needed, come up with an improvement request that is again passed to the analyst, then to the dev head, etc.

Formally, this approach does no seem to contradict any agile manifesto points: the development team constantly communicate with customers (marketing/sales) to clarify their needs, they minimize risks of shipping the wrong product by making tasks small and getting feedback early (at the end of every sprint), they focus on delivering value instead of following rock-solid contract terms.

Yet, somehow this approach seems fishy. All agile/scrum tutorials suggest that much more changes should be made in order to be "fully agile": make the teams cross-functional, drop strict traditional manager/dev/QA roles, merge separate analyze-develop-test-deploy stages into a common workflow, etc.

My questions are:

• Does the development approach described above really not contradict any agile manifesto points? Are the companies utilizing it right in calling themselves "agile"?
• What benefits does going "full agile/scrum" bring compared to this approach?

Answer 1

I don't see what is fishy about the process you describe. If you have iterative development with short release cycles (even if it is just internal releases) and continuous product-owner feedback and reevaluation of plans based on the knowledge gained by each release, I would say you are agile.

The benefit of iterative development have been known for a long time. For example Galls Law states:

A complex system that works is invariably found to have evolved from a simple system that worked.

This was written in 1975, 25 years before the Agile Manifesto, and it shoots down the "waterfall"-model before the term was even invented!

SCRUM is something much more specific than agile. SCRUM does not just mandate iterative development, it also places demands like cross functional teams, no distinct developer vs QA roles and so on. SCRUM is mush more controversial than agile. In many cases it is not practical (because you cannot just quickly train a QA to become a developer), and its benefits are dubious.

Methodologies are solutions to problems. The problems with waterfall is well-known: You build a system from the spec, but when the system is finished you realize the spec was wrong and insufficient, and now it is to late to change. Iterative development is the solution to this problem.

So instead of asking if your current process is "fully agile" you should consider if there are any observable problems with your current process. If that is the case, analyze if changing the process in some way may help.

Answer 2

The biggest fear for some may be due to calling yourself agile when you're really not. Are we doing Scrum if we only follow half of the principles? What will my developer friends think about this hypocrisy?

The Agile Manifesto isn't very specific. That was done intentionally. They just prefer doing some things than others, but they don't even suggest avoiding the others (Yes, you still should do documentation. Maybe just not so much initially.) They don't give a complete recipe like Scrum or Xtreme Programming may do. It's more of a chef saying, "Cook with fresh ingredients and make food people like."

Your question is are they agile? Forget about practices and techniques. I think you should compare the before (waterfall) with the current approach (whether you consider it agile or not.) and determine:

• Can we handle changes faster.
• Are we releasing features faster.

Many will tell you this is unmeasurable but what they really mean is it's difficult to be precise. There are indirect ways to do it. Just ask the customers. Do you think we're releasing features faster? Are there more bugs? Is it fast enough? You're making software people like; don't make this complicated.

If you don't think things have improved in these areas, then you can breakdown the process and start some specific practices (recommended by an established methodology or figure it out yourselves).

Answer 3

Does the development approach described above really not contradict any agile manifesto points? Are the companies utilizing it right in calling themselves "agile"?

The company you are describing is contradicting one of the four agile manifesto points:

• Responding to change over following a plan

Coming up with a complete specification before development is straight waterfall process. If the specification is set, the project can hardly welcome changes (which is one of the twelve agile principles). Agilists condemns big upfront design (a.k.a big requirement upfront) because it will most likely lead to waste because customers do not know what they want and the requirements will probably change.

Companies may contradict one, two or three agile manifesto points but it does not mean that they cannot call themselves an agile developing company. I would say that a company could call them agile as long as they are practicing agile practices or following agile principles under any agile method. However, if they are doing it well or not is another question.

What benefits does going "full agile/scrum" bring compared to this approach?

Scrum will affect the organizational part of projects and serves as a great discipline with its rules and practices. A handful of the good ones are

• User stories decomposed in tasks in the iteration backlog that describes the work to be done - If done correctly, you don't have to chase BA's or customers for clarification anymore. However, cannot fully cover the case of certain functionalities as a full requirement specification does.

• Closed-window rule - strictly forbid any individual to add functionality and will help reduce scope creep. The functionality can be assessed when the sprint is over and will often not be as brilliant as the time when coming up with the idea. However if it is really critical, product owner may cancel the sprint to add it.

• Daily scrum meeting - The three questions "what did I do previous day?", "what will I do today?" and "any impediments?" will give the project members a great overview over what is going on in the project.

Answer 4

No, a waterfall-style development process like the one you described is not what people who do Agile development call Agile. But who cares what you call it, really?

The real question is why are you doing Agile? If it's just because it's a buzzword that sounds cool, calling the current process Agile certainly is good enough. People get to use the buzzword a lot, and nobody has to change the way they are working.

If you have other goals*, it still doesn't matter if your process is called Agile, or if it is Agile. What matters is if these goals are achieved.

In other words "What benefits does going "full agile/scrum" bring compared to this approach?" is a question that management should ask itself long before getting Agile, not after.

---

*cheaper to change priorities, earlier deliverables, higher quality, better morale, more satisfied customers, lower costs, higher productivity, more transparency, are some of the things that are usually associated with Agile. But which ones you can achieve somewhat depends which process you're coming from.

Answer 5

There a different practises that might make your company more Agile. When I read people are assigned work I start to get shivers over my spline, but if it works it is not anti-Agile persee.

Have a look at the Agile Fluency model. It feels you are approaching level one, but there is still much to gain going up the ladder.