(Project Management) Agile in non-software development environments

[Deleted member 19844]

So my work is going through an Agile transformation (we've been a formal waterfall shop for years) and I'm wondering if anyone else has been in a place that's adopted Agile but NOT in a software development environment. Has it gone well? Does it not make sense?

I'd rather not describe specifically what we do, but I'm interested in the challenges and shortfalls that anyone has found when trying to adopt Agile outside of software development.

 

[8bit]

Engage with people who know about Agile practices, don't tell the old guard they need to be Agile and allow them to deliver the same old rubbish with a new hat on.

 

[Matheus]

It can be used in a lot of areas. And even when we're talking about software development, you should ask if the whole company is on board with this, not just IT. How does other areas in the company work? How does their work affect people in development, and vice versa? And so on. I can see areas in which it wouldn't work so well, and even that is arguabe, like civil construction. You won't change requirements of a bridge mid construction, for example. The biggest problem i faced in where i've been has been the mindset of higher management. Everyone likes to say that "hey, ye, i'm cool with everyone having a more active voice", but in reality, most fear "losing" some power or influence during a transformation

 

[Dralos]

yes i implemented a kanban board and scrum within a project (aerospace company/non software) but did not use any buzzwords, like scrum, sprints, user stories, daily stand ups and people actually just accepted it and didnt complain. after a few sprints they asked if we can continue that way and were pretty happy with what we achieved.

start with motivated employess. they tend to be more open minded and if they succeed with a new ways of working theyll spread their experience.

 

[lt519]

Yes, we run an agile process in an embedded systems environment where we are doing a lot of hardware design alongside software design. Ultimately we found that the agile process that they teach in classes isn't as applicable and you really have to mold it into your own process. A lot of places do things like this and call it ScrumBan where you are combining the scrum/sprint mentality that works well for Software with the kanban mentality that works well for hardware.

The lessons to be learnt from employing an agile process and lean engineering wholly apply though. Test prototypes early and often and make sure your workflow is optimized.

Trying to take it how they teach it in the books and rigidly applying it to your company is almost an ironic failure of the heart of agile/lean engineering.

 

[TechnicPuppet]

We're doing it just now and everyone just wants big Kanban touch screens and things but have no clue what they are doing.

 

[Deleted member 19844]

don't tell the old guard they need to be Agile and allow them to deliver the same old rubbish with a new hat on.

Click to shrink...

This is what I think is happening with some of the teams...

after a few sprints they asked if we can continue that way and were pretty happy with what we achieved.

Click to shrink...

Did you ever implement user stories? Was it challenging for folks to apply that?

Trying to take it how they teach it in the books and rigidly applying it to your company is almost an ironic failure of the heart of agile/lean engineering.

Click to shrink...

I think this is what's happening with stories -- everyone is trying to cram their work into the story format when often it just doesn't seem to fit...

 

[FriendlyNPC]

I saw this transformation in a software company full of very specialized and old developers and boy was it painful. The old people were not having any of it. Took like 2 years to get somewhat accepted.

 

[FliX]

https://blog.toggl.com/mars-software-development/

 

[AnotherDayAnotherDollar]

So my work is going through an Agile transformation (we've been a formal waterfall shop for years) and I'm wondering if anyone else has been in a place that's adopted Agile but NOT in a software development environment. Has it gone well? Does it not make sense?

I'd rather not describe specifically what we do, but I'm interested in the challenges and shortfalls that anyone has found when trying to adopt Agile outside of software development.

Click to shrink...

DevOps >>>>>>>> Traditional Agile >>>>>>>>>>>>>>> Dog shit >>>>>>>>>>>>>>>>> Waterfall.

 

[lt519]

This is what I think is happening with some of the teams...
Did you ever implement user stories? Was it challenging for folks to apply that?
I think this is what's happening with stories -- everyone is trying to cram their work into the story format when often it just doesn't seem to fit...

Click to shrink...

I've always considered the user story portion of the agile engineering process to just be writing good systems requirements. I don't buy into the fact that a user story is any different than deriving a requirement from a statement of work and having a traceability matrix. If that's how people want to write up their issues/tasking I don't really care. The core of it is writing up issues/tasking/requirements that are concise, able to be completed in a sprint, and testable. Any program that does that well is going to be successful. Then if you want to gauge velocity and all that go right ahead, but in hardware development velocity doesn't mean a whole lot to me. Folks aren't just banging out bugs/features where you can predict their output.

 

[Pirateluigi]

You can have successful project in any methodology. The important thing is avoiding prescriptivism. Projects are unique so it would be a mistake to force every project to be run the exact same way.

I've always considered the user story portion of the agile engineering process to just be writing good systems requirements. I don't buy into the fact that a user story is any different than deriving a requirement from a statement of work and having a traceability matrix. If that's how people want to write up their issues/tasking I don't really care. The core of it is writing up issues/tasking/requirements that are concise, able to be completed in a sprint, and testable. Any program that does that well is going to be successful. Then if you want to gauge velocity and all that go right ahead, but in hardware development velocity doesn't mean a whole lot to me. Folks aren't just banging out bugs/features where you can predict their output.

Click to shrink...

Well stated.

 

[Hilbert]

I have heard of people raising their kids using agile/scrum methodology.

 

[Deleted member 19844]

I've always considered the user story portion of the agile engineering process to just be writing good systems requirements. I don't buy into the fact that a user story is any different than deriving a requirement from a statement of work and having a traceability matrix. If that's how people want to write up their issues/tasking I don't really care. The core of it is writing up issues/tasking/requirements that are concise, able to be completed in a sprint, and testable. Any program that does that well is going to be successful. Then if you want to gauge velocity and all that go right ahead, but in hardware development velocity doesn't mean a whole lot to me. Folks aren't just banging out bugs/features where you can predict their output.

Click to shrink...

Thanks, this is well-put. I'm seeing people forcing task-level things into the story format and it just doesn't make sense to me...

 

[finalflame]

Well, --

I've always considered the user story portion of the agile engineering process to just be writing good systems requirements. I don't buy into the fact that a user story is any different than deriving a requirement from a statement of work and having a traceability matrix. If that's how people want to write up their issues/tasking I don't really care. The core of it is writing up issues/tasking/requirements that are concise, able to be completed in a sprint, and testable. Any program that does that well is going to be successful. Then if you want to gauge velocity and all that go right ahead, but in hardware development velocity doesn't mean a whole lot to me. Folks aren't just banging out bugs/features where you can predict their output.

Click to shrink...

-- actually this about covers what I came in here to say. Listen to this post, OP.

 

[SRG01]

I've always considered the user story portion of the agile engineering process to just be writing good systems requirements. I don't buy into the fact that a user story is any different than deriving a requirement from a statement of work and having a traceability matrix. If that's how people want to write up their issues/tasking I don't really care. The core of it is writing up issues/tasking/requirements that are concise, able to be completed in a sprint, and testable. Any program that does that well is going to be successful. Then if you want to gauge velocity and all that go right ahead, but in hardware development velocity doesn't mean a whole lot to me. Folks aren't just banging out bugs/features where you can predict their output.

Click to shrink...

I agree with the bolded a lot, especially because I've seen teams work on tasks/outcomes that aren't clearly defined from day one and end up throwing off all the project timelines.

 

[oreomunsta]

Oooh oooh, my company started this a little while ago!

My key observation: NOT EVERY PROJECT IS FIT FOR AGILE METHODOLOGY

Honestly, I see so many teams claim to be going Agile, and due to the nature of the project, it goes to shit. Agile needs to be considered a tool as much as waterfall, lean, or any other methodology. Making it the MO for every project is a recipe for a clusterfuck of inefficiency

 

[Deleted member 18179]

I agree with the bolded a lot, especially because I've seen teams work on tasks/outcomes that aren't clearly defined from day one and end up throwing off all the project timelines.

Click to shrink...

It also forces all departments to collaborate on a story that's descriptive and human readable. The crafting of the story invites questions and improves clarity so you don't end up with stuff like "As a Developer I can subroute system x to the mainframe junction rfg"

 

[hombremalo]

Agile, I said I knew it when getting my current job, still no clue.

 

[Hollywood Duo]

Agile works on anything. Its a mindset not some codified system. You need to constantly asses what you are doing and look for ways to improve it.

I have heard of people raising their kids using agile/scrum methodology.

Click to shrink...

Everyone raises their kid agile. The core component of it is assessing what works and doesn't work constantly. The most common refrain you'll hear a parent say is "everyone told me that X was so important and I believed them and I wish I hadn't wasted my time/money on that"

https://blog.toggl.com/mars-software-development/

Click to shrink...

No bias here at all lol

 

[philipnorth]

Oooh oooh, my company started this a little while ago!

My key observation: NOT EVERY PROJECT IS FIT FOR AGILE METHODOLOGY

Honestly, I see so many teams claim to be going Agile, and due to the nature of the project, it goes to shit. Agile needs to be considered a tool as much as waterfall, lean, or any other methodology. Making it the MO for every project is a recipe for a clusterfuck of inefficiency

Click to shrink...

I agree. We're in the middle of this as well. My team (legislation analists within government) is struggling as well. I come from IT originally and keep telling ppl as well: agile where possible.

I have convinced them to start using kanban though, just to visualize what everyone is doing, what needs to be Done and what we did and they definitely see the advantages there.

Oh but yeah, dont use the buzzwords, just talk about multi disciplinairy teams for in instance. That makes a lot more sense to 'older' ppl (non it ppl)

And make sure that being/going agile doesnt become the goal!!!

 

[SRG01]

No bias here at all lol

Click to shrink...

I think it's to illustrate that all project management approaches have their own (hilarious) pitfalls.

 

[exodus]

Having been on many teams using different methodologies, and even completely unstructued approaches, I do have some thoughts.

The main thing that causes any product to fail is a lack of communication. Agile addresses this, but it requires buy-in from everyone involved. I've been on a team with buy in from the client, and it was great. It took 1-2 years to really get in the groove, and there were learning pains, but we made it work in the end. We had to use the methodology as a standard baseline and modify it to fit our needs. Don't go expecting it to work great out of the box.

I've been on teams that try to implement Agile while being at a complete disconnect from clients and it's just a massive waste of time and brainpower.

Now I'm in a fully unstructured mishmash of whatever, kind of leaning towards the DevOpsy side of things, but we've got a long way to go.

 

[Hollywood Duo]

I think it's to illustrate that all project management approaches have their own (hilarious) pitfalls.

Click to shrink...

That is true except it portrays Waterfall as perfect so its a comic to make fun of everything except waterfall.

 

[Astronut325]

Been doing agile for about 6-7 years. I'm not sure I'm convinced it's better than waterfall. I agree that early prototypes and early testing/validation is extremely important, but that can be planned via waterfall too. I'm not seeing the benefits of it.

 

[exodus]

I agree. We're in the middle of this as well. My team (legislation analists within government) is struggling as well. I come from IT originally and keep telling ppl as well: agile where possible.

I have convinced them to start using kanban though, just to visualize what everyone is doing, what needs to be Done and what we did and they definitely see the advantages there.

Oh but yeah, dont use the buzzwords, just talk about multi disciplinairy teams for in instance. That makes a lot more sense to 'older' ppl (non it ppl)

And make sure that being/going agile doesnt become the goal!!!

Click to shrink...

Yeah I was doing it for government as well when I started my carreer. The biggest challenge is that you'll never get a full buy-in from the client since your budgets need to be pre-approved, and that's simply impossible in government. So you just need to take the bits and piece that work for you. Some vertical slices can also never be made small enough to both fit in an iteration and provide functionality visible to the client, especially when completion depends on an external source. I have no idea why Agile seems to be so strict on this. We had to live with a handful of 2+ iteration stories and live with it.

But still, planning, actual usable requirements, communication within the team, visibility, continuous feedback from the client and a reduction in pointless documentation resulted in huge gains for us. I moved back to a waterfall team after that project and it felt like molasses by comparison. I was aimless and had no idea what the client thought of any of my work.

 

[APOEERA]

I went from an IT shop that needed something (Agile, Waterfall, Lean, Kanban) and barely anything gets done on time or at all or didn't want to implement any changes to an Agile shop that's non software development. I like it so far and everyone involved communicates what they are running into and what they need help with. Could they not be on Agile and still accomplish the same goals? Yes but it's more fitting into the culture to keep Agile and also DevOps.

 

[Professor Lich]

I'm in a creative studio/position and we are just now transitioning from waterfall into agile (I think). It could be the upper management just wants better time estimates for projects which we never really had, but now projects have to fit into sprints in a studio wide calendar. Could end up being fine, but I think it'll be bumpy at the start since we're in the middle of multiple projects. Wait and see I guess.

 

[oreomunsta]

Here's a questionnaire I made that the internet can now quote forever when it comes to the big dev methodologies (agile, waterfall, kanban, scrum, lean):

Q1. How big is that deliverable your project intends to deliver?
Answer-A. "I dunno. Just needs to be a proof of concept. Nothing fancy" (go to Result 1)
Answer-B. "We need to deliver Moby Dick, essentially" (go to Q2)

Q2. How tight of a timeline are we talking about here?
Answer-A. "That whip's going to be cracked, and it's going to be cracked HARD" (go to Q3)
Answer-B. "We've got time to work on this, no biggie" (go to Q4)

Q3. Can you get away with delivering something that's initially shitty, with the intention that it's going to keep getting better over the course of the project?
Answer-A. "My ass would be grass if we delivered something like that" (go to Result 2)
Answer-B. "Rome wasn't built in a day, and neither will this deliverable :) " (go to Result 3)

Q4. How much expertise you got on that team there?
Answer-A. "We're new at this. We can figure what needs doing, but lol are we in for a ride" (go to Result 4)
Answer-B. "I have experts who, if I approach what they're doing, will hiss at me and tell me to not touch their shit" (go to Result 5)

Result 1: Congrats! Use lean, because you can make a Minimum Viable Product, and that's good 'nuff
Result 2: Congrats! You're using old sturdy waterfall. Make sure those checkpoints get checked along the way.
Result 3: Congrats! You're using Agile, where the Minimum Viable Product will be your best frenemy
Result 4: Congrats! You're using a Kanban, where everyone wants to cherry-pick the easy steps first to make it look like they're contributing
Result 5: Congrats! You're using scrum. Just make sure your team is delivering. Remember, a task will usually take as long as the amount of time you allocate to it :D

 

[Prophet Steve]

I think it can work but I don't really have experience with it. Kanban obviously works since it did not start out in software development anyway and works great for manufacturing.

But I think the principles of Agile can apply for a lot of things.

Been doing agile for about 6-7 years. I'm not sure I'm convinced it's better than waterfall. I agree that early prototypes and early testing/validation is extremely important, but that can be planned via waterfall too. I'm not seeing the benefits of it.

Click to shrink...

It depends a bit on what you consider waterfall because that isn't really defined all that well, but software development is very unpredicatable and when market conditions constantly change and you want to rely heavily on usage data to determine what to do you can't really plan everything in advanced. You can plan when to do testing, but without knowing the results you don't know how to plan what comes afterwards.

You can look at the principles and values of Agile and consider whethere you agree with them and how well they fit in a waterfall model.

I think it's to illustrate that all project management approaches have their own (hilarious) pitfalls.

Click to shrink...

Yeah no not really, it's just making fun out of every different kind of Agile while showing Waterfall as working out and making sense.

Yeah I was doing it for government as well when I started my carreer. The biggest challenge is that you'll never get a full buy-in from the client since your budgets need to be pre-approved, and that's simply impossible in government. So you just need to take the bits and piece that work for you. Some vertical slices can also never be made small enough to both fit in an iteration and provide functionality visible to the client, especially when completion depends on an external source. I have no idea why Agile seems to be so strict on this. We had to live with a handful of 2+ iteration stories and live with it.

But still, planning, actual usable requirements, communication within the team, visibility, continuous feedback from the client and a reduction in pointless documentation resulted in huge gains for us. I moved back to a waterfall team after that project and it felt like molasses by comparison. I was aimless and had no idea what the client thought of any of my work.

Click to shrink...

Agile isn't strict on that as all, as Agile doesn't really have hard-defined rules. Scrum does, but even that does not disallow you from making multiple iteration stories. Spikes and Epics are kind of examples of this, but the important thing is that you still have a deliverable product even though not all your functionality is included. It is also good to be aware that as along as something is not included you should consider it as having no value.

I do struggle with the same kind of budget issues though although most of the time the requirements are flexible enough to make it work.

I've always considered the user story portion of the agile engineering process to just be writing good systems requirements. I don't buy into the fact that a user story is any different than deriving a requirement from a statement of work and having a traceability matrix. If that's how people want to write up their issues/tasking I don't really care. The core of it is writing up issues/tasking/requirements that are concise, able to be completed in a sprint, and testable. Any program that does that well is going to be successful. Then if you want to gauge velocity and all that go right ahead, but in hardware development velocity doesn't mean a whole lot to me. Folks aren't just banging out bugs/features where you can predict their output.

Click to shrink...

Yeah I consider it the same. I do think it is a good way to give context to the people that implement the stories and force someone to think about why they do something, which I occasionally see as a problem when people are not using user stories. But there is no reason that is not possible without doing user stories.

 

[Prophet Steve]

Oops double post

 

[SRG01]

I think portraying waterfall as perfect is the joke lol

 

[hurlex]

We've done it. I don't think Agile as described to us really works for our group but PM's try to force it, and it didn't make us any better. Probably wasted more time on managing the process.

 

[The Grizz]

I have heard of people raising their kids using agile/scrum methodology.

Click to shrink...

I've heard and seen examples of this as well. Parents will put up the scrum board with chores that kids need to do during the day/week. Each week is a sprint and each chore is a story. It's intriguing but I prefer to leave scrum at work. To each their own, though.

 

[fulltimepanda]

the waterfall method on that comic needs to be changed.

You want to go to mars -> build a rocket -> Test the rocket -> go to mars -> find out that mars has been destroyed by aliens -> find out that management actually wanted to go to the sun anyway

 

[hephaestus]

I dont really understand what Agile is. Ive tried reading about it but it just looks like buzz words in a sentence. We have a new mechanical supervisor and he wants to implement Agile in our work area. (We perform maintenance and do repairs to hundreds of pumps, gearboxes, augers, chains, screens) we are a waste water treatment plant.
Nobody really understands what he wants, but numbers that don't
mean anything are very important to him. As well he is incredibly mad at us that we cant plan for emergency repairs 3-4 weeks in advance.
But he has reduced our stock and inventory to almost nothing which makes repairing and replacing equipment... Difficult.

 

[lt519]

Yeah I consider it the same. I do think it is a good way to give context to the people that implement the stories and force someone to think about why they do something, which I occasionally see as a problem when people are not using user stories. But there is no reason that is not possible without doing user stories.

Click to shrink...

I almost went on a rant about this earlier too but decided not to post it. But I'll do it anyway, your are dead on.

All these methods are all only as good as your team's communication both written and verbal. Stories help some people contextualize the problem which is great. I ultimately don't care how they are written; I can convert a well written requirement with shalls into a story and vice versa. Whichever works best for the team.

The most important thing to me is creating a mechanism for communication and accountability. If story is poorly written how can you hold someone accountable for doing a poor job? If a timeline is not agreed upon by both parties how can anyone be held accountable when deadlines are blown? If there is no agreed upon demonstration at the end of a sprint how can anyone be held accountable for not producing a testable item? Communication and commitments are key. Without them you can run an agile process but there will be no growth because the same mistakes will keep being made.

Agile is not construct to tell you how to run a successful program it is a construct on how to run a successful team. Successful programs will follow. Agile is largely successful because it encourages frequent communication, accountability, and honesty. It gets employees involved with the planning of the project instead of them being dictated everything to do by one person that may have a bad vision or planning.

 

[Davidion]

Much like user experience design, product management, pretty much all manner of complexity work, much of the issue arises from either conflict with existing power structures, lack of understanding, and lack of critical thinking in applying methodology which leads to thoughtless shoehorning and eating buzzword salads all day.

As been mentioned multiple time here, these are among the general things that are needed

- Clear communications
- Some semblance of work allocation around reasonable chunks
- Understanding scale and scope of work and evolving process around what's realistic
- Wrapping all of the above in visibility into understanding through research (which, btw, you don't actually need code for)

Being able to guide the team w/ critical thinking is an incredibly necessary but often underdiscussed part of any of these transformation efforts if your culture doesn't have some innate maturity.

 

[Septimus Prime]

I think before you do anything, get the team together and talk about what you intend to get out of this transformation. This should inform what methodology would be best to use and will help to get you some buy in.

 

[TheRagnCajun]

I don't know why you would use anything other than waterfall for most engineering projects. Traditionally you want to have clearly defined scope of work, requirements, budget and timeline. Agile and other methods seem like a compromise to accommodate clients who don't know what they want. When the customer doesn't know what they want you are guaranteed to waste a lot of time and resources.

 

[onadesertedisland]

https://blog.toggl.com/mars-software-development/

Click to shrink...

This is awesome. And true.

 

[Septimus Prime]

I don't know why you would use anything other than waterfall for most engineering projects. Traditionally you want to have clearly defined scope of work, requirements, budget and timeline. Agile and other methods seem like a compromise to accommodate clients who don't know what they want. When the customer doesn't know what they want you are guaranteed to waste a lot of time and resources.

Click to shrink...

I think it really depends what you're making. If the end product is a known quantity.

The big difference with Agile is that you get more check-ins to see if what you're doing is still what you want to do. The last thing you want to do is a shitload of work, just to find out that the PMs actually wanted something else.

 

[Hollywood Duo]

I think portraying waterfall as perfect is the joke lol

Click to shrink...

You never can tell these days.

 

[Mivey]

I have heard of people raising their kids using agile/scrum methodology.

Click to shrink...

What would "waterfall" style parents even be like? Just do whatever for 18 years, then see if it turned out right? If not, start again?

 

[Mr. Wonderful]

You can have successful project in any methodology. The important thing is avoiding prescriptivism. Projects are unique so it would be a mistake to force every project to be run the exact same way.

Click to shrink...

This. As others have said, not all projects are good fits for agile. The companies that are reorganizing the whole entire organization around agile are mis-managed and likely just following buzz words/management trends.

 

[Hollywood Duo]

What would "waterfall" style parents even be like? Just do whatever for 18 years, then see if it turned out right? If not, start again?

Click to shrink...

Probably one of those crazy books that are designed to make mothers feel terrible about themselves.

 

[Hecht]

What would "waterfall" style parents even be like? Just do whatever for 18 years, then see if it turned out right? If not, start again?

Click to shrink...

Isn't that how the second child gets made, only the waterfall processes run concurrently with a delay of a few years?

"Well shit these first four years didn't go well so he's screwed...wanna try again and hope the next one is better?"

 

[Septimus Prime]

What would "waterfall" style parents even be like? Just do whatever for 18 years, then see if it turned out right? If not, start again?

Click to shrink...

I'd like to see that WBS.

 

[captive]

DevOps >>>>>>>> Traditional Agile >>>>>>>>>>>>>>> Dog shit >>>>>>>>>>>>>>>>> Waterfall.

Click to shrink...

Devops isn't a development model. You still have to decide if you want to follow scrum or agile or whatever.

We have different clients doing agile ans scrum and we come in and build their shit in azure devops.

 

[Brando]

Been doing agile for about 6-7 years. I'm not sure I'm convinced it's better than waterfall. I agree that early prototypes and early testing/validation is extremely important, but that can be planned via waterfall too. I'm not seeing the benefits of it.

Click to shrink...

This has been my exact experience as well. Everyone I see online always talks about how great agile is and how their particular project couldn't be completed without it. It makes me feel like there's just this zealous religious cult of people surrounding the whole agile community because I've yet to see it work more effectively or what I would consider better had the project been run via waterfall. Granted, every organization I've gone through agile transformations with have not implemented it as its defined. They cherry pick the parts of agile they like (user stories) and leave out the parts they either aren't interested in or willing to commit to (retros).