Field Report: Mapping Project Contexts to the Right Agile Approach

My last blog presented the notion of using guiding goals to justify changes in the internal operating system of a team. Here I present the three distinct contexts of our project. These contexts are presented chronologically. I don’t mean to imply later approaches are in some way better than their predecessors. Had the pressures for change been applied in reverse I would have expected the sequence of change would have done the same. The important point is that the nature of the work changed and so we adapted to the new context rather than force the context into the preexisting model.

Context A: Remote Development

The team was within driving distance of the client. We had an embedded Business Systems Analyst who was able to mind meld with the remote Product Owner. The team had its own source code repository. We packaged code releases for deposit into the client’s source control to facilitate onsite testing and promotion of the builds.

Requirements were assumed to be similar across business units. The road map consisted of the minimum marketable features sequenced to align to each business unit’s predicted conversion date. Some refactoring was expected as each new line of business introduced its individual quirks.

The team adopted Scrum with two week iterations. Our testers were operating independent of the client’s Quality Assurance group but followed their standards. Microsoft TFS was used for tracking the sprints. The same team was responsible for page configuration and orchestrating content conversion.

Context A versus the Guiding Goals

• Transparency – Poor: Client leadership and technical SMEs felt isolated from the team despite the short drive. The interaction between the Product Owner and the embedded BSA was spectacular and offset the other negatives to some extent.
• Flexibility – Excellent: The team had the freedom to run development as they saw fit.
• Value and quality focused – Good: limited access to client technical SMEs slowed development. Adoption of continuous integration was limited due to the lack of client familiarity with tool.

Verdict: Good for the team in that this approach avoided nearly all distractions. Bad for the client in that what a team can interpret as distraction can often be a poor attempt to communicate. Although the link to the Product Owner was strong, links to other technical resources at the client had more tendrils and could not sustain the bandwidth of knowledge needed for success.

Context B: Onsite Platform Development

The move to the client site was triggered by a reevaluation at the program level aimed at determining an end date for the program to allow for yearly budgeting. The client wanted the team onsite to better be able to monitor progress. The team structure was the same as in Context A, just with no red line.

The planning horizon went from that required to release a business unit to the entire product roadmap needed to support all business units. The product was now envisioned as a set of capabilities common to all lines of business. Each capability would be implemented as a configuration driven framework which would be extended or ideally configured to suit the needs of a specific business unit.

The program level planning evolved rapidly to reflect a Lean/Agile approach in which the entire scope of capabilities were sequenced to support the intended conversion of the first business unit to leverage a given capability. The set of capabilities, page configuration and content needed to migrate a meaningful set of business units became the basis for a release. The releases contained larger more complicated business units. Higher volume justified the need to have a distinct team to develop or convert content and page configuration. This migration team, although not developing code, adopted Scrum.

The development team kept Scrum but with three week iterations. The third week helped account for the many non-Agile processes and procedures from the Quality Assurance group. The time was typically focused on the required formal manual functional testing that constituted acceptance testing in addition to defect fixing debt from prior sprints. No electronic tools were used for tracking the sprint other than a spreadsheet.

During this context, the development team grew from five developers, two tech leads and two testers to fifteen developers, six testers and three tech leads. We experimented with two Scrum Masters but eventually landed on one Scrum Master and one Agile Manager. As the development team matured, the members developed their own mode of self organization in which sub-teams formed dynamically around stories. By have a single large group, we were able to more effectively swarm around problem stories. This behavior was critical to dealing with the frameworks which had a high level of uncertainty and complexity.

Context B versus the Guiding Goals

• Transparency –Good: Client became a little too engaged at times in how the team was run but now worked with current data. The downstream migration team responsible for building out the pages was overwhelmed by the tide of change in tools and techniques coming from the development team. They struggled to provide a clear picture of their progress.
• Flexibility –Good: the team had to subject itself to restrictive and highly manual build practices for promoting code. They were able to implement some continuous integration. Some of the client’s management wanted to dictate core practices to the team without voicing a problem statement.
• Value and quality focused – Good: Access to SMEs and turnaround times on answers kept pace with the growth in team size and story throughput. The good interaction between the Product owner and the embedded BSA continued to be a highlight. More client BSAs were added to the mix with mostly positive results once they had gone through a learning curve. The migration activities that leveraged our toolset remain plagued with low quality due to lack of a well understood process together with a set of page building tools that were still immature. Out of the box Scrum did not offer any checks and balances other than to repeatedly indicate failure.

Verdict: Good for the client but a culture shock to the development team having to accommodate the multiple levels of management checking in with the team regularly. The team responded by becoming more cohesive as adversity will often do. The migration team was failing and was ready for a change.

Context C: Business Unit Conversion using a Coupled Kanban Pull Model

