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?

 

[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...

 

[Gilly]

Lean is fantastic, and my limited involvement with Kanban and SixSigma is positive too. I don't rate iterative deployments purely because of my own live services background. As the receiving manager I was accepting into live as part of a transition organisation. Iterative just means the responsibility is on the receiving managers to poke holes in each attempt, get the feedback to the devs and have them run around the loop again. Great for them to have the bitesize chunks and quick feedback, but rubbish for us that are burning hours trying to get what it is we need (and even then we weren't the client, and we didn't have a direct relationship with the client either).

An iterative waterfall approach with short timelines and formal feedback loops does work, but it doesn't have the speedy start that agile has purely on the basis that what's required needs to be baselined.

In an agile environment you can't have the hands-off approach that too many orgs have, and especially so when the work is outsourced. I'm working with a major retail business in the UK at the moment and they have outsourced almost the entire of the IT business to an external consultants, and then the service design to another external provider. Having been on the account a week it doesn't feel like the closeness of working relationship is there to engender the required trust to work effectively in scrums in an agile delivery.

 

[Gilly]

That makes absolute sense, and is the only way I can get it straight in my head. But in reality having someone who is skilled at both developing and testing is quite tricky and I don't think that I've ever seen a job advert for a joint dev/tester role in an agile environment. I think most places will still have testers and developers which leads me back to my original confusion.

Not only that, I'm not sure I'd be comfortable managing someone that was developing solutions and then marking his own homework.

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

I have literally no idea whats happening here.


You IT people use strange words

 

[Gilly]

That really seems there's something wrong- possibly with the attitude or the expectation. Both parties aren't the customer (including the ops manager sitting in their ITIL bubble) unless it's explicitly a delivery for the operations functionality for the operational management that the customer doesn't see.

Sounds like an attitude issue to me.. get a senior exec to reiterate the expectation - that means both should be working to the goal. Often if there's a cycle of negative hole pointing then the "customer" isn't in the loop (customer here being the ops manager that's not defining what they want). If they're changing their mind then that's different.. that ops manager should have a good definition in the user story, assisted by the engineer if needed (not written by the engineer).

If the ops manager needs it fixed then he needs to lift a finger.. but at the same time the engineer needs a kick to actually take responsibility for building the communications/meetings or general chat throughout the sprint.

Agile doesn't sit well with people that stand in their ivory towers and look down though their noses muttering "just make it work".. then whine that it's not right. Down that path, there be Problematic manager(s)..

In the scenario given I was the ops manager in my old role. The environment was not even slightly agile, and wasn't intending to be in any way at any level. We had to have fully baselined design documents before development started, then you had test environments completely split away from the production implementation engineers. The test environments were only testing that the product didn't break anything, not the full functionality of the solution in comparison to what the client actually desired...

It was very frustrating being the person that had to have an eye on requirements and the other eye on deliveries.

 

[Gilly]

The quote in your opening post is basically crap. I don't know who wrote it, but they clearly don't understand agile.

I can't remember his name but it was an article on LinkedIn from someone that claimed to be a specialist agile consultant

 

[Gilly]

Perhaps it's the wording used. He starts off with 'ideally...'. Perhaps he meant more to say 'in an ideal world...'

He does go on to say what should happen, not what would happen in his dream scenario.

 

[Gilly]

None of it revolves around the PM. Even good ones are nothing more than facilitators