Distributed Agile Development – 1: Reinterpreting the manifesto.

This is Part 1 of an indefinite series of posts centered on the topic of distributed development and using agile methodologies in distributed teams.

Problem

One of the principles of the Agile Manifesto is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” The manifesto was put together in 2001; a long time ago by software industry standard. At that time, offshore development (the primary scenario for distributed development) was beginning to gather momentum, but most such development occurred using the traditional heavy-weight development methodologies.

Today, there is a big shift to adopt agile techniques in distributed teams. How do such teams cope with being almost totally against the spirit of one of the principles of the Agile Manifesto? This post will highlight one of the many measures taken by teams around the world to achieve the spirit behind the mentioned principle:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Solution

Here are some ideas that you can use to remove/reduce the need for face-to-face communication:

  • Use of Technology: VOIP, Webcams, Screen Sharing Software. Technology, it seems keeps advancing. While, futuristic video conferencing solutions are still beyond most organizations’ means, there are many ‘good enough’ substitutes available which make it very comfortable and give near ‘face-to-face’ experience. At work, we use a combination of Skype/Vonage, Web Cams, and GoToMeeting/Webex, to achieve this on a daily basis. There are teams who do their daily Scrums over Skype and a shared desktop.
  • Take time out to get to know the teams: My organization strongly suggests all our clients to have visits back and forth between the two teams. Usually, someone from our office visits the client’s office at least twice a year, and we also invite team members from the client’s team to our office. What this does is that it allows the team members to know each other on a personal level (something that is very hard to achieve over phones and emails). This encourages a lot more participation during the Scrum calls for example (if you have met the person on the other side).
  • Spread Cultural Awareness: It really helps to know about the people you are interacting with. It helps if the teams know a little bit about the culture of people on the other side. It avoids awkward situations during communication (for example, one of the problems faced by some of my team member is that they never know if the client is joking or not). We hold workshops, where we call-in experts to educate our teams about cross-cultural communication.

Conclusion

Although, nothing can replace a true ‘face-to-face’ conversation (yet), the true message of this principle of the agile manifesto is to eliminate the inefficiency ‘non-face-to-face’ communication: which is slow and prone to misinterpretations. But a mix of technology and best practices can definitely come very close to eliminating the inefficiencies of ‘non-face-to-face’ communication.

What are your experiences?

XP Practice: Whole Team

Whole team practice recommends including on the team people with all skills and functionalities needed for creating the product: developers, testers, designers, technical writers and especially customers. It is a known fact that in software development a lot of information is lost or misinterpreted whenever the distant handover occurs. Even if everybody is doing his best and 90% of information is handed over correctly when the request goes over 4-5 handovers from customer to analyst to architect to developer to tester the information loss already reaches about 40%.

Agile software development methods fight with this information degradation with the help of the feedback loops, by making it easy for people to clarify things and verify if they got the idea correctly. Whole team practice is an extension of this idea to the extreme level – include everybody on the team and during the iteration they will be able to collaborate in order to produce a shippable increment of the software. Such a permanent collaboration and frequent commitment to the iteration plan also helps people to actually develop a feeling of a team – a feeling of belonging together, common responsibility, a feeling of “we are in this together”.

Whole team practice does not necessarily dictate to having the same team during the whole project. While it is definitely good to have the team core stay on the project extra team members can be added on the need basis. For example, in the beginning of the project there might be a bigger need for the subject domain experts, database administrator or user interface designers.

Links

This page is a part of the Extreme Programming overview

XP Values: Feedback

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of feedback emphasizes the belief in that requirements always change and/or are not well understood in the beginning of the project. Therefore the only way to build software the customer really needs is to continuously adjust the development basing on his feedback. Same goes to the technical level. Since software production is a new product development, it is rarely possible to plan it in detail in advance. Therefore it’s best to develop in such a manner that improving the design basing on how the current one behaves was easily possible.


Primary XP practices directly supporting the value of feedback

  • Sit Together and Whole Team– evaluate the decisions quickly with the help of the hallway feedback and by simply talking to the nearby sitting tester. Having people with the different perspectives in one room helps provides the team with the multiple perspectives on all their decisions and solutions
  • Pair Programming – code reviews are known to be useful. Then let’s do them already while programming. Get the second opinion on the code right, when creating it
  • Weekly cycle – wrap up and evaluate things often
  • Ten-Minute Build and Continuous Integration – verify that all the code in the system still works in no more, than ten minutes
  • Test-First Programming – make the code explicitly tell you, when it is done
  • Incremental Design – improve your design iteratively basing on how well the previous iteration works


Corollary XP practices directly supporting the value of feedback

  • Real Customer Involvement – when anything is unclear, show the current solution to the customer and ask the him directly
  • Root Cause Analysis – find the root causes both for the positive and the negative feedback
  • Code and Test – let the code tell you if the solution still works
  • Daily Deployment – get the actual view on the deployed current solution daily
  • Pay-per-use – empower the customer by letting him pay you basing on how your software works in the real world. Money is the ultimate feedback

This page is a part of the Extreme Programming overview

Agile Development with Microsoft Solutions Framework

Microsoft Solutions Framework is a set of processes, principles, models, and best practices geared at helping developers develop software successfully. MSF is an adaptable set of guidance and best practices aimed at increasing the chances of success during the Software Development Life Cycle.

How does one leverage MSF? MSF provides the framework for any number of methodologies. It is flexible enough to admit that there is no one true methodology and thus allows for a lot of flexibility in how software processes are implemented. One of the implementations of MSF (also from Microsoft) is called the MSF for Agile Software Development (MSF4ASD). This is MSF with an agile bent on the processes prescribed.

