Agile in the trenches (Part 1)

As part of my research on how Agile Methodologies can interface with Service-Oriented Architecture, I am working with a client performing a 2 week iteration. The iteration is focusing on automating a process via a Service Composition. The goal of the iteration is for an architect to provide a reference implementation for a development team. The development team will then use the reference implementation as the basis for the final service composition.

The reference implementation employs design patterns for version identification, process abstraction/centralization as well as design standards and industry standards. This implementation reduces the requirements on the development team to create the entire service composition and more on modification of a framework. The overall idea of having architecture teams support development teams came about in discussions with Kevin Davis. We discussed how the enterprise architecture team could become a much more effective participant in development cycles by performing co-development.

During execution of the architecture iteration the following was performed to keep the development team/architecture team interactions simple and concise:

1) Stand up meetings are replaced with email stand up meetings. The customer is the development team and to reduce the impact on this team, a simple summary of the current tasks and blocking issues are identified. The development team manager is responsible for getting blocking issues resolved.

2) An iteration planning meeting still occurs in this model to identify the user story(s) and development tasks. These are then entered into a Agile Management Tool for tracking and visibility.

3) A retrospection meeting occurs to demonstrate the user story solution and delivery results for the identified development tasks. As part of the delivery, a step by step documentation set is provided to help the development team utilize the reference framework.

This same process is being executed by other Architecture team members for future features/technology required by other development teams. The execution of these iterations is meant to help validate/alter the process towards a consistent delivery approach.