|
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
|
|
|
|
|
This, of course, applies to all meetings and not just agile ones. My experience has been that management expectations are most likely to make agile projects a success or a failure. Unfortunately, the way agile is marketed seems to raise management expectations to unrealistic levels. Agile can only work if everyone is realistic about targets and timelines.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
What we actually do is that our "Sprints" more or less extend to a release, so they can easily last for several months. The planning is done on-the-fly - as new tickets come in, we immediately (once a week or so) decide their priority and try to schedule them accordingly, including to the current sprint's backlog. Only very rarely (basically when an entirely new project is going to start) we really go through the whole backlog and schedule it. So normally we have a daily sprint meeting (15-20 mins) and a weekly backlog review.
I'm not saying it is an optimal approach, but for us it seems to work.
|
|
|
|
|
in our firm only junior developers need to "Standup" every morning.
us old dogs get to "Sit down", when underlings report to us everyday
dev
modified 20-Nov-13 3:54am.
|
|
|
|
|
Unfortunately, we are not buzzword compliant. We just tend to get on with the work.
|
|
|
|
|
|
Good leadership and open communications are all that's needed.
|
|
|
|
|
I relate to this comment.
We use a lot of pieces of Agile as they make sense.
Pair programming is great for getting new people up to speed, and for cross training.
Works wonderful when you are doing something totally new to both developers. Serves as
an on the fly logic check. But I do not see the need all the time. It can always be requested.
Test Driven. Anyone who has had to recompile 20yr old code will tell you how nice it is to
compile and TEST the current source version and make sure it builds the current system. Even
better if it has a test case it can run. Awesome if it has a full test suite attached that is
easily accessible.
One of the nicest things it does is to give a common language to people so they can communicate.
When management starts thinking in terms of Sprints or Cycles, or Releases. They suddenly realize
you cannot have EVERYTHING in the next release. Suddenly, the 1yr estimate to completion makes
sense to management who always thinks "Software is easy. It's soft. Just bang out some code."
It is THEIR job to ASK for what they want. It is OUR JOB to set their expectations and let them
know the COSTS of what they are asking for (time, energy, money/tools). And finally, when we don't
know, we have to admit we don't know, and get some guidelines.
|
|
|
|
|
That will die away.
I've seen this all before. E.g: "TQM" in the workplace (Total Quality Management). It was pushed, hyped, and touted. The W.Edward Demings thing.
It's primary success was making money for those who taught it.
Work satisfaction was for those who are satisfied with countless meetings.
And "Change of Culture" was the holy grail.
I see agile programming techniques as more tail-wagging-the-dog. Perhaps I'm just stubborn - or plan ahead and know what I'm doing.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Yes, teaching **any** development approach is a money machine - as long as you find enough people interested in such approaches.
For example for Scrum, you find enough people - and I doubt Scrum will die away soon, if at all, for small project development teams of 5-10 people.
For smaller teams it's less effective, for larger teams you need to become creative (Scrum of Scrum, etc.). For distributed teams (e.g. over different time zones), it is more challenging. Keep in mind: it is not the "one and only truth" - it is *an* approach to get (smaller?) software development projects more predictable.
I find the key concept of getting all "running the *same* direction" and the means to achieve that concise and lean. E.g. Scrum has little meetings overall - every excess meeting would be an impediment that is removed by the Scrum Master - hopefully 
Regarding "Culture of Change" (I assume you meant that): I think it is a commonly accepted reality in software develpment, that you cannot specify upfront everything and then construct the software in isolation to finally - "Big-Bang" - deliver the solution. Projects evolve to a solution with varying stakeholder inputs over time. There must be some means to integrate these changes into the process.
As said, Scrum is not the one and only truth, but it is an approach worth to consider.
Cheers
Andi
|
|
|
|
|
cant agree more - relentless corporate bullshit
dev
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
