Agile Quickies: Business and Developers work together daily
Have you ever played the game of telephone? It’s the one where a phrase is started, and repeated through a line of people to see if it gets distorted or maintains integrity until the end. It can be fun to see how something seemingly simple can lose fidelity in such a short amount of time. Now blow that game up from just something you do at a “Team Building” event, and insert complex business requirements, stage gating, differing interpretations of the same word, and the inherent challenges of translating esoteric business rules to equally specialized technical expertise. It’s a miracle that we’re capable of delivering on anything!
PMI conducted a study in 2013 that “states that poor communications is a contributing factor in 56% of the projects that failed.”(1) and that “PMI’s Pulse communications research finds that effective communications leads to more successful projects, allowing organizations to become high performers (completing an average of 80 percent of projects on time, on budget and meeting original goals). These organizations risk 14 times fewer dollars than their low-performing counterparts. The report also focuses on communications challenges that prevent organizations from accomplishing more successful projects, and identifies key initiatives that can help organizations improve their communication as they face their own unique challenges in such a complex and risky environment”.(2) It’s quite clear that effective communication is one of the most important skills we can develop as a team to reach more consistent success.
So how do we avoid falling into the trap of poor communication?
This cartoon has been around for awhile, and speaks well to what we experience as a team building solutions for our customers.
Agile advocates for business folks and the development team talking daily to ensure we are aligned with “The Why”, and the challenges of implementation. We work together to solve the real problem of the customer.
Ideally we are also working closely with the customer to understand the challenges they are facing and collaborating to deliver a solution. The missing piece in the cartoon above is collaborating with the customer to understand what they are looking for, rather than what we think they need, or what we find can fit into our “business strategy”(3).
Additionally, if business and tech are working closely together daily, we can communicate to all stakeholders when we reach a technical challenge that may require more time or more thought to solve. Rather than communicating in a status update slide deck, we will have real-time updates and understanding to be able to respond appropriately rather than reacting .
Finally, when all stakeholders are involved, and the people building the product are in fact stakeholders, there is a shared sense of ownership. Developers may have insight into how to solve that business people may have overlooked. And when we all feel the success or learning (some people say ‘failure’) we take that to heart and work to identify ways to improve and ensure that what we deliver works. When we collaborate as a team and solve problems together, we will generally arrive at a solution that not only solves the problem more effectively but achieves higher quality by avoiding communication breakdowns, and ensuring that we are building has a shared vision of success.
How we embody this principle:
- Communicating frequently in face to face meetings between business and the development team.
- Demos after each sprint show what we’ve been working on and provide a chance for feedback.
- Giving the team building the product trust to execute and influence in the solution.
- Collaborating with the customer to determine the strategy.
- Not creating a strategy that is too far in advance or too rigid to allow for adjusting if new information is revealed.
Making it practical:
- Business (in a Scrum context the PO) attends daily standups to provide any guidance or relay any feedback.
- Include the development team in all steps of the project cycle from ideation to discovery.
- Developers provide feedback for the proposed solutions and can propose alternative solutions.
- Full engagement in the process from all members of the team. Nothing is out of our job description. We Behave Like Owners at all levels.
- Take a step back during backlog prioritization and refinement to determine what is most valuable to deliver to the customer.
Further reading;
The “Project Cartoon” Root Cause. Variations of this cartoon have… | by Joseph Reiter | Medium
Building trust to learn as a team | by Joseph Reiter | Medium
1 Monkhouse, P. (2015). My project is failing, it is not my fault. Paper presented at PMI® Global Congress 2015 — EMEA, London, England. Newtown Square, PA: Project Management Institute.
2PMI (2013). The Essential Role of Communications.
3 If your business strategy isn’t aligned with solving customers problems, then we may want to rethink our business strategy… HBR’s Embrace Of Agile (forbes.com) AND Prioritize a backlog like an entrepreneur | by Joseph Reiter | Medium AND Entrepreneurs, Don’t Build Too Soon | by Alex Osterwalder | ThinkGrowth.org AND How To Test Your Idea. Start With The Most Critical Hypotheses | by Alex Osterwalder | ThinkGrowth.org