Templates

The exact documentation for MSF4ASD is available online, but if you are using MS Team Foundation Server with Visual Studio Team System, then you are in luck. Team Foundation Server has got support for MSF templates and Microsoft provides its MSF4ASD template as a free download. What this means is that once you install this template on your Team Foundation Server, then whenever you create a new project, you can choose to base it on the Agile Template.

This automatically configures your Project workspace around Agile concepts as defined by Microsoft MSF4ASD. It automatically configures your roles, statuses, data collection fields for tasks and work items. The best thing about it is that you can customize it to your process.

Templates for other Agile methodologies are also available (though not from Microsoft). There is one for Scrum, and another for EUP. The bottom line is that if you are working on a Team Foundation Server, you have the toolset to implement Agile methodologies through templates based on MSF.

XP Values: Simplicity

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of simplicity calls for looking for the simplest working solution first and improving it later only the need arises. This value is based on the assumption that requirements and many other things in software are changing so often and are so imprecise until done that it is rarely worth to implement things supposed to be helpful at some point in the future. By that moment there are good chances that improved understanding of the subject area and solution would call for a very different approach.

Examples of applying the value of simplicity could be

  • preferring paper prototypes over the diagrams carefully charted on a PC;
  • developing one feature at a time. Whenever possible with the customer evaluating when the feature is already good enough for him;
  • preferring live conversation to the extensive emailing;
  • etc.

Primary XP practices directly supporting the value of simplicity

  • Sit Together – make it easy to use the simplest way of communication – live discussion
  • Whole Team – make it easy to reach the specialist in any relevant area
  • Informative Workspace – make it as easy to update the project status as to move a card on the wall
  • Stories – document the requirements in the simplest possible “concept-like” way and refine them together with the customer later
  • Weekly Cycle – develop in short iterations so that ready-to-use functionality would be created step by step
  • Incremental Design – simple design first, refactoring later, improvements on demand
  • Test-First Programming and Continuous Integration – with the comprehensive set of automated tests make it easy to improve the software design on demand

Corollary XP practices directly supporting the value of simplicity

  • Real Customer Involvement – there is no simpler way to refine the requirement, than to show customer what you understood and to ask for his opinion on it
  • Incremental Deployment and Daily Deployment – deliver one small step at a time

This page is a part of the Extreme Programming overview

Christopher Evatt tells how one man made his city boom


An exciting story on how a person in the deepest regret, having no faith in himself can find its predestination and joy in life by having a close look on what really motivates him, not on what he thinks motivates him.

Story is told by Christopher Evatt, who is “assisting people and organisations to find their value and create their value”

Via Jos Schuurmans

XP Values: Communication

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of communication is to explicitly state that XP teams consider sharing the status of pretty much everything being important. Even though the useless meetings are not too welcome in any methodology, in general XP teams prefer the risk of over-communicating to under-communicating.

XP teams share information often and on many levels. They use pair programming for quick knowledge transfer, collaborative workspaces with big information radiators so that everybody could see and feel the current status by just entering a room, they use daily short standup meetings for updating the whole team on the current and perceived problems, they typically have a lot of automated tests and continuous integration server to instantly share the code integrity information. Eventually XP teams strive for having the customer on site so that the team could continuously demonstrate the current software to the customer and get his feedback for figuring out what the exact requirements and priorities

What is of biggest importance is that XP teams strive for incremental tuning of their communication practices. Via a mechanism of retrospectives they can drop the sharing practices that don’t work for them, decide to try something new or amend the practice not working so well for them.

Primary XP practices directly supporting the value of communication

Corollary XP practices directly supporting the value of communication

  • Real customer involvement – for communicating what’s done and his opinion on it and on what should be done next
  • Team continuity – keep the people working well together across the course of the projects
  • Daily deployment – realize the final product status early and often

This page is a part of the Extreme Programming overview

Extreme Programming

This page is not static. Links are added to it whenever a referenced topic is published

Extreme Programming often referred to as XP is probably the most known agile software development method. It is often considered being just a catalog of good practices exploited to the “extreme” level. However, extreme programming adepts often define the method not in terms of concrete practices, but rather in terms of permanent change guided by five values, fourteen principles and a number of practices known to be good in implementing these values and principles.

XP Values: Communication, Simplicity, Feedback, Courage, Respect.
XP Principles: Humanity, Economics, Mutual benefit, Self-similarity, Improvement, Diversity, Reflection, Flow, Opportunity, Redundancy, Failure, Quality, Baby steps, Accepted responsibility.

XP Primary Practices: Sit Together, Whole Team, Informative Workspace, Energized Work, Pair Programming, Stories, Weekly Cycle, Quarterly Cycle, Slack, Ten-Minute Build, Continuous Integration, Test-First Programming, Incremental Design

XP Corollary Practices: Real Customer Involvement, Incremental Deployment, Team Continuity, Shrinking Teams, Root Cause Analysis, Shared Code, Code and Tests, Single Code Base, Daily Deployment, Negotiated Scope Contract, Pay-per-use

It is indeed so that in many software development teams the change guided by these values and principles are effectively translated into getting into use more XP traditional practices such as Pair programming, Test driven development, Continuous integration or Small releases. Still it would be against the principle of Incremental change and value of Simplicity to try adopting many practices by the team new to agile methods – the team would be overwhelmed and practices would have little chance to become useful.

Further Links

Your experience

Which other “general” starting points would you recommend for learning about XP?