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.