Gorillarinas, Putting the agile skirt on a waterfall Gorilla
Fact: putting a skirt on a Gorilla doesn't make it any more graceful
Are your agile initiatives Gorillarinas?
If you're working in a large organization and trying to "be agile", it often turns into a strange situation where only a superficial set of changes are made, but folks wonder why their initiative isn't able to deliver the expected benefits. This is remarkably similar to putting a skirt on a Gorilla and then wondering why it isn't suddenly graceful.
I'm not saying you cannot train a Gorilla to dance ballet, I'm an optimist at heart and believe anything is possible. But don't make the mistake of thinking that the effort of taking an IT organization that has built up the overhead gunk and crud of a huge process and turning into a highly responsive and lean software delivery organization is anything less difficult than turning a Gorilla into a ballerina. This effort will be large, there will be casualties, and you will likely need expert help (or therapy).
As a member consulting organization, I get the benefit of meeting up with my compatriots at Redpoint to discuss the challenges, successes, and failures when working within transform hulking and clumsy organizations into something leaner, meaner, and more agile. One theme that recurs in these discussions is that many traditional processes are deliberately dehumanizing. They view people as interchangeable components that can be replaced at a moments notice and have no impact to the overall project. After all, if you've run out of ballerina's, you can surely substitute anybody (or anything) in a tutu to do the dance, right? This is a key failing and just plain wrong, and even in organizations that throw around slogans and mission statements proclaiming how important everyone's individual contribution is, all traditional processes turn developers, QA analysts, and even Bob the dinosaur into "Resources".
Some ways to know if you've got a Gorillarina:
standupsstatus report meetings that ALWAY last 1 hour (or longer)
- A variety of
torture devicestask/bug tracking tools... one for the "official" stuff and one for the "agile" stuff...
- ScrumMaster who's responsible for the work and assigns tasks to team members!
- Team members who sit around and wait for someone to tell them what to do
- Time-boxes that are well intended, but just never seem to work
- Planning starts with announcing a release date, then estimating the effort involved
- Retrospectives are about collecting lessons learned for our PMO to track!
- We do Pair Programming (a senior guy reviews all commits), Test-Driven Development (20 page formal test plans review d by QA AND the analyst team, and use Continuous Integration (we do a massive build the week before a release)
- User stories, requirements stories, development stories, test stories, and all sorts of other “types of stories” allow us to track the work!
- Our impediments list helps track why we miss our commitments!
- Recognize that you are not going to instantly get results by doing standups or using notecards or renaming your project manager the "Scrummaster"
- I know it's been said 1000x, but empower your team(s) to solve problems, if your process is getting in the way, ditch it... or fix it...
- Recognize that "agile" is not a technology thing, it's a business thing... everybody needs to have skin in the game.
- Agility is about values reified as techniques and practices, not merely practices!
- If you're in the Chicago area, drop us a line at email@example.com
- Find another organization that has a track record or producing results and let them help you (although our sales department would really like you to use the link above ;) )
One last note and something that was brought up while editing. Agile is not JUST the practices (jeez, there we go again...) it is as much about building shared values and attitudes about what the team is doing. Many organizations think they can send a couple of guys to "scrumaster training" and they'll come back and infect the entire organization. Helping transform teams and entire organizations from one mindset to another is a job that requires practice, experience, and skills that are not acquired in a one (or two) week class. It takes a certain type of person to fulfill this mission and if your goal is REAL transformation, it is in your best interest to seek out folks who have a proven track record. It can be a daunting task for someone who is inexperienced in the field, and if you think you can send a Business Analyst to a training course and then have them run around your organization waving the magic "agile" wand at projects, you'll most often end up with a bunch of "agile best practices" but no real transformation.Special thanks to Si Alhir and Steve Fastabend for feedback and editorial assistance....
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)