Do you prefer working in agile or scrum environment?
Discussion
I am a developer and have been working in rapid development environment. I enjoy working on in house project as there is not much pressure but definitely you have to produce results.
I have a basic understand of scrum environment but never worked with any scrum team. Just wondering if you feel more pressure working in scrum team because you work in tight deadlines.
I have a basic understand of scrum environment but never worked with any scrum team. Just wondering if you feel more pressure working in scrum team because you work in tight deadlines.
I'd love to know who dreamt all that Agile/Scrum s
t up. We had a manger try it here, was an abject failure.
What's wrong with just defining the tasks required to fit within the project deadlines / budgets and produce something useful at certain points along the way. Put together a Gantt chart if you must. Then get on with it. Actively manage your team but don't micro manage, meet maybe once a week to ensure everyone is heading in the right direction. Maybe ramp up the meetings as deadlines / milestones loom but keep them sort and purposeful so that people have plenty of time to do the actual work
t up. We had a manger try it here, was an abject failure.What's wrong with just defining the tasks required to fit within the project deadlines / budgets and produce something useful at certain points along the way. Put together a Gantt chart if you must. Then get on with it. Actively manage your team but don't micro manage, meet maybe once a week to ensure everyone is heading in the right direction. Maybe ramp up the meetings as deadlines / milestones loom but keep them sort and purposeful so that people have plenty of time to do the actual work
C0ffin D0dger said:
I'd love to know who dreamt all that Agile/Scrum st up. We had a manger try it here, was an abject failure.
What's wrong with just defining the tasks required to fit within the project deadlines / budgets and produce something useful at certain points along the way. Put together a Gantt chart if you must. Then get on with it. Actively manage your team but don't micro manage, meet maybe once a week to ensure everyone is heading in the right direction. Maybe ramp up the meetings as deadlines / milestones loom but keep them sort and purposeful so that people have plenty of time to do the actual work
Agreed - It's also an excuse to not get it right first time and fix it later.t up. We had a manger try it here, was an abject failure.What's wrong with just defining the tasks required to fit within the project deadlines / budgets and produce something useful at certain points along the way. Put together a Gantt chart if you must. Then get on with it. Actively manage your team but don't micro manage, meet maybe once a week to ensure everyone is heading in the right direction. Maybe ramp up the meetings as deadlines / milestones loom but keep them sort and purposeful so that people have plenty of time to do the actual work
I.T. in particular, would be quite stagnant if some bright noddy wasn't employed full time by the Ministry of Murphy to create non-essential activity!
slow_poke said:
GadgeS3C said:
I like waterfalls
Me too.But lately I've been hearing the word "DevOps" being bandied about an awful lot.....
DevOps was thrown my way last week at a conference. Seems to be the new buzz word. That along with traditional developers as we knew it are a dying breed and need to adapt to become business analysts and the like.
Don't really have a problem with agile/scrum, I just see it was a way to break down the work in to tasks, which anyone used to waterfall would do anyway.
Where it works well is for those who can't figure out how to do a breakdown and spend lots of time trying to complete everything. Once they have an objective of the first task for a given sprint they understand where they are and (hopefully) can manage to get that done.
The really clever buggers are the ones that write the books/do the training courses/consultancy etc on all this junk and earn lots of money from teaching people common sense!
Where it works well is for those who can't figure out how to do a breakdown and spend lots of time trying to complete everything. Once they have an objective of the first task for a given sprint they understand where they are and (hopefully) can manage to get that done.
The really clever buggers are the ones that write the books/do the training courses/consultancy etc on all this junk and earn lots of money from teaching people common sense!
NormalWisdom said:
Agreed - It's also an excuse to not get it right first time and fix it later.
I've heard this a lot in the past week from project managers but it's really not, it's a reaction to people expecting to get something with the complexity of a space shuttle built right in a single drop.Scrum is an agile methodology. Agile means less and less and is more a general perspective on how to build working software, scrum is some specific tools for getting there. Neither of these are understood by management who, if they've even read the agile manifesto, usually have an instinct to do the exact opposite of what it says regardless and assume you're all cowboys if you, say, choose individuals and interactions over processes.
Having just spent too long working on a project for a customer where they actually had a guy whose job title was 'scrum master' - i.e. what is normally a 10 minute role for a developer was somehow his entire job... I'd recommend understanding exactly what agile and scrum are before dipping your toe. This talk came up the other day, it's well worth a watch: https://www.youtube.com/watch?v=SsReC-u--gg
As usual, it is one of those things that probably 80% of the time is misinterpreted/misapplied/mismanaged and so its worth is going to depend on a lot of factors.
You can boil "agile" down into some very basic principles, the main one being to break up the job into small tasks and check progress against those tasks very often (e.g. a week or less). This is supposed to be the opposite of defining a detailed specification and architecture all in advance, before anything is implemented, and not checking anything until the very end (which is bad as it can fail big time). The problem is, agile is therefore often compared not as an alternative method to some other method, but as an alternative to failing to follow another method. Inevitably, when it comes to the crunch, if you were going to fail at one method then it's quite likely you'll fail at this too.
However, in defence of agile, it can genuinely be very useful for some types of projects (e.g. ones where there is a fair degree of uncertainty about the best way, required features etc). But like anything, you have to implement it properly. If you are used to following one method, one in which meetings go on and on and essentially waste 3 hours x 20 people's time, you will tend to be skeptical about any method that intersperses "real work" with lots of task-setting exercises. But agile methodologies normally have very different types of meetings explicitly to avoid this - hence lots have silly things in them like "stand-ups" (meetings where nobody is allowed to sit down). If you instead just have more meetings than you currently do, you'll probably just do the same thing as you're currently doing, but slower.
In my industry/employer we have largely switched to agile processes and they have been quite successful, despite the fact that most teams don't really implement them properly. That is purely because of the nature of the work: we tend not to work to detailed briefs: the "product" itself needs to be "agile".
You can boil "agile" down into some very basic principles, the main one being to break up the job into small tasks and check progress against those tasks very often (e.g. a week or less). This is supposed to be the opposite of defining a detailed specification and architecture all in advance, before anything is implemented, and not checking anything until the very end (which is bad as it can fail big time). The problem is, agile is therefore often compared not as an alternative method to some other method, but as an alternative to failing to follow another method. Inevitably, when it comes to the crunch, if you were going to fail at one method then it's quite likely you'll fail at this too.
However, in defence of agile, it can genuinely be very useful for some types of projects (e.g. ones where there is a fair degree of uncertainty about the best way, required features etc). But like anything, you have to implement it properly. If you are used to following one method, one in which meetings go on and on and essentially waste 3 hours x 20 people's time, you will tend to be skeptical about any method that intersperses "real work" with lots of task-setting exercises. But agile methodologies normally have very different types of meetings explicitly to avoid this - hence lots have silly things in them like "stand-ups" (meetings where nobody is allowed to sit down). If you instead just have more meetings than you currently do, you'll probably just do the same thing as you're currently doing, but slower.
In my industry/employer we have largely switched to agile processes and they have been quite successful, despite the fact that most teams don't really implement them properly. That is purely because of the nature of the work: we tend not to work to detailed briefs: the "product" itself needs to be "agile".
Troubleatmill said:
Agile methodologies are very useful - for the right projects.
The problem is project managers come back from a 2-3 day course - and try it out on very inappropriate projects.
This is it, 100%. I have worked with very successful agile run projects but you have to make sure that is the appropriate methodology for that particular project. The problem is people get involved in the latest thing and try and apply it to everything. My current role I was brought in after the previous head of it tried to run a massive project using scrum, which was totally in appropriate and almost lost the company the biggest client by far. We are still paying for his mistake years later.The problem is project managers come back from a 2-3 day course - and try it out on very inappropriate projects.
I enjoy it, I think you chat to people more,, get to know your colleagues better and come up with better solutions. I also like the team having each others back. It also helps avoid having "that guy" in the team that just sits in the corner and writes code no one understands.
However, Agile/Scrum implemented badly is as dangerous not using any method. I've worked in teams who are "sort-of-Agile" and it's chaos, knackering, painful chaos.
However, Agile/Scrum implemented badly is as dangerous not using any method. I've worked in teams who are "sort-of-Agile" and it's chaos, knackering, painful chaos.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff