Some time ago I found myself interviewing developers for a position that we had and quickly found that being “agile” for many either means that they are doing iterative waterfall development or that they are just simply not doing waterfall so by default it must be agile.
What I found is that while people have varying opinions on agile and even more varying practices, I found that there are a few key pieces that most often got skipped.
Item one. Stop and evaluate after every sprint, otherwise known as retrospectives! If you take nothing else from this article, take this. First off get the whole team in the room and kick out any bosses or supervisors. Have your staff submit topics ahead of time anonymously as to what went well, not so well, and what to improve. You will be shocked at the honesty your staff will have and over time the need for animosity should go away. This is all great, but the most important thing to come from these meetings is that you have action items as a result of these and hold people personally accountable to see them through. You want to build a culture of personal ownership!
Item two, stakeholder involvement. This one can get tricky. I work with groups that have well defined stakeholders, and I have some groups that are the polar opposite. What I have found is that once the stakeholders have vested interest and ownership into the backlog they will be more involved. And yes, this means that you let them make the priority calls. Now that’s not to say that you don’t intervene when technically necessary, but you will find that they will step up to the occasion and it is better to let the stakeholders battle out the priority then for you to guess it.
In closing, unless you subscribe to a pure implementation from the agile manifesto, chances are we have all deviated slightly and adapted to what would work best for our unique situation. To me I think that is really the heart of what agile development is about. Inspect and adapt.