Business people and developers must work together daily throughout the project.
Many many years ago, I was part of this offshore maintenance project for around 2 years. During the first year, we were a team of 3 – a project manager (PM), a technical and documentation lead (TDL), and a developer(DEV). I was the DEV. The PM had to interact with the client in getting new requirements, change requests, defects and prepare a plan for them. The TDL was in-charge of conducting feasibility studies, preparing implementation proposals and relevant documentation. The DEV had to implement it. I guess you can already understand the problems with this setup.
The workflow was somewhat like this:
There were a few problems with this kind of setup.
- Typically the average time between a new proposal and its delivery would be a month, more or less. There were occasions where the scope/behaviour of some CRs underwent changes after the technical documentation was frozen and before the implementation was finished. In such cases this workflow had to be repeated. This was lost time and effort.
- The communication lines were strictly moderated apparently as per client wishes. The DEV could talk only to the TDL or PM. Only the PM could talk to the client. This also lengthened the delays in getting issues resolved with the risk of the message getting lost in translation somewhere.
- Not the least of the problem were the people issues caused due to this setup. The TDL would typically prepare technical documentation where he would mention what lines of existing code needs to change, how and then write actual changed code into his documentation. This was frustrating and I complained about the lost time and the futility of having a developer who needs to only paste code as-is from the technical documentation (not to mention the indignity felt by the developer!). I wanted a setup where there were two DEVs under the PM and both DEVs took features and followed them end-to-end with activities of both the TDL and the DEV. But the client apparently wanted this setup and that was that, or so I was told by the PM.
In an Agile setup this problem and this much waste of time from proposal to implementation would never occur and that is because of this 4th principle. Let us explore this further.
Why is it said so?
.Constant feedback cannot be sought in isolation
During the days when we were managing and delivering projects the traditional way I do remember the teams working in a more assembly-line type of an arrangement. The UX designer, architect, PM (acting as the business analyst) would take care of the “front end” which was about managing the flow of new requirements (or change requests). The development team, testing team, supporting staff, PM and others would take care of the “back end” which was about managing development and delivery.
Even within this arrangement, the UX would start work mostly after new requirements were architecturally cleared, the testing team would start their work after the development team had turned over its work and so on. The result was that bugs would be found out late in the cycle and the turnaround time would eventually be quite long. From the previous posts on the first three principles we already understand that in a complex activity like software development getting feedback as early as feasible and acting on that feedback as soon as possible is always the key to successful deliveries. After we moved to adopting Scrum, the key difference was that this invisible wall between the “front-end” and”back-end” went away. The whole team worked together on almost every aspect impacting planning, development and delivery.
Working together as a team, and not working in a perpetual hand-over mode, is the key to let feedback surface quicker while managing complex development activities. Feedback facilitates adaptation, adaptation facilitates evolution, and evolution facilitates better complexity management. The intention behind this principle should thus be obvious.
.Complexity demands transparent communication
Continuing with the previous point, if managing complex activities requires whole teams working together then it also needs radical transparency in communication and information flow so that the entire pipeline between work-feedback-resolution can be made as short and efficient as possible. Suffice it to say that such smooth communication is enabled more by everyone working together than by teams working in isolation and communicating through regulated formal modes.
Of course, when such free flow of information in tight knit teams is enabled there is a risk of ensuring that the communication and information exchanged is valuable to the project and not just noise. This is where the team culture, the organization culture and the Agile values – communication, simplicity, courage, feedback, respect, and anything else the team adopted – act as a strong foundation. This needs the support of the Scrum Master, Agile Coach and the management to ensure that noise is minimized and constructive communication is maximized.
.Transparent communication needs an open workplace
Continuing with the theme of co-locating complete teams to work together throughout, and with the theme of transparent and open communication, the next obstacle to free flow of information is visibility. Nothing impedes free flow of information within a team more than every individual sitting in different offices, or high-walled cubicles, and communicating over phones, IM, forums and so on. Letting the team sit in open work-spaces where they can actually sit and work together works wonders to your Agile adoption.
How is it put in practice?
Scrum has several events and ceremonies that ensures that the whole Scrum team, and sometimes even stakeholders, get to meet and discuss. The Product Owner is the designated role for “business people” and this role must work closely with the development team.
So, that’s it from me about this principle. But before I finish this post let me also tell what happened to the project I described at the start:
… The client apparently wanted this setup and that was that, or so I was told by the PM. So I would do my best to write code that was no where like what the TDL proposed, design it in a way that agreed with the TDL’s proposal in principle but differed in the specifics and so on. I justified it saying that what was in the documentation was a very rudimentary implementation and I had optimized it based on my testing (Later I came to know this practice had a name – Refactoring). The TDL and me would get into frequent arguments about the right technical solution. Document reviews were heated affairs. Code reviews were heated affairs too. Frequent turf-wars were the norm. The PM had to routinely step in and douse flames. All this in a team of 3! Of course the client knew none of this since deliveries would happen as promised. But clearly, this was not a productive atmosphere and much productive time lost. After 1 year of this story, the PM left and we had a new PM (the TDL became the new PM) and we got a new DEV with a proposal of me taking over the role of TDL. The new DEV was justifiably offended. But this time we all knew better. I proposed to scrap the role of TDL and have two DEVs take up end-to-end responsibilities. The new PM (who was the earlier TDL) took this up with the client who agreed because he now trusted the offshore team after an year of quality deliveries. The atmosphere in the team was now much better.
Actually turf-wars in an Agile team is a good topic to be discussed separately. Hopefully, I will make a post on it sometime in the future.
Other references used in this post:
- 1.The Agile manifesto
- 2.The principles of Agile software development
- Link 3, link 4, link 5, and link 6. A gentle introduction to extreme programming and team dynamics
- 7. Martin Fowler’s post on a team room
- 8. Another post, by Rajeev Singh, on open workspaces