11–13 of 13 posts
- Small team in which everyone knows everyone else and the chemistry is right
- Clear objective, all team members own something, could be share or part of project, whoever falls behind got maybe one or two chances and then gets cut ruthlessly
- Team is working on challenging projects
Most teams simply do not satisfy even one.
As someone who has worked in 5 different companies using some form of Agile, I have the following take on this (below). I know you said you're not strictly a development team, but that's where my experience is and the comments below are focussed. That said hopefully some of the points are transferable to your domain. - Agile is about flexibility, but it can* come with a much bigger price tag if you don't do most of y…
You make a lot of good points but I disagree with this one. I understand the need for business to know how much a project will cost, but I don't think there is any other way than finger in the air. Or rather looking at a project of similar scope and going from there.
The core of agile, for businesses, in my opinion is to deliver business value in the shortest amount of time. Changing requirements are not a bug but a feature of Agile. But you can't estimate for the unknown.
Let's say you are building an app for a bank that allows customers to leave comments on merchants as an option, three menus down. Turns out your customers love that feature and the bank decides to promote that feature.
This business agility is at the core of digital transformation and it should not be discussed away as not being part of the original requirements. Rather it should be embraced.
But you can't estimate the unknown. And I have in my life never seen a project that didn't have wild changes in requirements along the way.
So in my opinion you may as well throw out a number based on experience. Deep estimation based on Excel sheets and task completion times are not gonna improve on the result.
> So, my question: Is there a way to get Agile right? or are we doomed to fail in the same ways that has been described by countless articles discussing the downfalls of Agile? Yes. Don't be dogmatic. Pick an initial set of processes/practices that match more or less what you already do, want to do (based on a reasonable belief of utility and practicality), or have done (with success) in the past. As you move forward…
I would like to make one point that I would highly recommend in respect to a lot of people unhappy with Agile methodologies.
I suggest picking a method, let's say Scrum and really implementing it as recommended. Get a coach if necessary. Try to experience it first before making changes. I think for example the self organizing team has to be experienced rather than read.
Only once you have done it, by the book, start making changes and improve the process.
Don't fall into the trap of reading about Scrum, thinking well I don't need retrospectives they are dumb and do your roll your own thing.
Understand what Agile is, rather than follow some cargo cult interpretation.
This will lead to dark agile, or agile in name only, where you do waterfall but with daily standups.
Which I think explains a lot of the unhappiness people experience with Scrum.