Group Coherence for Project Teams - Practice for Continuous Improvement

One of the principles in the Agile Manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This principle guides both aspiring and seasoned Agile teams in the pursuit of continuous improvement and can support whatever Agile adoption path an organization may choose. Kent Beck adds observations about this topic.
"'Continuous' improvement is a bit of a misnomer. It means continuous awareness, responsiveness to feedback, and openness to improvement. When you know how to improve, then you improve. You make a change; observe the effects; then digest the change, turning it into a solid habit. Eventually you hit a plateau from which you can absorb more feedback and identify the next opportunity." (Beck & Andres 2005, p141)Extreme Programming Explained: Embrace ChangeAddison-Wesley Boston MAThis quote describes a process that we recognize as Practice, defined in our previous article, Group Coherence for Project Teams - Common Purpose, as "The ability to identify difference and learn through attentive repetition, either for individuals or groups... Through Practice we can get a feel for the contextual application of knowledge, rather than the acquisition of individual techniques." Practice, an ingredient of Group Coherence, is the only ingredient that the research group found to be connected to every other ingredient. Beck refers to continuous improvement in the context of an individual's learning process. "Change myself, then offer the fruits of that change to others." (p141) Practice is a process through which groups can also learn and change.
Although individuals contribute to the features developed by a project team, the product of their work (the features themselves) does not belong to an individual, but is the product of the entire group. Just as the music produced by a jazz ensemble includes the individual improvisations of each member, the music belongs to the group. To whom does the technical debt and code quality in software systems belong? Why do some environments not take advantage of the opportunity for iteration provided by Agile methods to turn releases into non-events?We propose that items such as code quality, technical debt and release cycles have tacit ownership at the group level. This is unconscious, as group ownership is often minimally recognized in organizations. These unacknowledged group items are vulnerable to decisions and prioritization made by individuals without the group's voice, at the expense of the opportunity for the group to learn. Untapped group learning can be brought to awareness through group Practice thus supporting the pursuit of continuous improvement in these often challenging areas.Challenges - Release ProcessLarge organizations are prone to centralize their release process in an attempt to protect their live systems from rogue updates, or their customers from a greater pace of change than they can absorb. A common implementation of this protection is to use an additional team for production releases independent of the development team. In reality the development team is invariably called in to resolve issues that surface during the release process. This illustrates tacit ownership of the release process that belongs to both release and project teams. The whole-group ownership of the release is not acknowledged. The resulting integration feedback loop is late, long and cumbersome and releases are big events involving multiple departments and stressful interactions with long hours.In environments where a centralized release process is assumed to be the constraint and not up for discussion, Agile is stunted in its ability to provide continuous Practice in the software delivery. A common reason to avoid the process conversation is the excuse that "our complex business needs such a process." However, by not allowing Agile teams to release to production early and often, we prevent the Practice that would allow them to turn the release process into a non-event. Challenges - Technical DebtThe centralized release process implementation can result in development and test environments with limited ability to test performance, integration, code coverage or product usability. This forces a lot of critical testing to be done during the release rather than the development process. The project team's best efforts to deliver a "safe" and tested feature set become little more than guesses. The developers have to attempt all their testing in the System Test environment. This is like developing blind as this environment lacks the connections to the system's external integrations.The project team's group product consists of all the features and all the tests. Centralizing the release process fragments group ownership. Developers focus on unit and system tests and don't have access to accomplish the full set of critical tests. The release team can focus on the tests the developers can't execute but release engineers do not have access to the code. The result surfaces technical debt that neither team is empowered to own. When responsibilities for the group product are fragmented, no whole group exists to own that product. Practice by the whole ownership group could improve both the release process and catch technical debt earlier.Challenges - Code QualityCustomers and product owners may press the project team for a wide feature set and an aggressive delivery date. This can compromise code quality, causing the developers to express concern. The two groups might have a different interpretation of the Agile principle for "minimizing the work not done". Customers might think that refactoring is unnecessary waste since this effort results in no visible changes to the application. They often challenge the value of what they might describe as "writing the code twice". However, once a feature is implemented, an Agile development team refactors the code to make it more efficient to run, cheaper to maintain and easier to extend. So who does the code quality belong to? The customers are paying for the work but the developers have a fiduciary duty to ensure that the customer receives maximized value. The code quality is part of the whole-group product. This disagreement shows that in this case the true communication never happened. The need is to resolve the disagreement and create collaboration.Code quality is built into the software over time. If the opportunity for collaboration is limited to the final stages of release preparation, the ability to identify deficiencies in code quality is also limited. An occasional look at the system does not provide the opportunity to develop trust, align goals and expectations, and learn to communicate effectively as a team. Practice to Enable Whole-Group OwnershipWe would like to share our personal experience of one way in which we have turned the tacit group ownership of release process, technical debt and code quality into a conscious seamless part of the day-to-day interactions of a whole project team. In a financial risk management system like the one in this example, projects waited until a complete financial model was implemented in C. Once the traders validated this model, the developers could begin to extend their risk management system to use it. After this software development was complete, operations and support processes could be created. These sequential handoffs were an established project life cycle.When market conditions suddenly invalidated an existing financial model, a business need arose to extend the risk management system considerably without knowing what replacement model to use. Using an invalid model put traders at great financial risk and under considerable stress to manually adjust every quoted price. This was a crisis that could not wait for a sequence of handoffs over the next 12-18 months.Instead, by initiating communication with all the stakeholder groups simultaneously, it became clear that each had a part of the process and also a part of the solution. To make the communication among the stakeholders both practical and concrete, developers created sandbox versions of production for each conversation among traders, financial modelers, trading administrators and support engineers. The increased level and quality of communication led to the realization that the whole group owned the system.Implementing the sandboxes removed the handoffs and enabled the participation of the whole team throughout the project. The whole group was able to take ownership of the technical debt, code quality and release process, since each of these sandboxes made these items visible to everyone involved. Most sandboxes were set to refresh their database daily from the live system, and would be extended with all the daily code changes from the development system as well. In addition, the financial modelers were evolving multiple analytic libraries, and the latest versions of their work were also applied to the sandboxes on a daily basis.Traders and their administrative staff picked up any drop in code quality on the part of either the developers or the financial modelers immediately. Any technical debt that impacted the usability of the system or the daily generation of risk or profit and loss figures was also picked up immediately. Degradation in the computational performance of the application was obvious to everyone straight away. And of course, the release process was being tested on each sandbox every day. An Environment for Group LearningThe previous example illustrates how software development can be a group learning process. This solution allowed for both Practice by the entire group and also for continuous improvement in several areas. For example, the financial modelers were able to share each other's work and thus were able to explore four or five times the normal number of candidate models to develop a solution, with each cycle of modeling providing input for continuous improvement. The traders were able to test numerous hypotheses about the market parameters that would influence the new models, thereby contributing improvement to their business model and trading strategy.Given the crisis, the stakeholders were willing to do away with the traditional handoffs, include all the participants and create a shared sense of common purpose. This holistic project interaction initiated group Practice in which self-organization and group learning spontaneously emerged. When somebody suggested something that the group could do, the group provided a way for them to try it, improving the group's environment with each cycle. Eventually, the group was able to create its ideal environment for continuous improvement. This environment was the result of acknowledging the previously tacit group ownership of the risk management system. The Practice allowed a new self-organization to emerge. ConclusionWhen everyone is able to see and experience the progress made throughout the development process, they will offer and receive feedback without being solicited or prepared. This open group exchange is one result of Practice. To guide a collection of Agile practitioners and their project stakeholders towards Group Coherence, it is important to provide opportunities for the group to Practice ‘being a group'.Without ‘being a group' the team has no access to the tacit knowledge. Once it accesses its shared understanding, the team develops a knack for group learning. Group learning is necessary for a team to embrace suggested improvements. Continuous improvement depends on group learning provided through Practice.Guiding a group from Practice to continuous improvement can allow practical results in such challenging areas as code quality and technical debt and can make releases so frequent, tested and drama-free that they become invisible.


