Agile vs Scrum vs Waterfall vs Iterative...

[Gilly]

Ideally, in an agile process, all types of work would finish at exactly the same time. The team would finish analyzing the problem at exactly the same time they finished designing the solution to the problem, which would also be the same time they finished coding and testing that solution. All four of those disciplines (and any others I’m not using in this example) would all finish at exactly the same time.

I ran across this whilst looking up some implementation methods today. OK, this is one person's take on it only, but having come from a live services background and being relatively new to project delivery (I am used to being delivered to) this seems to be at odds with my understanding.

I get waterfall, and iterative waterfall, and I understand scrum from a high level... I thought I understood agile, though am now seriously doubting that given the above statement.

In the scenario given above, how is it possible to finish analysing the problem, finish designing the solution in order to resolve said problem, finish coding the solution and finish testing the solution all at the same time? How can you test something ahead of it being completed?

 

[randomshenans]

You start with less weighty documentation/ plans, do user stories, start a sprint, or whatever, work through and iterate all in parallel.

 

[Gilly]

You start with less weighty documentation/ plans, do user stories, start a sprint, or whatever, work through and iterate all in parallel.

Doing it in parallel isn't really possible, unless I'm missing something major, if you don't know the baseline against which you need to test.

What's the value in testing something that's incomplete?

[edit]Note: by incomplete I don't mean without full low level designs, I just mean that whatever it is you are testing hasn't been finished in design or coding at this point...

 

[scorza]

Not sure that the concept of baselines is as important in Agile as it is in Waterfall or V-Model - the whole point is to do away with high engineering concepts which you trade off by developing your product really quickly. Agile isn't appropriate for all software development projects.

Edit: For sure, you can't test something that doesn't exist, but you can do your test analysis, define test cases, even write test harnesses if you've defined the contract of the interfaces.

 

[Tunney]

Agile means splitting work into small, manageable chunks that are completely finished before moving onto the next chunk. I've never seen those disciplines all finish at the same time but each part should be finished in the space of a short period (usually a few weeks).

 

[Aedus]

A baseline is given once you've established yourself into Agile more, it's basically saying "This piece of work was deemed to be x amount of effort, this story is more complex, so judging on this baseline, this story could be estimated at x".

If you have an epic which could be a big project, you would break it down into chunks (User stories), each of the user stories would then be estimated. Then based on the teams velocity from previous sprints you can get a gauge of how much work realistically a team can complete in 1 sprint, a project can take multiple sprints, remember at the end of a sprint it's only potentially releasable software. So big projects can span many sprints.

Each user story should be testable, so testing can take place in chunks, however the full User Acceptance testing of the solution won't be able to be complete until the whole project is done, but the benefit is if you had a user story for example for the UI, someone can test just the UI element, and instead of getting to the end of a project and coming back with 500 bugs some including the UI, the UI testing will be complete whilst a developer is still looking at that area of the project. Which is why they say "Testing and development happen in parallel", because they do, but on a story level, not on a project level.

 

[The Geezer]

In my experience the Agile delivery model does not fit for all types of deliveries, you cut you cloth accordingly. I would say the Agile Model is most effective for repeatable / known deliveries.

 

[Mr^B]

How can you test something ahead of it being completed?

...assuming this is to be used for some sort of software delivery..

TDD (Test Driven Development) implies that you write the test for the code, before you write the code. And then you carry on testing the code as you build it. There's no distinct "phases", and the design emerges out of the tight feedback loop as you are building the solution.

Agile encourages small items of work, the analysis, design, code and testing of the work can all be completed alongside each other, they are no longer separate disciplines.

I'd say that agile is actually of far more use where the problem/solution space is unknown - because it encourages you to explore the problem space - and that if you understand the problem, and therefore the solution, then a more traditional approach (waterfall) would be more appropriate.

 

[Burnsy2023]

It's also important to point out that Agile is a philosophy, a set of values, not an implementation. That's where something like XP or scrum comes in.

 

[Rids]

That's not my understanding of agile either, how can you finish testing a solution the same time as the solution is finalised? Makes no sense.
Also I'm not sure how you can have a fully developed solution to a problem while you're still analysing exactly what the problem is.

I agree that you'll have a great deal of overlap, you can start developing a solution long before you know the full scope of the problem, you can have your test scripts ready to go while development is occurring, but I don't think the concept of no overlap feasible.

 

[Diddums x]

I've spent the last hour or so wondering what the hell you're talking about. I just googled it and discovered it's about software development so I can feel less stupid now. Cheers Gilly

 

[scorza]

That's not my understanding of agile either, how can you finish testing a solution the same time as the solution is finalised? Makes no sense.
Also I'm not sure how you can have a fully developed solution to a problem while you're still analysing exactly what the problem is.

Part of the rationale behind Agile is to get your Analysts, Designers, Developers and Testers working together rather than operating in their own individual silos which typically happens with non-Agile methodologies. How many times have devs working on a waterfall project encountered inconsistent or incomplete design which can be traced back to poorly worded requirements? Lots of times in my experience and to be fair it's not always the BA's fault.

If you can get all designer, developer and tester input into the analyst then you should get better quality requirements than if the BAs worked on their own or so the theory goes. It also means that the designers, devs and testers should already have an understanding of the problem before the requirements are specified, so can start their work without a formal baseline.

 

[Schnippzle]

It's also important to point out that Agile is a philosophy, a set of values, not an implementation. That's where something like XP or scrum comes in.

Agreed.

 

[leaskovski]

I ran across this whilst looking up some implementation methods today. OK, this is one person's take on it only, but having come from a live services background and being relatively new to project delivery (I am used to being delivered to) this seems to be at odds with my understanding.

I get waterfall, and iterative waterfall, and I understand scrum from a high level... I thought I understood agile, though am now seriously doubting that given the above statement.

In the scenario given above, how is it possible to finish analysing the problem, finish designing the solution in order to resolve said problem, finish coding the solution and finish testing the solution all at the same time? How can you test something ahead of it being completed?

Basically it all comes down to breaking your epic up into good sized storys that don't contain shed loads of work, and then this makes it possible to do things in parallel and get your team to all be working on stuff that all fits nicely into a sprint.

 

[TommyV]

I work with a client who wanted us to move to an agile process with them just before christmas.

In summary;

- We now delivery far far less to them than we previously did, due to all of the red tape (our attitude before was just get it done and delivered quick time). One of the points of agile was supposedly to remove any red tape and have just more transparent process of getting stuff designed/developed/delivered, nope.
- We now have umpteen amount of pointless meetings, sprint pre-planning, sprint planning, sprint retrospectives, sprint review, sprint daily stand ups. So much time spent talking about what we're doing, other than actually doing it.
- Much more reliance on the customer to prepare their 'stories' before anyone actually starts working on them, this has been a huge blocker and slowing down the entire process.

It's pretty frustrating, going from agile in the rawest form of what agile is, to an agile delivery framework. That's just my experience, I'm sure others have had much better dealings.

 

[leaskovski]

lol, love how every manager in the world thinks agile is a win win. Waterfall.. too much up front guff, yeah, lets go agile as that cuts all that out. Thats all they see.

 

[Burnsy2023]

lol, love how every manager in the world thinks agile is a win win. Waterfall.. too much up front guff, yeah, lets go agile as that cuts all that out. Thats all they see.

Agile is very powerful when used correctly. It requires a shift in culture and working practices which is not easy to implement but when you have full feature teams that work well, you can produce much better software.

I've worked in Scrum teams in the last 3 years or so and tbh, I wouldn't want to use anything else.

 

[NickK]

Doing it in parallel isn't really possible, unless I'm missing something major, if you don't know the baseline against which you need to test.

What's the value in testing something that's incomplete?

[edit]Note: by incomplete I don't mean without full low level designs, I just mean that whatever it is you are testing hasn't been finished in design or coding at this point...

Traditional project deliver attempts to define a contract with a scope of work (requirements) and then guess the cost and time associated with it. The time to the project is that the scope is delivered (validated using acceptance testing) it's effectively attempting to model the complete system as a requirement then deliver the complete system.

The reality is that the scope changes over time. The business value (not the money) to the customer for parts of the scope and new scope also changes over time.
The result is a change request process that results, over time, not being able to adequately cope with the changes to the complete system AND the existing development. Oh - then theres the failure due to budget overruns...

The result is delivered and .. often failure to deliver quickly and early results in systems that don't do what the customer wants or fail completely to deliver what the customer wants NOW in terms of business value.


Agile on the other hand focuses on people. It trusts that people know what they're doing and how to deliver business value of the customer.
The iterative breakdown and delivery to need management - a backlog and prioritisation through business value. Iterative working with the customer means they effectively sign off a progressive delivery of business value.

