|
|
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
|
|
|
|
|
I've worked with more development processes than I care to remember, and at this point my conclusion is that none of that matters. It's people that decide whether a project succeeds or fails - process has little to do with it.
|
|
|
|
|
Yep,100% correct.+5
Nothing is Impossible for Willing Heart.
|
|
|
|
|
I agree. As soon as a process is created, the universe (as Rick Cook said about programming, but it applies here as well) brings forth a bigger idiot to make the process frustrating and ineffective.
|
|
|
|
|
|
I've been doing this more than a quarter-century now. I'm continually surprised by manager-types not seeing the correlation between hiring smarter people and getting better results.
While the methodology certainly helps, I agree with Nemanja's point.
The truth is, on anything above minor complexity, every corner case can't be thought of beforehand. Also, taking X amount of time (typically measured in weeks if not months) to define every last requirement is a recipe for failure; by the time those documents are created, the business needs have changed.
To me, that's the big strengths of agile; you have a goal, build the application toward that, and as you discover weird cases, you raise and address them. As the business needs change, well, it's just software; hopefully your design allows for some not-too-bad rework.
|
|
|
|
|
I used SCRUM and I'm currently using KANBAN.
I really like using them, although we can debate if they can effectively be applied in a fixed-time/fixed-budget developments... but this is another issue.
Using them makes the projects more successful, without any doubt.
The two main reasons I identify from the field are: Visibility and Perception.
Visibility avoids surprises.
At all times everybody knows what's going on. If there are impediments or if someone is lazy or slow or whatever else influences the estimation, it will clearly show right away.
This lets us act way ahead preventing or in the worst case expect trouble.
Perception is something that is also related to visibility.
If you actually only know that you're late near the end, your perception of delay is worse than if you already knew way before. Even if the end result is the sometimes the same, with better visibility we're able to better manage expectations.
Everybody will know that there's a problem, everybody will be able to contribute to a solution and most of all, all this will be done way ahead of disaster.
So at the end, software development is as it has always been, unpredictable.
There's no way around this. It can be greatly improved with experience and bigger safety margins but if you're stepping in a new technology or just assembled a new team, there's no methodology that will assure you 100% on-time success.
Agile methodologies will basically improve the project visibility, improving the perception of delay.
|
|
|
|
|
AlexCode wrote: Agile methodologies will basically improve the project visibility, improving the perception of delay.
Agreed. This, along with with the ability to clearly identify the cost of spec changes to all stakeholders, have been the top two benefits of the agile process in our company.
/ravi
|
|
|
|
|
So far I haven't been working on a project that use any agile methodology as envisioned by its creators.
We had a stint in Extreme programming (is this correct choice of words? ), but reigning project manager wasn't up to it and it ended in several burst's of rage and quarreling.
Also we started some projects as agile, but they ended up in who knows what direction... lack of discipline and lame project management are to blame (I strongly believe so).
In current team, most of the time we work by principle of iterative development, so we have no sprints, rushes, daily chats and accompanying documentation as preached by some agile standards.
From time to time we work in some bastard form between waterfall and iterative approach (big picture is purely waterfall, but on smaller scale progress between steps is mostly iterative).
Mislim, dakle jeo sam.
|
|
|
|
|
I would say that the main contributor to out less successful projects were because of promises that were made by our project managers or marketeers after the given correct inputs from the product owners and more specifically the disregard of the inputs given by the product owners and the promise to deliver something in half the time. It has nothing to do with agile.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
