THE AGILE MANIFESTO: UNDERSTANDING PRINCIPLE #4

“Business people and developers must work together daily throughout the project.”

The #AgileManifesto is the set of key values and principles behind the #Agile philosophy. It serves to help development teams work more efficiently and sustainably together. Known officially as ‘The Manifesto for Agile Software Development’, the manifesto details 4 Values and 12 Principles that in 2001 was focused solely on Software Development. Today, however, it has evolved into transformational approaches entire organizations, from development through operations, hope to effectively implement.

I have provided a brief explanation of each of the agile principles here, but this article will dig a little deeper into Principle #4, “Business people and developers must work together daily throughout the project,”. We will look at it’s original intent, best practices in its application, as well as discuss some of the challenge’s organizations face when implementing this important principle.

Communication is a critical component of any team’s success, and the agile principles and practices mandate it as a daily event. Communication and collaboration need to occur not only at the team level but between business stakeholders and developers as well throughout the development process. This leads to better decisions as business and development teams are aligned.

Stakeholders must frequently collaborate to ensure that the product is being developed in the correct direction, as autonomous self-managing teams balance intentional architecture with emerging design. By not fixing all the requirements up front, the customers and stakeholders can allow development teams to take a set-based design approach in which work is demonstrated, collaboration occurs, and requirements are fixed over time based on feedback. This is in direct contradiction to traditional waterfall approaches where all or most requirements are fixed up front and there is little flexibility.

Commonly, in an agile environment, feedback and collaboration occur through the use of reviews and demo’s in which the Agile Team demonstrates the work they have completed, most commonly portrayed as live working software. Teams demonstrate small increments of value (stories) iteratively, and businesspeople provide direct and timely feedback early and often. When shifts in direction need to occur or targets are missed, the team can quickly adapt their approach without much wasted effort. In a waterfall environment, feedback typically occurs at the end of production after a larger solution has been completed. Comparatively an incremental approach of a couple weeks has far less variance than one that might occur every few months.

Collaboration and communication are also facilitated through the breakdown of siloes across the organization and colocation of businesspeople (product owners) on the agile teams. Having a businessperson who can act as a proxy for the customer and other key stakeholders available to the team at will enhances understanding of the work, improves flow, and speeds up feedback as the team completes the work. Product Owners should be available to answer questions at will, and accept stories as done.

Lastly, to support strong collaboration and communication across the enterprise ensure that all siloes are broken down. Discussions need to freely occur and evolve without the use of email as the primary means. Encourage your businesspeople to participate in the demo’s and agile ceremonies in order to facilitate flow within the process. Encourage your development team members to be open and honest about impediments in the process and to speak freely when they have questions or concerns with the requested product. Even in this modern world of distributed teams, we should work together closely (virtually) daily.

Over the years I have come across many who have made arguments against every one of the agile manifestos’ principles, some more than others. There is always someone who can find fault in what seemingly seems common sensical, but then again common sense as they say is not so common. Well in this case, the arguments are not about common sense but rather ignorance, that being a lack of knowledge and understanding in what we are trying to accomplish.

Change is expensive. 

Traditional software development regards change as an expense which is to be avoided. Not knowing all the requirements up front and allowing for Set-Based Design could cause frequent changes and increased costs. Additionally, in #agiledevelopment short iterations mean priorities can be shifted regularly causing even more changes, which “costs” the company even more.

However, the mindset of avoiding change due to cost is shortsighted. We must understand that development is not only about cost, but the value delivered and the revenue extraction thereof. If we create better products for our customers by having businesspeople more involved in the process, we will generally be able to extract more value from those products. When we create products that are based on requirements our clients set months or even years ago, there is a high potential for failure. Failure, while an option, costs exponentially more when feedback becomes more infrequent. So score one for Principle #4.

Communication Barriers 

Developers are often shielded off from businesspeople. Analysts, et al, are put between the business and the development team to “translate” the business language to a language that developers can understand, and vice versa. While understandable in some instances, it slows flow and creates siloes. Instead, we should look to remove these barriers and let developers and the businesspeople interact with each other daily. In doing so, we increase mutual understanding and respect.

As we know, successful product development requires insights from both the business and technical sides of an organization. This can only happen if these two teams work together consistently. Regular communication between businesspeople and developers helps improve alignment across the organization while building trust and transparency.

If you have ever played the telephone game as a child, you know how quickly a message can be altered even when passed from person to person in a relatively short line. In business, particularly when dealing with customer expectations this can cause serious issues. Having the business and developers work closely together reduces (but does not eliminate) this risk. Getting feedback and clarifying misunderstandings early and often helps in producing more successful outcomes.

Interruptions cause delays. 

Businesspeople are busy. Developers are busy. Interrupting their work will cause delays. While not a strong argument I understand its premise. Research indicates that task switching has the potential to decrease productivity by as much as 20%. If this holds true and we regularly allow these two groups (businesspeople and developers) to interrupt each other, each could become less productive.

However, Agile has built in ceremonies for communication and collaboration to take place. The Daily Standup is one ceremony many agile shops use to put this principle into practice, keeping everyone connected. It is short, concise, and specifically focused with updates and impediment communication in mind. Followed by the 16th minute (meet after), this short ceremony is the perfect time for businesspeople (Product Owners specifically) to understand where development is, where it is going, and what they can do to help. There is no need for constant interruptions or task switching by anyone. While the DSU is certainly the place where most of this effort takes place, there are many other ceremonies that encourage business involvement with the team.

Lastly, there are always instances when businesspeople will need to speak with developers quickly and that should not be discouraged. Organizations, teams, and #ScrumMasters simply need to find a way to balance and manage this time. Doing so will help maintain and improve communication and collaboration across the enterprise, while easily sustaining, if not improving productive value delivery.

Summary

The Agile Manifestos Principle #4, “Business people and developers must work together daily throughout the project” can be a challenging change for organizations to overcome. We must get past the idea that these two groups cannot effectively communicate together regularly. We must get past the idea that how we currently do business is good enough. Just because an organization may be successful today, does not mean it will not be the Blockbuster of tomorrow.

Instead, look to be more inclusive, communicative, transparent, and visible in everything you do. Find ways to involve all stakeholders in the process from the C-Suite to your customers, to the knowledge workers developing all the things. Collaborate and communicate daily and great valuable things are sure follow.

If you found this valuable, please comment, and read our other articles that cover other principles, as well as transformational challenges and tips to overcome them. I encourage you to follow us on social media and/or subscribe to our blog.