Agile software development, the principles. Principle 4: Business people and developers must work together daily throughout the project.

This is the fourth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.

 The question is: is this going to work in practice or is this only based on a nice marketing and sales story.

 Principle 4: Business people and developers must work together daily throughout the project.

Strange, shouldn’t this be common practice? In my daily work I meet lots of developers that have never had any contact with business people. The only notice of the business they get is the constant feed of PowerPoint presentations. When they are lucky the presentations contain hard to understand schemas, “roadmaps” and high level (or extremely detailed) business requirements.

This 4^th principle tries to overcome the communication and cultural differences between ICT and business. It recognizes that there are significant differences in culture and jargon between these two groups. By putting them together on a daily basis they get used to each other and they develop a common understanding of the goal of the project.

Working together on a daily basis must actually mean working together! So this does not mean a daily short meeting after witch the two teams retreat to their own project room.

Preferably the two teams must work together in the same space and have a constant interaction. The development team gets an impression of the daily work of the business team, the issues the business sees as important and the way the work is done. On the other hand the business team get’s an insight in, and possibility for contribution on, the solution-design and a frequent feedback about the project’s status. This will create a common culture where both teams are working together on the new systems solution. This prevents a culture where “them (developers) delivering a new system for us (business)”. The last (and most important) benefit of this set-up is that business and developers also share the same coffee machine. This makes it easier to discuss and to expose small frustrations and remarks that are not discussed in the formal project meetings.

Advantages of this principle are:

Teams bound and get a common goal.
A common culture emerges. Teams see the end-product (the delivered software system) as a common deliverable (and not just a developer’s party). They commonly feel responsible for the quality, functionality and planning/budget of the product. There is an open communication between the stakeholders and this enables a culture where difficulties are resolved quickly (and with little resistance). 

Quick feedback on proposed solutions.
The day to day communication between developers and business makes it easier to get feedback on proposed solutions. It is easy to ask an end-user their opinion about a screen design, report or business problem right away when they are just sitting just a few meters away. The developers can get their feedback in an early stage on a version 0.1 prototype. This is a good measure if the developers are building the correct software without spending a lot of effort on useless prototypes.

Common knowledge about the design and purpose of the new system.
Getting developers and business working together on a day to day basis creates a common knowledge about the purpose of the new system. Developers get to know the business goal and purpose of the system and the business people see more about the technical background of the systems technique. This makes the discussion about the possibility (or impossibility) of a certain requirement or technical solution more easy. The discussions take place with more understanding and respect for the individual team member’s profession and capabilities.

Constant focus and urgency
When developers and business are working together on a day to day basis they will keep focus on the delivery of the end-product. The need and purpose of the new systems becomes practically clear to de developers. They see the need for the new system on a day to day basis. The business sees the constant growth of the new system and can decide to implement a part of the system before all modules are finished. The business sees the need for quick feedback and focus on the systems prime objective. This hopefully will overcome unnecessary discussions (and delay) about small, low priority features. 

Information about and acting on environmental changes during the projects execution.
During the course of the project environmental changes happen. Changes in market, organization, business or other changes will have an impact on the functionality of the software system under development. Well controlled and swift action on these changes will keep the end-product aligned with the business goals. Day-to-day working together will make environmental changes known by both developers and business. Setting a proper (and agile) change management procedure will make it possible to act upon these changes without disturbing the whole project planning and budget.

Elevated acceptance of the new system.
Last but not least; Working together on a day to day basis will make the creation of the product known to most of the stakeholders. Most of the stakeholders have seen and used the system for many times in tests and demo’s before it is taken into production. This will make the transition and acceptance of the new system easier. Stakeholders will have the knowledge that they have participated and (in some cases) even contributed to the new system. They are more motivated to use the new system.

In the most ideal case the business team contributes actually on the solution by e.g. creating actual screen designs, report specifications, test specifications or manuals. The development team can contribute to the business by assisting with the initial data entry of the new system, assisting by explaining the usage of the new system.

Remarks for the (project) management of teams that are working closely together:

• Business and developers teams must be motivated to overcome their resistance in getting in touch with the other team. When there is no motivation to work and communicate together there is no actual connection and no additional benefit in setting the teams together. Joint team activity at the start of the project can help a lot in getting the individuals within the teams to get to know each other and create bounding between the teams. 
• Overactive participation between members of two teams can lead to growth of the project’s scope. Individual members of the development team will invent new functionality without noticing the project’s budget or timeline. To overcome this problem all changes must be discussed in the team meetings before they are planned to be realized.
• Frequent discussions about functionality is good but will distract people that are trying to do some concentrated work. When members of the teams are set in one large room (stimulating creativity) the discussions about project subjects (or other tings) can lead to a lower productivity on both the business and developers side. To prevent this you can choose to implement a separate discussion room that is equipped with necessary demonstration tools (whiteboard, beamer, post-it notes etc.). To facilitate concentrated work (or one on one discussion) some separate silent working rooms can be set up also.

Conclusion:

Working together on a day to daily basis will make the software development more real for both the developers and the business. Developers work on a daily basis together with the users of their product understands their needs and purposes. The business people actually see the developers working on their product. This demystifies the whole development process. Working together on a daily basis will produce a product with better business alignment, focus on valuable features and higher acceptance.

Other posts about the AGILE Principles (soon to come):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Google