The development of new capabilities began to take second place as the bottleneck moved to the migration team. The development team’s turnaround tended to become more predictable and the majority of work was driven by the needs of the migration team. The development and migration team both changed their approached to Kanban, dispensing with sprints in favor of internal releases with dates driven more by the accumulation of value. The overall approach had become more of a pull model. When the organization defined the next logical business unit to migrate, it triggered the flow of a set of pages through the migration team. This in turn pulled new widgets and enhancements from the development team.

The mix of work for the development team also varied. Instead of developing just capabilities, the delivery team needed to produce new widgets in the form of business rules, content rendering macros and configurations for the highly configurable application developed during Context A and B. This sort of development fell in the value-add category as opposed to application performance opportunities and defect resolution in the failure load bucket.

The teams embedded the procedures of the Quality Assurance group as Kanban policies. It tended to slow the work down but the cadence was more measured. Quality improved by encouraging the right sorts of reviews at the most natural part of the flow. No electronic tools were used for tracking. We did not calculate cumulative flow because the redesigned board highlighted flow issues.

Context C versus the Guiding Goals

• Transparency –Excellent: The client now had front to back visibility of progress from both team. They were able to make informed decisions about the impact of changes in business strategy without interrupting the teams.
• Flexibility – Excellent: the pull model established between the teams meant the work was done only when needed. The notion of limited Work in Progress from Kanban was used to keep the right amount of work in flight allowing for daily reprioritization if needed.
• Value and quality focused – Excellent: The continuous flow of Kanban made it easier to leverage dead patches in workload to address technical debt. Policies applied to development focused on having two eyes on each deliverable be it a design, code or test cases. The migration team used policies to implement context specific checks and balances that the preceding Scrum approach had not. There was no equivalent to the XP practices of a development team. Explicit policies had filled that void. An expanded BSA team acted as knowledge managers providing a consistent view of the work customized for consumption by the two teams.

Verdict: This context had the best alignment of people, approach and type of work. Kanban didn’t make life better but Kanban was the best for this context. The throughput of page development hit the sort of velocity we had expected with around 90% pass rate of a page coming out of the migration team. Visibility of flow allowed us to spot opportunities to accept changes with the same predictability around date and delivery.

Comments

[Antonio]

Thanks for (very!) quick reply, must be because we're both in Norway/Oslo;)Some bcngkrouad info:My current project is a web application (plain war) which integrates with a database through Hibernate and is built using Maven. We have some custom maven plugins, one for the creation of the database and one for the deployment of the war to an application server (JBoss at the moment). We have created an installer using the maven-assembly-plugin which is used to setup the application in other environments like test,stage,production. The installer bundles a build.xml with a few targets to achieve the same things we do in Maven in our development environment. The home-grown utilities for creating the database and deploying to the appserver is used in all environments, from Maven in dev-env, from Ant in all other envs.I want to replace our custom utilities for database creation/migration AND deployment with some more standard things, where the DBDeploy (or c5-db-migration) could be used for the database-related stuff.Challenges:1. Database-related tasks: Is there a tool that can be utilised from both Maven and Ant to accomplish the database creation/migration? Right now it seems that DBDeploy would be the primary tool, since we can execute ant tasks from Maven. Input?2. Appserver/deployment related tasks: Currently we have a home-grown maven plugin which takes care of creating a JBoss directory structure and deploying the war file, as well as starting it in our development environment. In test/stage/production we have Ant targets in the installer which does the same. I've looked at maven-cargo-plugin and finds it interesting, since it can both download an app-server and deploy/redeploy war files to it by configuration in pom.xml. Well, I would like to have a common approach for installing/configuration/deployment of an appserver in dev-env/test/stage/prod. The installer which is deployed to the maven repo should be environmental-neutral, right?! So, will the agile-deploy facilitate my needs?

[Ochesc]

Well, my first thought would be to chnage the domain-object to represent the three fields. As you have a need to separate things, and well separating the area-code from the number would probably be smart anyway (and you would avoid primitive obsession).From what I understand you can't really chnage the domain object. If you have a PhoneNumber domain object, you can create a custom binder for all objects of type PhoneNumber and assemble three fields to one. I'm not quite sure how the binding/names of the separate fields would come into play here.Creating a separate object with all the fields and then copying it all to the domain object would be a last resort. It's the old DTO, duplicate definitions thingy all over again. When I said stay object oriented, I also said to reuse as much of the domain object as possible. So if you have to create a new object, reuse the domain object too. In a small case with just the phonenumber this is not obvious, but if you say that you are actually editing a Customer with and address a solution could be to build a CustomerForm object that references a Customer object. Then the CustomerForm could contain the specific phone1 etc. but for all other fields reference the Customer object (a JSTL reference would be something like ${form.customer.name}). This way you reuse as much of the original domain object, but add a little extra logic in the CustomerForm to accomodate the UI.