I had the pleasure of chatting with EBG Consulting‘s Mary Gorman at the May Greater Atlanta IIBA chapter meeting. As we were rapping about training, methodology and the work she and Ellen Gottesdiener are doing on their upcoming book, it was mentioned that the very same core principles that worked in successful plan-driven/serial development projects (and yes, there have been many such – I’ve participated in a few myself) are the same ones that make an agile team successful, and will be the same ones that make delivery using the next big, buzzword delivery methodology successful.
Not long ago, I wrote a few thoughts on what “agile” means to the business analyst, and mentioned that, in the end, it is about adaptability. If we can learn those basic, timeless principles that make any project successful, we’ll be able to identify them and adapt more easily to any environment whether waterfall, spiral, scrum, or the next big thing.
One of those fundamental principles – and right now I’m of a mind that it may be the most important of all – is that of combining and enabling the cross-functional team.
Strip away almost all the other “stuff” associated with methodology and project overhead, and (at least in my experience) the essence of successful projects is this:
- Assemble a group of smart, motivated people with the right skills to get the job done. Typically, you’ll want analysis, modeling, design, development and QA skills, and perhaps others depending on the context.
- Give the team unfettered access to the business decision makers and users whose regular input and feedback are critical.
- Empower the team to decide on the conventions they think they need in terms of planning/process/ceremony/division of work. In some cases process these may be more rigorous, in others less.
- Ensure that the team and stakeholders have a clear and unified understanding of what “done” means, what success looks like (and how it will be measured!), and a plan for getting there.
- Give the team time to work through the inevitable kinks and challenges of transforming from a group of individuals to a team. This implies enough time to establish familiarity and a sense of accountability one to another; time to gain a sense of the value and role of each individual, and time to establish a repeatable, maintainable rhythm.
- Facilitate a learning environment where lessons of the past are applied, and constructive feedback a commodity that is valued and not feared.
- Keep the team together and give them time to optimize performance.
- Get out of the way, and let them deliver.
Regardless of the methodology you use, or what you call your requirements, if you can manage the above, you have a pretty good chance at success in any environment.
Thanks for the post, Jonathan! I’ve found that in addition to working with your own team, it can be really helpful to solicit the input from other teams as well. A colleague of mine recently wrote an article about this topic and how it can really improve the project. Check it out
here.
Thanks for the comment, Kell, and welcome to Practical Analyst. I’m not sure why, but your link didn’t com across correctly. I did give it a look, though. Thanks! I’ve long been a big fan of the Seilevel site. Here is the link for the benefit of others:
http://requirements.seilevel.com/blog/2012/04/business-analyst-tip-the-value-of-internal-reviews-for-bas-and-ba-teams.html