Ref: http://www.agilejournal.com/articles/17-articles/1742-group-coherence-for-project-teams-practice-for-continuous-improvement

Agile Methods and Virtual Distributed Teams

By Dr. David F. Rico, PMP, CSM

Are Agile Methods and virtual distributed teams compatible? Aren't Agile Methods and virtual distributed teams polar opposites? Aren't they incompatible? And, if they are compatible, what are the specific techniques for making Agile Methods work for virtual distributed teams?
What does all of this mean? What is this controversy surrounding Agile Methods and virtual distributed teams? Why wouldn't Agile Methods be compatible with virtual distributed teams?
Well, all of this is related to the principles and values of Agile Methods as defined by the Agile Manifesto (http://www.agilemanifesto.org/). The sixth of 12 major principles is as follows, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It relates to two of the four major values of Agile Methods: (1) individuals and interactions and (2) customer collaboration. So, taken at face-value, no pun intended, one would be omitting half or 50% of the values of Agile Methods if one didn't use face-to-face conversations with customers and team members. Or, would they?
Face-to-face communication is contextually-rich, and is the preferred method of communication in Agile Methods. In Traditional Methods, statements-of-work, requests for proposals, contracts, requirements, and designs are considered contextually rich. But, nothing beats good old face-to-face communication when it comes to interacting with customers and team members. The creators of Agile Methods realized this and etched face-to-face communication in stone as one of their 12 commandments.
Okay, now, so anyone who can read a book on Agile Methods knows that face-to-face practices are mandatory. That is, anyone except those who are trying to make money in the global software industry. The global software industry is all about connecting or automating the supply chain of goods and services using products from China, computer programming labor from India, project managers from North America, and researchers in Europe. Well, that's simple, just co-locate everyone. Not so fast, why can't everyone stay exactly where they are and use electronic means to communicate? Well, that would involve violating the principles and values of Agile Methods, wouldn't it? In fact, if a team is not face-to-face, it's using Traditional Methods, not Agile Methods. Or, is it?
The creators of Agile Methods had part of the equation correct. Face-to-face communication is contextually rich, and is therefore superior to virtual distributed communication or software documentation in certain circumstances. However, the North American creators of Agile Methods failed to anticipate or acknowledge that 95% of the world wasn't collocated with them, and that North America wasn't even the predominant computer programming market. Didn't they heed the warnings of Ed Yourdon who said that the Indian software market was skyrocketing or how about Michael Cusumano's warning that Japan's Software Factories were taking over the planet? Perhaps they were caught up in the euphoria of Microsoft's and Intel's instant success in the 1990s. Or, the Internet Gold Rush convinced them that North American information technology dominance was here to stay?
I think the only ones who didn't believe the creators of Agile Methods were the 70 or so other countries besides the United States, who benefited from the Personal Computer and Internet revolution as well (along with any enterprising capitalist who wanted to make a quick-buck interconnecting the global supply chain).
The problem is that 99% of the population who knows anything about Agile Methods believes that one isn't being Agile if one isn't using face-to-face communication and all of the associated trappings (e.g., onsite customers, pair programmers, daily standup meetings, etc.).
Well, hang on to your seats, because the world is changing as we speak, and virtual distributed teams for Agile Methods are here to stay. We all have the benefit of being on the leading edge of this phenomenon as part of the next phase of software engineering evolution. I bet most people who are delving into Agile Methods didn't even realize they were on the cutting-edge of software engineering when they endeavored to use Agile Methods? Let's take a look at some of the evidence.
The folks at British Telecom have devised a set of practices for making Agile Methods work with virtual distributed teams (Cannizzo, Marcionetti, & Moser, 2008). They've identified four major practices to help marry Agile Methods with virtual distributed teams: (1) maximize project status visibility to all stakeholders, (2) ruthlessly automate as many development and management processes as possible, (3) ensure effective communications to the maximum extent possible, and (4) provide immediate feedback on every task performed. They use Eclipse IDE for writing code, Fitnesse and Selenium for acceptance testing, CruiseControl with Ant as a build tool, Danube ScrumWorks for user stories, Subversion for version control, and Atlassian Confluence Wiki for document sharing. Other tools include Visual Studio, NetBeans, Capistrano, Live Meeting, Communicator, Meet Me, and a variety of team building tools.
The folks at Yahoo! (Drummond & Unson, 2008) suggest mandatory meetings within time zones, periodic face-to-face meetings across time zones, overlapping virtual distributed meetings where possible, periodic synchronization between international Scrum Masters, the use of Wikis to share photographs of user stories on Post It notes, and ensuring that virtual distributed teams maintain the rank-ordering or priority of user stories. Furthermore, Yahoo! says to emphasize individuals and interactions over processes and tools as much as humanly possible, factor in the needs of the global workforce over individual practices of Agile Methods, and ensure that accurate information is shared in a timely fashion.
The folks in Canada (Robarts, 2008) say to have periodic face-to-face meetings as much as possible (especially during project kickoff), periodically send people back and forth from one country or location to another, ensure domain experts periodically visit one another, ensure delivery teams occasionally visit one another face-to-face, hold virtual distributed daily standup meetings between people in the same time zone, exchange informal notes such as PowerPoint presentations as meeting minutes, and ensure Wikis and other automated tool content is constantly up-to-date. The Canadians remind us to emphasize the use of Agile Methods practices like User Stories (instead of specifications), use video conferences as much as possible, and use portable information technologies such as laptops, cell phones, and personal digital assistants (e.g., BlackBerries). More importantly, proper schedule management is of utmost importance, especially when it comes to building in management reserve, accounting for international Holidays and unplanned events, and keeping the schedules current as well as communicating them. Interestingly enough, we're advised to allow enough latitude for differences in individual Agile Method practices across international boundaries.
The list goes on and on, as the Indians recommend automated dashboards and wikis (Shrinivasavadhani & Panicker, 2008). The Americans emphasize WebEx Meetings, periodic virtual distributed meetings between international Scrum Masters, and a variety of techniques such as balancing power, allowing for variation in practices, detailed User Stories, empowerment, sharing vision statements, executive commitment, and as much communication as possible (Therrien, 2008). Another Canadian team says to use nearshore resources, maintain strict communication plans, share electronic workspaces, use synchronous communications only in adjacent time zones, and use asynchronous retrospectives (Vax & Michaud, 2008). Finally, a group of Americans and Canadians recommend instant messaging, synchronous communication mechanisms, video conferencing, face-to-face virtual distributed meetings, virtual distributed standup meetings, and the list goes on and on (Young & Terashima, 2008). You don't want to skip this last paper, because it contained a lot of helpful advice.
So, what's the bottom line? The creators of Agile Methods had it right, face-to-face communication is contextually rich and face-to-face is the preferred method of communication. And, a lot of face-to-face communication is a key, if not the key, to project success. I speak from experience on this one, because one of the most difficult projects I've ever managed, was success due to frequent, unscheduled face-to-face communication to break down the barriers to personal trust. Once the barriers to trust had been breached through frequent personal interaction, then the project completed successfully. We were given an award by a customer who had never given an award to a consulting firm before. You just don't find that kind of advice in your typical textbook on Traditional Methods. So, how do we duplicate the benefits of face-to-face interaction in virtual distributed teams? Communicate, frequently and often! Outside of video teleconferencing, telephone calls have been one of the best forms of communication over the last century. It's the "unscheduled" telephone calls that provide the most return-on-investment (versus regularly scheduled telephone calls that just don’t seem to have the same effects). Ad hoc telephone calls help alleviate anxiety instantly, as opposed to scheduled phone calls. Intimate, personal communications break down barriers to trust and ensure project success almost every time.

REFERENCES

Cannizzo, F., Marcionetti, G., & Moser, P. (2008). Evolution of the tools and practices of a large distributed agile team. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 513-518.

Drummond, B. S., & Unson, J. F. (2008). Yahoo distributed agile: Notes from the world over. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 315-321.

Robarts, J. M. (2008). Practical considerations for distributed agile projects. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 327-332.

Shrinivasavadhani, J., & Panicker, V. (2008). Remote mentoring a distributed agile team. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 322-326.

Therrien, E. (2008). Overcoming the challenges of building a distributed agile organization. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 368-372.

Vax, M., & Michaud, S. (2008). Distributed agile: Growing a practice together. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 310-314.

Young, C., & Terashima, H. (2008). How did we adapt agile processes to our distributed development? Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 304-309.