2

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?
Improve this question
5
  • There are some important aspects missing in your process description: 1. How often does marketing get to see what their feature is starting to look like? 2. What happens if Marketing doesn't like the direction that the product is taking and wants to make changes to the feature halfway through?
    – Bart van Ingen Schenau
    Mar 29, 2017 at 12:17
  • @BartvanIngenSchenau, I edited the question to clarify these points
    – Andre Borges
    Mar 29, 2017 at 12:32
  • No approach will ever be agile enough to be considered "fully agile," whatever that is.
    – Blrfl
    Mar 29, 2017 at 13:57
  • 2
    Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team" - Scrum Guide. Your example contains neither self-organising nor self-reliant teams. It's pretty obviously not Scrum.
    – Nathan Cooper
    Mar 29, 2017 at 14:07
  • 1
    Agile likes traditional software development so much, it does it over and over again.
    – JeffO
    Apr 5, 2017 at 20:16

5 Answers 5

Reset to default
11

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.

Improve this answer
2
  • 1
    Right on, scrum != agile. I recommend to anyone who wants to learn agile to read/listen to some of what Alastair Cockburn has to say about it. Too much of what people know about agile is around process. You really need to focus on goals and concepts.
    – JimmyJames
    Mar 29, 2017 at 16:09
  • Does Scrum really suggest your team must train testers to be developers? I've not heard of that before.
    – Jace Browning
    May 31, 2017 at 13:03
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).

Improve this answer
2
  • Sure, change handling and release speed are all improved when you introduce small-length iterations. But is, say 5% increase in feature release speed, enough to say "now we are agile"? I'm asking because there is a lot of confusion about this term between customers and developers, employees and managers. Say, a job seeker is promised an agile environment by his future employer, but on his first day he looks around and says "Hey, but that's waterfall". And the manager is confused: "No, it's not! We have iterations, which makes us agile." Is there an authority that can say who is right here?
    – Andre Borges
    Mar 29, 2017 at 15:25
  • @AndreBorges - I disagree with the first sentence of your comment. There are many teams who don't know how to adapt their coding practices to automatically gain any benefit. Example: Unit Testing. Many will say it allows for faster changes since you can progress with confidence having a solid suite of tests. But what if you're very inefficient at writing unit tests or they're low quality? Agility suffers. There is no gold standard on many things in this industry. IMHO - If being part of an agile team is that important, ask a lot more questions about how it is implemented.
    – JeffO
    Mar 29, 2017 at 22:56
1

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.