Agile and Beyond

Agile Requirements?

Guess what… Detroit has its own agile conference. I had heard of it but had never attended. This year I went with 4 Caliber team members. I was impressed with the sheer size and professionalism of the event.

The conference had nearly 700 attendees and was sold out weeks in advance. There were sessions covering many different aspects of agile with 6 to 7 running at a time. Caliber competition and integrators were there in force. There were booths from HP, IBM, VersionOne, Rally and many others. It turned out to be a great event packed with useful “requirements” insight and info.

There were many interesting speakers including some pretty heavy hitters in the worldwide agile community. Most notable were Ron Jeffries (“founder” of XP and signor of the Agile Manifesto), Chet Hendrickson, Steve Denning and David J. Anderson. The sessions covered a spectrum of topics around agile tooling, enterprise usage, aligning agile with business need, etc.

While a fair amount of the content was focused on the “how to” and “why” agile conversation that you’d expect, I also noticed a clear theme of “agile works but there is a lot of room for improvement”.

The opening speaker David J. Anderson’s speech was titled “Stop doing Agile, start thinking agility”. David’s main points were that there are too many organizations caught up trying to following the 12 agile principles and not enough focused on results and the value provided to the business. He highlighted the point that agile delivery teams who expect the organization to change around them usually fail. David went on to add that we need to find ways to respect current roles, titles and responsibilities while delivering in an agile way (sounds a bit like “water-scrum-fall” to me). I came away from his session agreeing that this is a key and most often overlooked factor in agile succeeding. It’s also one of the potential sweet spots for Caliber.

One of the other key sessions that stood out for me was focused on “Value Driven Agile”. There was of course mention of the key tenant of “change is inevitable, embrace it” but most of the session focused on finding ways to align work items with stated business goals (or requirements if you will J). It’s key from a stakeholder perspective to understand how work in flight relates to value, but it’s also just as critical from an implementation perspective to keep the true business goal in mind.

There was a ton of good discussion and useful information, which would take way too long for me to write up. I realize I may be seeing the world through “Caliber” glasses but I certainly felt a common thread throughout the day.

There is obviously a very tight relationship between the business drivers and delivery, but in Agile they are too often not clearly visible to each other.

The “Business team” need to define what / why, with visibility to the how / when.

The “Technology team” needs to define the how / when, with visibility to the what / why.

Organizations are struggling to bring the two worlds together. The key to success in the formal requirements market is the enabling the collaborative definition of need and allowing the delivery team to use methodologies and technologies they chose (Agile, Waterfall, Water-scrum-fall, Kanban…). The delivery team needs to always to work with an eye toward "Value" to the business - or the higher level business requirement. Visibility from one to the other is what enables true agility.

“A sportscar speeding off may be fun and exciting, but racing off without setting your direction will likely take you away from where you want to be.” - Matt Van Fleet (Agile and Beyond:2012)

  • Boehm and Turner were on this track of identifying the "Home Ground" of both Agile andPlan-driven methods around 2004 in their paper "Observations on Balancing Discipline and Agility" it's an excellent discussion of how to decide which method to employ.

    In the RE training we provide we strongly recommend the customer send the "Principal Stakeholders" for their project teams.  They are the BA, the Sr. Software Engineer and the Sr. Test Engineer.  Our focus is on getting them to learn to communicate more effectively because they all come from different cultural communiction worlds.

    While we train the normal topics like vision, scope, traceability, voice of the customer, quality requirements, etc. we also devote a half day to communication training and a half day to Agile vs Plan-driven with a focus on the material Boehm provides.  The rest of the two or three day class embraces those 'normal' topics.  Every training vendor should do the same.  Communication issues in Requirements and User Storie development are the big issue because of those cross-cultural differences.