I was interested in your article on Agile adoption (Transitioning a Waterfall team to an Agile development team)...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
Dig Deeper on Building Software Project Teams
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting.continue reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates.continue reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.