Agile IT Delivery

Forums › IT Pro and developers › Agile IT Delivery

1 | 2

nzkc

1573 posts

Uber Geek

#2245787 26-May-2019 10:07

Caution: I seem to have got into a bit of a diatribe on this subject!

I have found that companies and management prefer waterfall cause its easier "to get". Project managers like it because they can focus around the dates. Where waterfall projects struggle, in IT at least and probably elsewhere, is with changes to deliverables. All to often what people ask for and what people need are not the same thing. I have issues with waterfall in all kinds of IT projects. If you've got a clear single deliverable like "deliver SFB/Teams to the company" then its an acceptable approach. The tasks involved are reasonably clear from the outset, the people you need likewise. However; if you have a project that is less clear or worse being driven by someone who wont use the resulting product then waterfall will fail. You may deliver the desired outcome, eventually, however you've likely run over time and over budget because the goal posts kept moving. As an example; how often do you hear of government IT projects running over time and over budget? And these are almost always a big waterfall project.

This is where Agile tries to come and solve. Agile attempts to get rapid regular feedback from your stakeholders and customers to help guide you both to the eventual outcome. You actually dont have to have a clear final state to start the project. An example might be "deliver our contact centre a knowledge base tool that they can update and will help them find answers quickly". There are lots of products out there that'll do that already, but if for some reason you decide to create your own or need to evaluate the many as part of the project you can start right away. You'd go away try a few things and come back to your stakeholders and customers with a first rough draft of something. It might just be "here are our ideas and how we think this might work" rather than prototype. The goals of these iterations are to make that unclear desired result more clear. You're also talking to your customers more directly. Something that almost never happens with waterfall (unless you're the BA maybe).

A lot of companies struggle with agile for all kinds of reasons from what I've seen and I am far from an expert....but I've worked long enough to see things! Most project managers dont seem to get it at all - especially if they've worked a long time with waterfall. They really struggle with the lack of clear dates and outcomes. CxO and higher level managers also want clear dates and clear costs. Thats not always obvious with agile. If you're a "coalface" IT worker how often are you asked "when will have this done" or "how much is that going to cost" (if you're a little higher up the food chain). Those questions arent easy to answer and as a result the answers are often wrong. Even with everyones best intentions.

What people often do not realise is that agile itself does not prescribe a way to manage the project per se. Scrums arent a requirement of agile - though they are regularly adopted. Different teams in the same organisation might run their agile projects differently. Different companies often will too. Indeed if youre allowed to change the way you work within your team you will likely be more successful. If something is prescribed onto you (because pointy haired manager said you'd do it that way) you'll probably find everything jarring and difficult to work with. And you'll question things (I like people who question the status quo!) as you wont see the point of it.

So which methodology is right for you or your company? Dunno. I've got a preference and its probably clear from the above which that is! As others have said the methodology isnt necessarily the important part. People are. Always. If you've got good people across the board you'll have successful outcomes. Learning how you work with your colleagues is probably even more important than all of that. Your personality types are different. Your motivations are different. What engages each of you is different. If you can learn these things about each other you'll work more cohesively as a team (your immediate team and wider department and ultimately company). Finding a company that values this above all else is rare. And having worked abroad a bit it seems NZ is behind a bit here - but starting to get there.

</soapbox>

Edit: And as someone earlier said dont bother with Skype for Business (its "deprecated"). Go with Teams (which whilst it has its own problems is way better than SFB).

TwoSeven

1627 posts

Uber Geek

Subscriber

#2245834 26-May-2019 12:21

nzkc:
Caution: I seem to have got into a bit of a diatribe on this subject!

<soapbox>

I have found that companies and management prefer waterfall cause its easier "to get". Project managers like it because they can focus around the dates.

I am willing to bet that whatever you thought those companies were doing, it wasn’t waterfall.

When I see it mentioned by proponents of Agile it seems to always refer to some kind of view of Waterfall that never existed. In the media, they would call it fake-news. In IT I would call this fake science. It is usually then followed by some discussion around how some projects failed and how the new technique will work better - it is a classic sales technique.

The model itself is drawn using what is known as a Bennington Cascade diagram. When Waterfall was introduced, the added concept was that of feedback loops.

Each stage has two parts - the bit where one does some work and the bit where one checks the work. One shouldn’t progress to the next stage unless one is reasonably confident one is in the ballpark of being sure what one is doing is right. At any time (and usually quite often) feedback loops are used where new or missing information once discovered is sent back to to the previous stage and an iteration is performed.

Alternatively, a number of iterations may be performed deliberately at a stage in order to kick off multiple instances of the next stage in parallel. For example, multiple requirement iterations, lead to several in-parallel feature teams. This scale-out technique can be used often in large projects where having staff with a specific skillset unused can result in large costs (for example, having 200 developers sitting idle is a cost of around $90k/hour including opportunity cost).

At the end of the last stage, it may be that another iteration from the beginning is required - this technique is typically used in both phased and iterative projects.

One of the most popular business engagement models is as Mini-Waterfall. The reason behind this is because it aligns with the most common way many businesses operate. PRINCE (Work Packages), PMI, WSSDM, ISO9001, ITIL, Six Sigma, Lean, and even Agile (Sprints) all use this basic technique in some shape or form. In effect it comes down to simply, knowing what needs to be done, putting it in scope, managing that scope, and knowing when to stop.

I like to use a factory assembly line and iso 9001 (an earlier version of the standard) as a demonstration.

1) At the beginning the customer goes to a web page and chooses all of the features and colours that they want (note: it is likely that the customer has already seen a prototype).
2) A roll of steel is delivered into the factory as raw material and begins its way down the assembly line.
3) At each stage of the assembly line, two things happen a) some assembly is performed and b) the work and all previous work is checked
4) If a check fails, the work goes back to the point where it it became non-conforming (the industry term for a bug - non conforming with the requirement or specification) and it is brought back into conformance (fixed).
4a) the defective step is modified to remove the cause of the defect (Kaizen)
5) at each stage, all of the materials (resources - such as staff, parts, tools) required by that stage are provided - only at the point in time when they are actually needed (Kanban).
6) at any time before a stage is committed to, the customer can change their mind (within reason) for example, change the colour of the car.
7) when the car is completed it goes through the final round of checks (testing) and is shipped to the customer.
8) the Customer accepts or rejects the car.

