Q

Translating business requirements and understanding team roles

Lisa Crispin offers several tools and techniques for translating business requirements and gaining insight into team members' roles on project teams.

I was interested in your article on Agile adoption (Transitioning a Waterfall team to an Agile development team) because my team is going through some pains in that area. Our big problem is that developers, business, operations and users don't understand each other, so meetings are fraught with misunderstandings. How can we come up with a common language? As PM, I'm frequently translating business requirements, working with each group...

individually and communicating what one group says to the other, which works okay but isn't efficient.

Each role in a business has a different agenda, and different goals with respect to software. I don't think I'm going overboard to say that every software project or team runs into difficulties around communication. We might code the most robust software ever, only to find that we misunderstood the business requirements.

I recommend a multi-pronged attack plan to help everyone involved in developing software find a common language. First of all, invest time for each member of the software team to become a domain expert. We can't help our business stakeholders find the right software solutions if we don't know their jobs. I worked on a team where we budgeted several story points per iteration to sitting with business experts, learning what they do and thinking of ways we could help them with software.

Secondly, try out different techniques that help groups visualize what they need. Mind mapping is a powerful way to identify ideas, requirements, ripple effects and high-risk areas for a software project. Story mapping is a wonderful technique that lets teams drill down to the bare bones of required software, then flesh that out with required features. Use retrospectives to inspect areas that aren't working so well, and think of small experiments to try to help improve your process.

The communication gap among customers, programmers, testers and business experts is a common problem. Domain-specific languages allow us to get on the "same page" about a new software feature. Even with a DSL, you may need roles on the team who specialize in communication. Testers are often good at "translating" business requirements to technological capabilities. Experienced business analysts can also facilitate better communication. Read a book such as Discover to Deliver by Ellen Gottesdiener and Mary Gorman to learn practices that will help everyone work together to build the application.

There are some fun and valuable activities that don't take much time that your teams could try to get experience collaboration, such as the Fluency Game from Language Hunters and the Marshmallow Challenge. Conduct retrospectives frequently, and try different experiments to help people in different roles learn to listen to each other.

This was first published in October 2012

Dig deeper on Building Software Project Teams

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close