Agile vs Scrum vs Waterfall vs Iterative...

[NickK]

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.

It's implied by the "agile" reference, however often the buzz word gets used without actually doing it.

Think of it as each person takes the responsibility to solve that problem (business value). For larger problems, teams can be used.

The sprint planning is really a people discussing their ideas in how they want to deliver it with colleagues with feed back.

Story points should be a measure of complexity not time. Then over a period you start to get a feeling for the complexity, and if a piece of complexity can be delivered in a sprint (completely).

Not all people can work on a single task, but it means that the team say how much complexity can be dealt with for each user story. In my old place, if a task was over 13SP then we knew it needed further break down as the maximum of a developer was about 13SP/sprint. Considering some of our epics were quoted as XL (t-shirt size) being over 120SP we knew quickly if we had issues.

Every team takes a while to zero in and reduce the error cone of the complexity estimation. Every traditional has heard the phase "sorry it's going to over run because it was more complicated than I thought" - a guess at the very start of the project to create time/cost estimates from the requirements scope.
Now agile/scrum means you only focus on the important things then as you break that down you know over time for the entire project/product that the estimations will get better because there's an estimate-experience-feedback loop for every sprint and that includes the estimation.

Iterative just means the responsibility is on the receiving managers to poke holes in each attempt

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

 

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

 

[dazzerd]

I always found these various philosophies a make work scheme for generations of middle class middle managers who lack the technical competence to actually provide a solution to the business themselves or as a team.

In other words ohh, that problem is difficult I haven't got a clue how to solve it so lets at least talk about it endlessly for months and months in the hope that somebody eventually in the business will step up and provide a solution and then we can take credit for it.

Or am i being too cynical?

 

[Tefal]

haha it is like another language .

i thought this was about writing a book at first

 

[JBod]

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?

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

I am not personally a fan of pure scrum either, it tends to not work. Hybrid Scrum+Kanban approaches are better, ironically the problem I have with scrum is how rigid it is for something part of the Agile methodologies.

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.

You need to look up Test Driven Development with paired programming. I am a firm believer in it, it is the best thing to do for code quality and regular production deployments. Fail fast, fail early and fail often.

The best development environment I have ever seen is when I was at 7digital. I saw 5+ product teams releasing live code multiple times a day, all the teams code depended on each other and a core API. The teams practiced Test Driven Development and every deployment went through the automated test framework (TeamCity), unit tests, integration tests etc... creating the truest Continuous Integration I have ever witnessed.

If a bug made it to production the first thing they did after roll back (which was really a roll forward) was to create a new test to catch it before fixing it.

Check out a short prezi here https://prezi.com/b5sncbab4tkh/day-in-the-life-of-a-7digital-developer-abridged/

And this book: http://www.infoq.com/resource/minib...ok/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf

 

[NotAGolf]

You need to look up Test Driven Development with paired programming. I am a firm believer in it, it is the best thing to do for code quality and regular production deployments. Fail fast, fail early and fail often.

The best development environment I have ever seen is when I was at 7digital. I saw 5+ product teams releasing live code multiple times a day, all the teams code depended on each other and a core API. The teams practiced Test Driven Development and every deployment went through the automated test framework (TeamCity), unit tests, integration tests etc... creating the truest Continuous Integration I have ever witnessed.

So was there any manual testing at any stage, or was it all automated? 100% automated unit tests sure, maybe even 100% automated regressions tests, but I imagine 100% automated functional tests would be tricky to implement, if not impossible (depending on the product of course).

 

