This session will mirror the structure of the accompanying experience report paper. It will be driven by a power point presentation.

See this picture for the style of presentation I prefer. This picture is one of many from the white board communication sessions I used on this project.

This session should be able to reference the client and project explicitly. This is still be agreed but this particular client has previously been willing for Valtech to reference them in case studies and were in fact the subject of an experience report delivered at Agile 2008 regarding the adoption of TDD.

The material will reflect on the experiences gained over a fourteen month period after the successful agile delivery of a single, very high profile project. During this period the client tasked the technical architect to build on the successful application of agile techniques and scale up across a number of larger projects.

This particular client has a long history of document centric, process heavy, waterfall development which was failing to deliver in the fast moving world of mobile internet. One of the key challenges facing the technical architect was how to deliver on a remit which had been defined when the development process was structured around a waterfall and documentation review when the agile techniques had delivered success through empowerment of developers without document centric quality gates.

The technical architect, was very aware of these challenges and so structured the approach, recorded the outcomes and then reflected on the experience. This was done with a view to maximizing success but also to feedback what had been learned for future engagements.

The presentation and report will be structured as follows:

Introductory section

• Statement of the report objective: Document the experience of enabling agile delivery on a number of concurrent projects through the role of technical architect without retreating into the ivory tower.
• Summary of what is wrong with conventional architecture roles based on personal experience, i.e. the ivory tower. This will be based on two previous major real world projects.
• Summary of the knowledge regarding the role of technical architect collected by the agile community with references.
• Description of project context:
  • Client is international development group responsible for driving up mobile data usage through applications and content.
  • Part of one of the largest international mobile telecommunications companies in the world.
  • Successful delivery of first agile project with client in 2007.
  • Initial project had a small developer footprint.
  • Success gave confidence to client to pursue wider adoption of techniques across several projects and larger teams.

Body of report / presentation

The emphasis here is on presenting the experience and backing up arguments with artifacts and empirical evidence. This is especially so in part two where the techniques introduced better enabled this sort of reflection. Artifacts include:

Photographs of whiteboard sessions and wiki pages. Key findings from retrospectives - the feedback from team members was especially insightful. Class diagrams etc from code reviews tied in with static analysis reports to highlight the techniques in use. The diary of the technical architect.

Part one, A less successful six month period

This section will summarize a six month period in 2008 during the aftermath of the successful launch where progress was made but some worrying issues began to emerge. These related in part to the scale up and partly to a natural counter reaction to the agile process.

The section will go through

• The initial attempts to scale up.
• How the legacy processes pushed back against the agile approach in the period immediatly after launch.
• A summary of the events that indicated that something was wrong.
• A reflection on what had caused these problems using a key artifact, the project diary, which showed the delays, technical emergencies, degradation of agile practices.

Part two, redefining the approach

This section is intended to form the most useful section of the report. A number of techniques were identified from experience and published material at the start of this phase of the programme. This list of techniques was refined over time. For each of the techniques the goal, a number of artifacts and stories and the feedback from retrospectives are presented. The author then gives his conclusion of the effectiveness of the technique in the context of this programme and how it could have been better applied.

The techniques are categorized and evaluated within the report as follows:

(A full list of the techniques and the how they were evaluated is not presented here for brevity).

• Directing, e.g.
  • Presenting developers with a prioritized list of styles, techniques and patterns.
  • Stipulating certain practices, such as the use of CI, insisting that development environments be easy to build
• Communicating, e.g.
  • The various tools used to communicate including scrums and scrums of scrums. A brief summary of the protocols used, the problems encountered and benefits (from the perspective of the architect).
• Mentoring
• Auditing
  • Code reviews focused on areas of perceived complexity (artifacts include class diagrams produced during reviews and how they were used with static analysis tools to highlight issues)
  • Testing - TDD and acceptance tests are a critical part of our success and warrant a whole other session. The basic objectives and direction is documented here.
  • Analysis of CI statistics
• Reflecting At the peak of development hour long retrospectives were held at the end of each two week sprint (with multiple concurrent projects). The feedback gathered and team dynamics during these sessions was startlingly useful and forms the basis for this section.

Unexpected techniques

There were several skills that were not explicitly on the list at the beginning of the project but with reflection were key to success. This section quickly highlights the role of these soft skills which are often ignored. These include:

• Ruthless time management
• Delegation of architectural roles to key individuals
• Interviewing

Conclusions

Drawing on the evidence presented in the above sections the report draws to a close by presenting the conclusions.