Thus you have a customer, your customer knows roughly what they want and through interactive iterations. At the end of each iteration you're signing off acceptance.

Dates are still important but the customer is engaged through the entire sprint cycle with the engineers working directly with the customer.

The dangers are:
* information overload and overall solution, however there's nothing stopping you from having an overall definition picture at a high level (that's what the product/project backlog is). Your engineers must know how their work fits - if not then they're not caring in what they deliver and will be ineffective.
* not setting dates - agile doesn't mean you don't have dates, you do. You, the customer and the engineering staff all know them as they're in the backlog. Make it your team's responsibility for highlighting dates at risk at the standup (scrum).
* "doomsday clock" being used for R&D - the scrum idea of a clock is to show if you've done a "quick hack" to deliver quickly how much you need todo to complete it correctly. It doesn't mean the time required to redevelop something because of a new technology is available and the engineers want to use it - that's R&D and is a backlog task.
* X is the substitute for the customer. No. No. No. Only if you're developing product then the product manager is the customer for market-led/multi-customer features or use cases.
* Definition of done - that doesn't mean the engineer has checked in their godlike piece of development. It's when the customer is happy. The sprint acceptance means they're happy - if the thing isn't then either the customer changed their mind in the scope or the the development took longer than estimated originally - the over run/new work is additional that carried over to the next sprint. The customer can see quickly (and everyone else) if there's changes through the burn downs.

Long post.. lots if different things that are difficult to put but Agile really works in an organised way and if you have 100 developers then it still works. However the way in which the organisation is left to them. They still need to define, decompose the work and demonstrate the work is complete. Even if it's a scrum of scrums or tribes or however you wish to look at organising.

One really nice example is Valve. They have no organisational structure- the entire team is fluid and works by moving their desks physically.. so you development work may have a team made up of PR, Marketing, Legal and developers.. all working side by side. They don't compartmentalise the different functions and the result is that the team get a very good idea between the functions on how they need to communicate and work.

Traditional - paper - "you do this"
Agile - people - "I trust you to make the customer happy (work done)"

 

[scorza]

I work with a client who wanted us to move to an agile process with them just before christmas.

In summary;

- We now delivery far far less to them than we previously did, due to all of the red tape (our attitude before was just get it done and delivered quick time). One of the points of agile was supposedly to remove any red tape and have just more transparent process of getting stuff designed/developed/delivered, nope.
- We now have umpteen amount of pointless meetings, sprint pre-planning, sprint planning, sprint retrospectives, sprint review, sprint daily stand ups. So much time spent talking about what we're doing, other than actually doing it.
- Much more reliance on the customer to prepare their 'stories' before anyone actually starts working on them, this has been a huge blocker and slowing down the entire process.

It's pretty frustrating, going from agile in the rawest form of what agile is, to an agile delivery framework. That's just my experience, I'm sure others have had much better dealings.

Is your client the British government by any chance? They're pushing Agile methodologies big time.

I've only ever worked on Waterfall and V-Model projects - V-Model was far and away the best.

 

[NickK]

Agile is very powerful when used correctly. It requires a shift in culture and working practices which is not easy to implement but when you have full feature teams that work well, you can produce much better software.

I've worked in Scrum teams in the last 3 years or so and tbh, I wouldn't want to use anything else.

Agile is funny - I've had job interviews with a defence contractor for marine work.. the panel of project managers looked down the nose at me, said they tried agile but it didn't work (equates to someone read a book and nobody understood what they were attempting to suggest).

Typically business cases will be on a yearly cycle in older organisations.. they have a yearly masterplan and the concept of scrum seems dysfunctional to them. Now business changes - it changes faster than the annual plans would indicate.. no wait they have a monthly report that simply KPI's the original guess. Well surprise surprise they wait too long to fix changes.

When the organisation works in an agile form, even the finance and HR are operating in sprints. The key here is to ensure that the communication/teams work together - otherwise you've got your finance operating at loggerheads to others etc and there's no progress.

Each area of the organisation has their backlog? Not really.. because the organisation is delivering 'business value' thus marketing/pr/hr/product management are all part of the team delivering against the same backlog.

It makes it very fast for senior execs to see/change their priorities without the "seagull" treatment or the underlings playing the "mushroom game" and hoping that everything will be ok.
With correct visibility the exec can see their organisation's progress and the problems that need their attention. It also makes people step up and take responsibility.