|
At least 50% of the people who have used this methodology see no benefit towards the success of a project. I am very pleased to be in the last group who have never had "Agile" inflicted upon them.
The corollary question should now be asked - did "Agile" reduce your workload.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes said: I am very pleased to be in the last group who have never had "Agile" inflicted upon them.
You lucky, lucky person! Wish I could say the same
|
|
|
|
|
I'm prolly agile by default.
I just kinda do what I gotta do as I gotta do ya know?
|
|
|
|
|
So you are just plain lazy?
No more Mister Nice Guy... >: |
|
|
|
|
|
Na,
I just don't write a spec for myself have meetings about it etc..
I say to myself. "I should write a ..." and start in, doing what I have to when I have to.
Feel pretty agile if not dysfunctional .
|
|
|
|
|
You should have meetings with yourself, loudly discussing various pros and cons.
People will hear you and report your behavior to HR as well as management. There will be inquiries and you will be called in to discuss matters with HR.
Soon, you could apply for (mental) disability brought on by workplace stress and retire!
Can you think of a better outcome?
|
|
|
|
|
Well, I think it depends on the way you do projectmanagement. If you have a strict and efficient project process it will be successful.
I've seen a lot of agile or classic projects that weren't successful, because everybody did their part he liked. That's the real problem.
A good projectmanagement solves most problems.
|
|
|
|
|
With Scrum you have less change to do your own thing (we call it U-Boat Project), since it becomes very quickly apparent if you do not work on the agreed items. I find this a good part of Scrum, especially if you have people in the team who tend to add their "bells and whistles" that no one asked for...
Cheers
Andi
modified 20-Nov-13 18:13pm.
|
|
|
|
|
Andreas Gieriet wrote: With Scrum you have less change to do your own thing
Yes, well, if you follow Scrum. That's a defined process and if you follow it, it's good. Of cource you can alter Scrum for your needs in your company or project, but you need a defined way.
That's the same for every projectmanagement method. If you have one, it doesn't matter if you are programming agile or not.
The type of project should be the matter why you decide to use an agile method or not. There are some project were an agile development means terrific costs, for others it will reduce costs.
But that's not my original argument: You have to go a strict process if you want to succeed indepedent from agile or classic methods.
|
|
|
|
|
|
Agile = short leashed, short game
Waterfall = long term
there was a time i was working for traders who wants everything done right away - i hacked everything (fixes so dirty thinking back I still have this grin on my face), who gives a sh*t? Agile right? So it is
dev
|
|
|
|
|
It is better not to fixate on any given methodology, because the needs/conditions of the company and project are likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to be successful. It’s important to remember that Scrum and Agile methodology are not a one-time look at a companies process, it’s an on-going philosophy based on continuous improvement.
Life gives hundred reasons to cry, but thousand reasons to smile. So, keep smiling
|
|
|
|
|
Spot on. Agile seems to work well where requirements are frequently changing and the system is incrementally developed over time.
I wouldn't want control systems for a plane or nuclear plant developed like that though.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
What ever the methodology may be... "Client Is King".
So King alone can declare the success/failure of it.
As a programmer I can say its a great methodology
Thanks,
•…♥…ЯΚ…♥…•
|
|
|
|
|
From the end-user's perspective, agile is successful in getting the end-user something on-time. That may not be (all of) what they want nor when they want it.
|
|
|
|
|
Yes you are right...
Thanks,
•…♥…ЯΚ…♥…•
|
|
|
|
|
It has given us clear short term prioritisation of tasks which is great when you want to move forward.
We've combined it with Google's Design Sprint to make sure that what we deliver incorporates everybodies best ideas (or at least presents a coherent front end eventually).
Thanks to scrum we're actually moving quite fast and roughly in the same direction.
|
|
|
|
|
All of the above plus some manager's idea of what Agile is supposed to look like... and it still failed in that we delivered late (but not buggy, coz I have some integrity)
|
|
|
|
|
Yes; they have all been successes.
|
|
|
|
|
|
What I have observed as the biggest contributions to success/failure is in what you are attempting to manage.
Trying to manage people contributes to failure.
Managing Projects and leading people contributes to success.
I have work in a "jelled team" only twice in my long career. Once as a team member and once as the team leader and project manager. Both times the experience was quite awesome in terms of productivity, moral, project success and personal satisfaction and growth.
Treat people with respect and dignity. Exercise faith in them and patience with them. Come to mutual agreements as to what and when they can deliver. Actively remove road blocks. Have a weekly meeting where open discussions are encouraged and valued. Go to lunch together where work talk is discouraged (but not forbidden). Allow them to exceed your expectations and theirs and they will.
|
|
|
|
|
Agile isn't about developers... it's about managers. How else can we tell them what needs to get done? How else can we show them expectations need to change? How else can we show them 'feature creep" is out of scope and causing us to miss deadlines?
modified 18-Nov-13 16:02pm.
|
|
|
|
|
I'm currently using SCRUM and not a fan. We are on two week sprints. Our overall sprint goal has us accomplishing a goal that doesn't fit into the two week box. The result is completing things for the sake of saying they are done. More unit testing should happen, but we don't have time.
The problem is not actually SCRUM, but the way it is implemented. The "agile" process is turned into a very fixed and rigid thing. I'm starting to laugh every time I hear agile.
|
|
|
|
|
We have started to use some agile methology in our projects, but for many things, we quickly decided not to implement i.e a full scrum methology. It just results in many meetings, but as long as developers have more than enough open tickets, that hardly helps reducing the time to the release.
|
|
|
|
|
It would be interesting which Scrum meetings were optimized away and in which way. My experience is that many meetings are not sufficiently moderated. Keep them short and don't let the ones who "like to talk" to stretch the limit. Have a clear topic, everyone must come prepared into the meeting.
Cheers
Andi
|
|
|
|