Gorillarinas, Putting the agile skirt on a waterfall Gorilla

-

Fact: putting a skirt on a Gorilla doesn't make it any more graceful

Ballerina gorilla

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:

  • Daily standups status 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!
Some things you can do to pave the way toward having a more graceful Gorillarina:
  • 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 agile@redpointtech.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....

Comments

Philip said…
This is a fantastic article. While I couldn't check off too many of the things that may be a sign that we've got a Gorillarina on our hands, I was certainly able to identify with it. We are attempting the transition from waterfall, and we did send a few team members to a scrum master training session and expect that that would get the ball rolling. Not exactly working. Thanks for the article.
June 4, 2013 at 1:47 PM
Philip said…
This is a fantastic article. While I couldn't check off too many of the things that may be a sign that we've got a Gorillarina on our hands, I was certainly able to identify with it. We are attempting the transition from waterfall, and we did send a few team members to a scrum master training session and expect that that would get the ball rolling. Not exactly working. Thanks for the article.
June 4, 2013 at 1:47 PM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u
Read more