Step 3b is an example of a feedback loop.
Step 7 is an example of IT Service Delivery (if it were an IT project)
Step 3 is an example of an Agile Sprint

In a nutshell, this is an example of waterfall (or mini-waterfall).

As an aside, when people are talking about agile techniques, it is my observation that it is common for them to do so in the form of small businesses- what we call person+dog operations. In that context, many agile techniques sound logical and often work quite well. But scale them up to large enterprise where there may be several thousand developers and tens of thousands of people involved in the project and they often fall flat, not because they are poor techniques, but because the context for which they were designed is totally different.

Software Engineer
(the practice of real science, engineering and management)
A.I. (Automation rebranded)
Gender Neutral
(a person who believes in equality and who does not believe in/use stereotypes. Examples such as gender, binary, nonbinary, male/female etc.)

...they/their/them...

nzkc

1573 posts

Uber Geek

#2245866 26-May-2019 15:46

TwoSeven:

I am willing to bet that whatever you thought those companies were doing, it wasn’t waterfall.

Look; I have simplified things a bit. The projects were waterfall. They may have been run poorly and maybe didnt conform to your pure view of waterfall. A lot of them were definitely poorly run - hope youre not a project manager cause in my experience I've only met a handful that actually managed a project and added value. The rest were just "when will this done?", "how complete is this?" just so they could report it and presumably get their bonuses :-P . And Ive heard people compare agile to mini waterfall before. I'm honestly somewhat "meh" about approaches. One thing I picked up on was you seemed to agree that regular feedback is important. I think regular feedback is key to the success of an project. In my experience (which is honestly quite a lot) it just doesn't tend to happen in waterfall projects. I've seen the frustration this drives for all involved.

I also had to chuckle at your comment about large companies with 10s of thousands of employees working on a project as we really just don't have that here in NZ! And again; when you do they tend to be government projects and how often do you hear about those going massively over budget. Waterfall can work. Massive infrastructure projects (buildings, motorways etc) rely on it. For some reason we in IT just cant get it to work as well as those industries (and yeah I know they can run over too). I have some theories on this and theyre nothing to do with the methodology.

One of the things I tried to convey, and perhaps did so poorly and failed, was that the methodology is secondary to everything else. Everthing also has many skews and you need to find the one that works for you the team you're in eventually. In the first instance focus on the people and the relationships. That'll get you faster, better and more results than anything else. If you push the process over anything else that seems to be a sure fire way to disengage your staff really quickly!

1 | 2