An Agile Team in Flux
An Agile Team in Flux
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
In late 2008, ThoughtWorks was called in to remove legacy systems and initiate an Agile cultural shift for a large international communications firm. Sharlene McKinnon, who was part of the ThoughtWorks SOA team, had much to say about her experiences:
"Inexperience, bad behaviors, vague program direction," were the main problems McKinnon said. "In the midst of all this growth they had developed a large and inflexible legacy system that was compiled of vendor products, mis-matched technology, custom development, legacy code, and issues that could no longer be solved within the organization itself. This was a mission critical situation if they wanted to continue as a major player in communications."
ThoughtWorks brought in senior architects and experienced SOA developers along with experts in Business Capability Modeling (BCM). There were around 200 people on the project. The goal was to use BCM to define business boundaries, make teams that presided over business functionality, use SOA services for communication across boundaries, and replace the legacy systems.
ThoughtWorks broke its people up into roughly a dozen teams, each one with a business capability assignment (e.g. product team, order team, etc.). The SOA team was the keystone of the whole process. They were tasked with defining business capabilities and converting existing systems to SOA. One of the problems the team ran into was the shuffling of team members who were being pulled out to work on other pressing issues for other teams.
This constantly changing, unstable environment is what McKinnon calls "flux". The program itself was in flux because of the shifting path for development due to a lack of program level guidance. "We recognized that innovation is rather nebulous and that in the world of software development things change," McKinnon said. With people scattered over several countries failing to communicate, due to some resistance on the part of the clients, the program was in a chaotic state. ThoughtWorks' strategy was to expose flux. McKinnon explains that the term "expose" is used because the team only had collaborative influence.
Challenges exposing SOA team Flux
- No cross team collaboration on stories
- Misconceptions over how much time team members could contribute to other projects
- Difficulty seeing relationships between teams
The SOA team's first idea was to create a new iteration board. They reworked their iteration board in a way that allowed them to keep track of who was working with what team on a given day. Here is what the board showed:
- Where people's time was going
- How much time could be devoted to the development of other teams
- More collaboration was needed between teams
Challenges exposing Flux at the Program Level
- Mistrust towards Agile - changes happening too fast
- Non-existent cross team collaboration
- Lack of program level support and guidance
- Bad behaviors
Again, the SOA team used a mapping technique where interactions were recorded on a wall of notes. The map had high level business capabilities on the left and smaller, intricate tasks on the right. Cards moved from left to right down the board and teams identified areas of interdependency. The map clearly showed that teams could not function as isolated "silos" in order to be productive.
Example of an iteration board
Early on, only three teams truly adopted the agile strategies and as a result, they became the most efficient teams. They produced sound, production ready code on a consistent basis. Teams that had friction with the SOA teams had violent reactions. "I can't think of any other way to describe what happened other than likening the reaction to a volcano letting off steam," McKinnon explains. It made the client firm realize how badly the change was needed and eventually, through more interaction, the SOA team was able to tear down many of the "silos" around teams.
In early 2009 the program was restructured and the number of personnel on the project was cut in half. The SOA team grew into three teams that were called "the Integration." The Integration found that they became more successful when they stopped thinking of themselves as a team and starting thinking about integration as a role. After the restructuring, much of the heavy lifting had been done and the company had pulled through the flux.
Opinions expressed by DZone contributors are their own.