Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.


Wednesday, October 24, 2012

Adventures in Agile and GreenHopper

They say that one should put process before tool. In fact, I often say this myself (thereby I confess my occasional membership in the troublesome, faceless "they"). The statement reflects the fact that so many IT projects fail when they pursue a backwards approach (none of mine of course; wink-wink). Despite knowing better, and going against the advice of our Agile trainers, I recently forced my team to employ Atlassian's GreenHopper product in our department's first Agile BI project.

Just to make things more interesting, an experienced Scrum Master arrived on-site only during the last week of the three-week virgin sprint. And the director of the department (that's me) acted as both Product Owner and Developer (and occasionally Scrum Master). And, as if that were not enough, this project was the first hands-on exposure to a data model (Noetix EBS Views), a development tool (OBIEE), and a methodology (Scrum-like)? Yeah, it was a lot.

So how did it go? Pretty darn well, on the whole, though hardly a Scrum case study...

Without betraying the confidence of our Sprint Retrospective too much, several of us cited the tool (GreenHopper) as one of the best aspects of the experience. (The Daily Stand-Up got a lot of love, too.) And, of course, nothing really compared to the ecstatic looks on our customers' faces at seeing what we actually delivered in this new technology on such an aggressive timeline!

For me, personally, GreenHopper was a revelation. Despite being a few generations behind (we are upgrading the Atlassian suite next month), the tool made a tremendous difference in what could have been a complete disaster. How did it make such a difference? To break down the differences, I'm going to look at things through a few different lenses...

GreenHopper Task Board: Drag tasks through the workflow

As a member of the sprint team... It was immensely gratifying to drag a task through the stages on the Task Board; almost as good a feeling as crossing off a to-do list item or deleting an email. And to quickly see all the tasks assigned to me and where they stand--fantastic. I found it motivating to watch the colors of the progress bar change, the red portion shrinking toward nothing. It also liked flagging impediments and knowing they would get rapid attention.
 
Wearing my Scrum Product Owner hat... I loved drag-and-drop planning and prioritization, loved watching progress and clearing impediments, and how easy it was to write new stories. But mostly I feel in love with visibility: filtering the Task Board, watching the Burn Down Chart, responding to comments and questions raised through JIRA. It was a very different experience for me and I think it will be interesting to see how some of my business partners feel about it!

And on more perspective: as a "former" Project Manager I wished I had something like this long ago. Clearing impediments at least daily in the stand-up meeting is certainly a game-changer, no matter what one's feelings about all the other rituals of Agile/Scrum.

Now what about what went wrong... Other than the fact that I don't really recommend biting off a new data model, new technology, and new methodology all at once... Nor to start with an unusually aggressive sprint duration. But setting that all aside, how did it play out? See the below chart -- far from what you'd hope to see in a burn-down chart.

Not the burn-down chart you want to see...
A few issues contributed to this ugly chart:

  • We were not clear on decomposition of Stories into Technical Tasks; this happened after the sprint began, which accounts for those blue spikes of new issues! 
  • We did not set clear ground rules for transitioning items through the workflow steps, so a lot of tasks remained "in progress" until a clean-up activity at the end.
  • Our stories may have been too "big" and perhaps need to be decomposed further even before the step of defining technical tasks. 
  • Every single moment was a learning moment for the team... 
    • In the end, what matters the most is that we delivered some great functionality to the business and learned a ton through our "trial by fire."

    posted by JasonShaffner @ 10:04 PM Add a comment!

    0 Comments:

    << Home