[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

 

[semi-pro waster]

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

Not specifically about software design but I would typically treat self-professed experts with a (large) degree of scepticism until/unless there's confirmation they know what they are talking about, either from my own experience or that of others. It's probably a bit like being an estate agent - anyone can set themselves up as a consultant without any verification of ability but the good ones are a lot rarer.

There's also potentially the problem that "ideally" things do happen in the way described i.e. in a perfect theoretical world but practically and pragmatically you've got to take the best elements from various options to get what works for you and your company.

 

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

 

[OspreyO]

For me from the outside looking in, (my development experience is all obsolete). I'm looking at re-skilling and all these new ideas seems daunting.

Agile seems about getting lots bite sized chunks done right, first time, concurrently. Managing realistic expectations of all parties. To avoid the classic problems in a traditional waterfall approach, which often end up being unsatisfactory experience, for customer and developer. Which often fall short in expectations, and quality.

 

[D.P.]

So was there any manual testing at any stage, or was it all automated? 100% automated unit tests sure, maybe even 100% automated regressions tests, but I imagine 100% automated functional tests would be tricky to implement, if not impossible (depending on the product of course).

Indeed, for is functional testing takes a few weeks of driving around to get enough feedback. Then there are just simple things like pushing a change to so e parts of the code will result in a 4-5hour compile time before the unit tests run. We aim to make quarterly releases and don't stress if things get delayed.

 

[NickK]

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

I hear you! I'm normally responsible for solution/bespoke project and product delivery.

 

[NickK]

I always found these various philosophies a make work scheme for generations of middle class middle managers who lack the technical competence to actually provide a solution to the business themselves or as a team.

In other words ohh, that problem is difficult I haven't got a clue how to solve it so lets at least talk about it endlessly for months and months in the hope that somebody eventually in the business will step up and provide a solution and then we can take credit for it.

Or am i being too cynical?

Nope.

However if a manager doesn't want the indignity of people leaving an citing their (mis)conduct as the reason..

No different to TOGAF or <insert methodology that by design puts the practitioner in the centre and as the most important thing in the world here>. All methodologies in their purest form are constructed from a perspective. It's important to understand that perspective and the drivers - true. However development methodologies seems to think the world revolves around developers, project management methodologies - revolves around the PrjMgr, same with product, ops etc.. There is no one true answer/solution but most of these methodologies sell themselves as the silver bullet.

 

[NickK]

Kanban has the capability to remove the two week "sprint" however the problem caused by bad "work package" style delivery process then becomes that people attempt to force things for immediate delivery and additionally it leads to pressure to "get the thing done asap" without the need to focus on discussing it with peers.

Having a back log means someone as the fundamental authority of setting the priority. All the developers should know the way the priority is done and why it's done. However that's no different to traditional waterfall team management where external managers attempting to interact with the team members to change their work should be talking to the team manager.

 

[Gilly]

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

 

[Itchytrigg]

We've been working with Agile for the last 6 months now in my team, thankfully 6 months prior the other programming teams made the push and rolled it with support from the whole business, if we didn't have that buy in all ready I think it would have been a lot harder.

The best thing I find is we are constantly adapting our implementation to suit our needs. We're in a scrumban setup due to our team being responsible for both support and new developments.

Hardest internal elements in implementation were some of our more junior team didn't want to get involved in the backlog reviews and would often say "well I guess it's got to be done". We're getting there and I challenge my whole team to be realistic, I don't care what the cost was, the required launch date, etc, etc. Can you do it, do you have what you need to do it?

To the couple of folks mentioning pointless meetings, they shouldn't be that. I've seen with other teams in our company what poor management/control/buy in does, there is one team that has 1hr daily stand ups......I joined one once as they "needed" me. I then refused to attend again till they got them back on point and in 15 minutes or less.

Each of the meetings has a point and people that are needed, if they go off point you need to change something and they shouldn't involve folks who've better things to be doing. Maybe the framework picked is not right for the team. The agile principles should be telling people to evaluate and adapt, especially the processes themselves.

 

[DarrenM343]

JFDI is the best methodology .
One problem I find with Agile, Scrum and the like in my opinion is that you often find the "talkers" involved who are great and talking the talk but not walking the walk (delivering) - they like the BS of it all.

 

[Stretch]

Agile is becoming more of a distraction than a benefit lately. People seem more preoccupied with what Agile is/isn't than what it's suppose to offer.

It's become more heavy weight, there are consultants, certificates, mangers etc etc. I've spent more time than I care to remember "debating" Agile implementation and it's added nothing to my life except waste time.

The Agile manifest is over 25 years old, and the Agile methodology was largely a response to a problem which doesn't exist any more.

My personal issue with it is it's just to vague, and it leaves too many people feeling they have an opinion that matter