-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
(Project Management) Agile in non-software development environments
- Thread starter Deleted member 19844
- Start date
OP
OP
This triggers another question for me: I manage a project team where the people engaged in several different projects for different clients. Some of the projects are multi-year efforts with predictable standards and desired outcomes, some are smaller efforts that only use a couple of my resources, and some of the projects are actually ongoing, predictable, repeatable support processes.
So my question is, if not all projects are suited to a particular method, then how do you manage a team that's engaged in such a variety of projects?
In web development where trends change as the project is being developed or A/B testing is part of the process you can't do waterfall.
User stories are good. Failing fast is good. Security and quality left are good. Using PIPs as an excuse for not doing anything else but what is precisely what has been written down or kanban sizing as a passive aggressive blocker is fucking bullshit. Answer my question, Steve. I don't need to go through your goddam scrum master. I know the people who set up payroll. Oh, NOW you got time for me, Steve? This looks like 3 units for you now, Steve? Just magically fits in with the epic? You're a miracle worker, Steve.
Can someone explain the point of user stories to me? It's probably just that my PMs suck, but it just seems like it's just adding cognitive load onto your requirements. Instead of having a nice list of bullet points, you're parsing paragraphs of text, half of which is just filler connective tissue. "As a User I can" is almost always superfluous.
Also, (and again, this might just be because of my bad PMs), agile seems like it's terrible at dealing with dependencies. Oh, this ticket depends on this other one being done? I guess maybe we'll deal with it in 2 weeks in the next sprint. If that first ticket is even done then. Critical path is even taught in CS 101!
Also, (and again, this might just be because of my bad PMs), agile seems like it's terrible at dealing with dependencies. Oh, this ticket depends on this other one being done? I guess maybe we'll deal with it in 2 weeks in the next sprint. If that first ticket is even done then. Critical path is even taught in CS 101!
I work as Product Owner - although in Software development, but for a historically-grown legacy software, which means you still have to make room for critical stuff.
You should see the framework as that - a framework within you make the best of it. If you follow every "rule" to its absolute core, you won't get anything done.
That doesn't mean you should only apply the things that you find beneficial, but the frameworks are written very open for a reason, and I think many people starting to follow it, follow it too strictly. There are many real-world structures that aren't even covered, so you have to try to fit them in as best as you can. Consistency is key tho. Whatever you do, do it consistently.
As for how to approach user stories and the like, the most important aspect is the problem vs solution domain.
The stakeholder should only focus on the problem domain.
"What"...
...should be the end result
...are the feature requirements
...is the accomplished benefit
...etc
The Engineering / software team is responsible for the solution domain.
"How"...
...should that end result be accomplished
...should that feature be designed and implemented
...etc
The worst thing that can happen is the project lead or stakeholder micro-manages how something should be specifically done without listening to the input of the engendering team. Trust is essential. The team trust that the requirements and priorities are what is needed and the PO trusts the team that they know how to implement the best solution.
You should see the framework as that - a framework within you make the best of it. If you follow every "rule" to its absolute core, you won't get anything done.
That doesn't mean you should only apply the things that you find beneficial, but the frameworks are written very open for a reason, and I think many people starting to follow it, follow it too strictly. There are many real-world structures that aren't even covered, so you have to try to fit them in as best as you can. Consistency is key tho. Whatever you do, do it consistently.
As for how to approach user stories and the like, the most important aspect is the problem vs solution domain.
The stakeholder should only focus on the problem domain.
"What"...
...should be the end result
...are the feature requirements
...is the accomplished benefit
...etc
The Engineering / software team is responsible for the solution domain.
"How"...
...should that end result be accomplished
...should that feature be designed and implemented
...etc
The worst thing that can happen is the project lead or stakeholder micro-manages how something should be specifically done without listening to the input of the engendering team. Trust is essential. The team trust that the requirements and priorities are what is needed and the PO trusts the team that they know how to implement the best solution.
So that's what agile is, I though the name sounded familiar lol.
Mildly nfsw?
Mildly nfsw?
Lol only if you share a picture of it :]
Feel free to reword it, too. I only wrote it off the cuff
I am so sorry to hear the software industry is infecting other industries with its ideas.
People should not learn from us.
Though I ain't lie, I saw 10 people startups who had full time "scrum master" with no other responsibilities. So that stupidity can start small.
People should not learn from us.
I think agile has a couple of good ideas, but because consultants need to sell books and conference tickets, it can be turned by people who love rules and process into this dumb ass time wasting thing, which is what usually seem to happen once your company/organization gets big enough.
Though I ain't lie, I saw 10 people startups who had full time "scrum master" with no other responsibilities. So that stupidity can start small.
Devops is unpaid overtime.
I mean yeah, I know the slides of the people who go around suggesting companies do that talk about other stuff, but in my experience what it means in practice is fire all your ops people and make your devs do the same job.
you should be identifying dependencies when your team grooms your backlog (or during any other context in which you may be exploring/investigating/researching the work). Then the product/project manager (whomever queues up the work) should schedule and prioritize it accordingly.
Technical dependencies are one thing, but one could even consider the front end UI design as a "dependency" and the last place I worked, we tried to stay ahead of development by 2-3 sprints.
Threads like these are fun to jump into as a total and complete ignoramus and try to figure out what the hell you guys are talking about.
Except in the waterfall method, the rocket failed testing so it went back into development. The majority of the designers were let go because their job was done and they were mostly contractors. Hiring was done but no one can figure out how the rocket is supposed to work.
I work with IT side from business. I would say about 20% of my job is trying to solve business application errors and problems, and creating tickets/JIRAs for bugs. Then I get on biweekly calls to prioritize these bugs against feature release. The IT side I work with follows agile/kanban thought of fixing problems. Lot of times what happens is that I report a bug which a user reported to me. For example, when they create a new record in the application, the system created a dupe dwkey in the data warehouse. When I run the reports, the wrong record is being fetched. I created a ticket for the IT team to resolve this, and it got lost in a sea of other tickets. 6 months from now, my ticket is still pending and the user found a workaround in the application (killed his own record, created a new one, migrated previous dependencies etc).
In short my business users are finding workaround because IT cannot solve their issues.
Then, during devops/cross functional meetings, they show that the application has an uptime of "99.6%" in the past two weeks, hurrah. Me and my peers just laugh about those horseshit numbers every time. Sometimes we take bets on what the new number is. The application itself is so bugridden, why show it's availability kpi? To show us how great they are doing? It doesn't make sense.
In short my business users are finding workaround because IT cannot solve their issues.
Then, during devops/cross functional meetings, they show that the application has an uptime of "99.6%" in the past two weeks, hurrah. Me and my peers just laugh about those horseshit numbers every time. Sometimes we take bets on what the new number is. The application itself is so bugridden, why show it's availability kpi? To show us how great they are doing? It doesn't make sense.
You can use scrum to queue up and protect their workloads in each sprint. Every planning, you can reprioritize things.
You can use something like kanban and just track how many tasks your department can finish to get a predictable flow.
I think the idea is for the ticket writer to conceptualize his asks as a user. The format just helps with that, but I personally think it flies in the face of agile philosophy to force people to use that format.
Does anyone have an easy to digest reference on these project management styles? I work in healthcare IT and occasionally hear terms like agile, scrum, kanban etc. around the office but I've never had any formal training in the subject as my background is clinical.
I've found myself taking on a bit of project management out f necessity lately and I'm just sort of making it up as I go along. Apparently I created something very close to a kanban board, but I'm guessing the software I used was geared towards that already.
I've found myself taking on a bit of project management out f necessity lately and I'm just sort of making it up as I go along. Apparently I created something very close to a kanban board, but I'm guessing the software I used was geared towards that already.
Jeez sorry! :(
I've mentioned it earlier but it is basically forcing you into a format that lets you consider a number of thing such as who benefits from a feature and for developers provides context for who they are making it. Also what to make, but that's always done anyway. And how those users benefit from it.
It can also easily be done without user stories. But way too often I see tickets that don't provide that info and I am confused at why to do something and for who I am doing so. And then it is also often that even who made those things did not really consider that and people are just creating things that seemed like a good idea but barely benefit anyone.
A simple overview is easy enough to find with Google it with everything you can dive a lot deeper. I think this works for at least the basics. Look up the agile manifesto for agile, the Scrum guide for Scrum and Kanban is kind of the board.
They are used as umbrella terms for so many things though so all are associated with a lot of extra stuff. Kanban is closely related to Lean and it may be worth it to start searching for that too.
The simple way I understand it is if you have a project that can change many times along the way then agile is a good method to use. If not, then waterfall will work just fine.
My company is trying to use agile service managment for oporations after putting scrum in place for projects,but for them agile service management is just a way to micro manage. They also want to work in the ITIL framework but don't really seem to want to invest the time to learn what that really is.
Scrum has been benefitual since its been keeping people on task for once. ITIL has been a waste since they won't backup up the problem managers (my job) and change management is still a mess after 9 years. Plus they have us doing 2nd/3rd level app support along with problem management.
My company is trying to use agile service managment for oporations after putting scrum in place for projects,but for them agile service management is just a way to micro manage. They also want to work in the ITIL framework but don't really seem to want to invest the time to learn what that really is.
Scrum has been benefitual since its been keeping people on task for once. ITIL has been a waste since they won't backup up the problem managers (my job) and change management is still a mess after 9 years. Plus they have us doing 2nd/3rd level app support along with problem management.
This so much.
I told my project team we won't be doing agile anymore, changed some minor stuff and adapted scrum a bit, and suddenly they stopped complaining and started actually working.
I've worked in dev companies that have tried to move to agile through scrum several times, they've all messed up and found their way back to something like waterfall.
As a developer it's mostly felt like busy work for the managers to keep on busy working. The rest of us just kept on going as we would have no matter the system
As a developer it's mostly felt like busy work for the managers to keep on busy working. The rest of us just kept on going as we would have no matter the system
My company has been doing "Agile" for 7 years.
Most projects i've worked on were just "pretend" agile. Basically, we do daily meetings to say what we've worked on yesterday and what we'll do today, we have a board with tickets in different stages and that's about it. The rest is basic Waterfall way, we just call it "agile" for contract reasons.
But i'm currently working on a project full agile for a change : We're one year late on the MVP delivery. So either we're exceptionnally shit at it or there's something clearly flawed in this process.
Anyway, i'm definitely not sold on it. For any type of work. (and fuck the retros, this is always a boring slog to go through that never changes anything)
Most projects i've worked on were just "pretend" agile. Basically, we do daily meetings to say what we've worked on yesterday and what we'll do today, we have a board with tickets in different stages and that's about it. The rest is basic Waterfall way, we just call it "agile" for contract reasons.
But i'm currently working on a project full agile for a change : We're one year late on the MVP delivery. So either we're exceptionnally shit at it or there's something clearly flawed in this process.
Anyway, i'm definitely not sold on it. For any type of work. (and fuck the retros, this is always a boring slog to go through that never changes anything)
I'm actually programme consulting right now for a company that has "gone Agile" and I'm basically trying to build a waterfall structure around them and they're loving the changes (I think).
Tbh I don't really see the point in agile outside of software development because the whole point is providing iterations on requirements so that the devs and business are on the same page. There are good things, like having a 15 minute stand up 3 times a week is good for keeping up to date on what's happening in the short term. But right now I've come in and the programme team have no idea what they're doing outside of a month in front of them and I'm now trying to map it out for them.
In my experience, it does not work for every team.
In my previous job I was part of a small team responsible for solution design and implementation/deployment for specific network appliances, but also responsible for changes and solving outages related to those appliances. Any (extra) work we received from the latter had impact on the former.
With this, together with unengaged management only concerned with delivery results on the former, you could imagine I was not a fan. This method of working does not fit well in an operational department, in my opinion, especially if your team is a one stop shop responsible for everything. And of course it doesn't help it was forced upon us with the only argument that other teams in the IT department do it as well. Perhaps it does work well with larger teams that only have key areas of responsibility.
In my previous job I was part of a small team responsible for solution design and implementation/deployment for specific network appliances, but also responsible for changes and solving outages related to those appliances. Any (extra) work we received from the latter had impact on the former.
With this, together with unengaged management only concerned with delivery results on the former, you could imagine I was not a fan. This method of working does not fit well in an operational department, in my opinion, especially if your team is a one stop shop responsible for everything. And of course it doesn't help it was forced upon us with the only argument that other teams in the IT department do it as well. Perhaps it does work well with larger teams that only have key areas of responsibility.
Look, all you need to do are plot out your key milestones ahead of time as possible, and then try a hybrid of Agile and Waterfall philosophies until you hit something that works for the team.
Make sure you're tracking your Actions, Risks and Issues, and you're golden.
I feel in IT Agile can be really beneficial because of the need to build and test all the time (and realising the design isn't what was asked), but I just cannot understand why you would go full agile in a non-IT environment.
Make sure you're tracking your Actions, Risks and Issues, and you're golden.
I feel in IT Agile can be really beneficial because of the need to build and test all the time (and realising the design isn't what was asked), but I just cannot understand why you would go full agile in a non-IT environment.
Agile is NOT A PROCESS
Agile is a change in how everyone at a business THINKS ABOUT THEIR JOB.
Individuals and interactions are more important than process and tools.
Working software (getting shit done) is more important than comprehensive documentation (work that only makes sense when getting shit done is not at risk)
Customer collaboration over contract negotiation
Responding to change over following a plan.
Agile is about keeping things small and talking a lot.
Any "agile transformation" that does not force people to change their own working habits to follow the manifesto principle is a waste of time.
Agile is a change in how everyone at a business THINKS ABOUT THEIR JOB.
Individuals and interactions are more important than process and tools.
Working software (getting shit done) is more important than comprehensive documentation (work that only makes sense when getting shit done is not at risk)
Customer collaboration over contract negotiation
Responding to change over following a plan.
Agile is about keeping things small and talking a lot.
Any "agile transformation" that does not force people to change their own working habits to follow the manifesto principle is a waste of time.
I run a solo law practice with a couple interns and an assistant. I do put things into Trello for a Kanban board view. Is there anything from Agile that could apply to my situation?
We use kanban for our workload and do a standup 3x a week to discuss what we're doing/have Done.
(Work in gov, legislation analist, we handle new legislation and questions/issues regarding existing leg)
Use what works for you. Dont overthink it. Try it for a month or two. If it doesnt ADD value, dont do it.
One thing I've encountered among people on the business side, especially product managers, is that they assume agile means 'I've got a problem, you need to drop everything now to work on it.' and of you don't they wander off muttering about not being very agile.
I'm about to embark on my Agile foundation training (I'm a PRINCE2 trained PM) and I'm looking forward to it.
I'm about to embark on my Agile foundation training (I'm a PRINCE2 trained PM) and I'm looking forward to it.
with these things I usually find that if it has a name then it's something made to sell books and training seminars. The problem I have with these ideologies is that it's like hey look let's analyze how good teams work together and then package that as a project management methodology. But you never stopped to consider if it's the actual people making up the team that made it successful. I have a massive distrust for any packaged solutions that's fueled by buzzwords and marketing. To me it makes more sense to put together really good teams and have them figure out the process. Yes that's hard, all great things are hard to do. Modern software is generally complete shit.
Last edited:
I feel the same is true. Apply this to anything. Useless analysts come in and try to understand successful things and only copy attributes not getting that it took someone special creating them. People aren't cogs. The secret to success is to have good people, treated well, and trusted. This formula also includes a lot of failure prior to success, but capitalism is always looking for a cheat code.
yep, people take agile to just mean "I use jira and we ship fast"
when in reality you use jira wrong and you're still overwrought with terrible middle management and awful micro managing of every minutia of a feature.
The best thing is to analyze what your team does and then find a hybrid of different methods that makes everything transparent and efficient.
And don't use a single buzz word. Then everyone will think you're evangelizing some method you fell in love with.
I just work in the Water Quality side but Operations people told me the biggest issue in an emergency situation is not having replacement parts or personnel on site when something goes down.
And don't use a single buzz word. Then everyone will think you're evangelizing some method you fell in love with.
I just work in the Water Quality side but Operations people told me the biggest issue in an emergency situation is not having replacement parts or personnel on site when something goes down.
Our biggest problem is management doesnt want to carry any inventory and most of the parts we need has a 18 week or more delivery time. We end up stripping the broken equipment down, glueing it together and limp it along. Then every temporary fix becomes a permanent fix.
Sorry side question how does your approvement process work to buy parts? They took away everyones company credit card so when i need some small parts. I have to get a P.O. then it has to be approved through 3 layers of management and the company im buying from has to have all ready been pre approved for purchasing from.
I work in construction and I use Trello to keep myself organized and looking ahead on all my projects. Its incredibly useful.
I don't know much about any of these methodologies because they seem like such buzzword word-salad whenever I try and read about them.
I don't know much about any of these methodologies because they seem like such buzzword word-salad whenever I try and read about them.
Yep it's almost exactly the same process with approvals and POs. And getting a vendor approved is challenging too, they have to have the right paperwork, insurance, and NSF certification even for things that don't contact the water. It feels like the performance/price of their product is the last thing we look at.
It sounds like that the supervisor/management is trying to implement JIT without understanding how JIT is supposed to work.
It would be funnier (and better highlight the pitfalls of the methodology) if the rocket failed some of the tests