AgileMalta

Remote Agile

Filed under: Remote — Dave Sammut @ 12:15 pm

Certain themes become cardinal rules after getting through a year long agile project working on a proprietary framework from within a near-shore development team.

As happens with many lessons learned, there are weaknesses exposed and praise for what worked well. As also happens with lessons learned, much of these are forgotten or simply not put into action during the next endeavor. So here are some key points, cardinal rules if you will, and awareness of potential pitfalls awaiting a remotely located development team - Dave Sammut.

“No Surprises” - Radiohead

The importance of regular code reviews which include pattern usage, best practices, performance and stability. This could possibly include participation of a non-team member to participate during the sprint to audit code and provide feedback back into the team during the stabilizing period.

Pattern Usage - The use of standardized techniques to perform both application specific logic (business logic) and pluming (retrieving data, URL creation) processing.

Best Practices - Javadoc, formatting, common java best practices

Performance - Policy counts, performance analysis which feeds back into application specific (business logic) patterns used. Perhaps an IA/BA review needed

Stability – Unit test coverage, Integration test coverage based on user stories

“I believe the children are our future Teach them well and let them lead the way” - Whitney Houston

In any discipline, be it technical, BA, IA or testing it takes an individual with the right attitude and approach to ensure quality and success (knowing what to deliver) upon which management would like to model new people entering a similar role. The problem is what when a new individual enters the role, new attitudes and approaches (including new good and bad habits) are introduced which at times are not part of the ‘modeling’ result management desired. However, without diluting an individual’s personality, a suite of cardinal rules (a manifesto even) should be communicated to ensure that no matter what good or bad habits are introduced, the core basics which define success are ALWAYS adhered to. Failure to do so simply reflects an ill placed individual in a particular role.

“A wicked messenger falleth into mischief: but a faithful ambassador is health.” – The Bible

At each location daily communication is paramount to resolving issues and to gain further insight into the domain, which is then reflected in the code-base, an updated IA or business rule. This will then need to be communicated to the testing team to ensure verification integrity. Further insight into the domain is achieved when concise and efficient communication, through the use of a common vocabulary, proper tools and domain diagrams, is exercised.

Communication across geographically separate locations presents increased risks of miscommunication. When ill communicated (misinformation) solutions are implemented (code, IA, BA) the actual results of the ill communicated solutions will surface at a later date when the issue in question is no longer fresh in all the participants’ heads.

To minimize the risk of miscommunication, an ‘ambassador’ at each location should be responsible for the quality of communication, through the use of appropriate tools (IM, phone, WebX), discipline in communication (common vocabulary) and with the help of visual aids (domain diagrams) to further drive an idea home. It’s not that only one person is involved in all communication, rather the ambassador should be aware of the big picture and be able to assist team members be good communicators.

“Necessity is the mother of all invention” - Thorstein Veblen

From the moment an idea is endorsed and selected as a user story the detailed definition is produced. This includes everything a development team needs to successfully implement a user story; design, IA, BA, user cases and test cases. Some user stories require a great deal of detail depending on its nature, others require very little definition at all, or at least very little of a particular artifact. The idea is to have ‘enough’ information for the successful development of the user story. However, should further insight be required, other artifacts can indeed be created to explain the further insight needed. Using a guideline as to what is indeed ‘enough’ and further artifacts delivered upon request minimizes the amount of decay and unused efforts. Once again, depending on the nature of the user story, the teams should agree to what degree is indeed acceptable amount of information. Failure to understand what “sufficient information” is can lead the design effort to resemble that of RUP with a heavy up-front design phase.

“I see dead people.” - Cole Sear (6^th Sense)

The importance of communication amongst team members and in artifacts is a paramount theme when working in geographically separated locations. Without the luxury of face-to-face communication that benefits from being within an earshot or ‘around the corner’, team members must turn to alternative ways to efficiently and accurately communicate with each other.

With face-to-face communication the talker and the listener benefit from gestures, white boards (physical and air), body language and instance acknowledgment of statements, ideas and arguments. When separated, team members need to heighten their other senses to ensure that they make up for the lack of face-to-face communication. Team members need to be made aware of what tools are available and how to effectively communicate across these channels. These channels require that communication etiquette be adhered to minimize frustration and promote such tools.

“Surround yourself with the best people you can find, delegate authority, and don’t interfere as long as the policy you’ve decided upon is being carried out.” - Ronald Reagan

It’s impossible or very tiresome exercise to micromanage every deliverable of every team member. Each team contains different tasks, different skill-sets, different people with different ambitions with whom all tasks must be addressed. Each team member can indeed be strategically positioned to exploit their skill-set and can be used to attain new skills from different members performing different tasks. The art of cross-pollination ensures that no one person holds the information by which in their absence the team is presented with an impediment. This coupled with strategically positioning team members in roles which exploit their skills will create a well-balanced team and a skill-building team culture.

“Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi

On the whole the project is seen a one team divided into separate sub-teams which are all required to deliver artifacts (deliverables). Each team in this configuration can also be divided into other sub-teams. So, essentially there are two configurations which need to be addressed to minimize risks such as miscommunication and poor quality of work.

The two sub-team configurations:

1. Co-located
2. Distributed

Co-located sub-team

Co-located teams benefit from ease of communication amongst themselves to collaboratively produce their deliverables. The challenge such a team has is that of producing deliverables which concisely communicate sufficient information for other teams to use to fulfill the production of their deliverables. The risks the team has to deal with are indeed producing ‘just enough’ of information for other teams. Should another team require further insight, this request should be handled by the co-located team and addition information supplied to address any shortage of information. Basic rule is to know what exactly to deliver by adhering to a set of cardinal rules/guidelines.

Distributed sub-team

Distributed sub-teams have the same responsibilities as co-located teams with the additional challenge of team members located at separate locations. This adds additional risks of miscommunication of ideas finding their way into the final product thus resulting in a deliverable of poor quality. Such teams must establish efficient means of internal communication and an appropriate quality assurance measures.

No matter the configuration of a team, miscommunication (resulting in poor quality deliverables) can find its way into any facet of the deliverable. The only difference is that the less importance given to communication in either team will have different severity levels of repercussions.

Team Audits

Each team, regardless of discipline should be subject to regular audits on all deliverables from the different target audiences to ensure that the deliverable does indeed sufficiently communication clearly to all related parties. With additional efforts given to inspecting the quality of deliverables prior to their ‘sending off’ catch any potential issues before the producing team deems the deliverable to be ‘done’.