Context: I just spent the last 3 months helping an architecture team adopt some of the agile practices. When I was brought over to this team, I was supposed to help them build their reputation in the organization. I was given an enormous task of making the team agile.
Forces: So where do I start? I could take the XP white book and slap all the 12 practices on them. But I knew that would certainly not work. Also, I was not sure what were the real issues from the team‘s point of view? I had heard the application teams [their customers] complain. The manager of the team had some issues he wanted to resolve. But what was the real issue?
I was starting on a new team. I had never worked with anyone on this team. Based on my experiences with previous projects, I knew I had to build trust with the team to make anything work.
So the question comes back. Where do I start?
Approach: Well, conducting a team retrospective felt like a decent option. If I could pull off the retrospective, then I could get an initial list of issues [which are really user stories for a coach] for the team. Based on this list, I could ask my customers [the team] to prioritize the issues based on what hurts them the most and fixing which issue will deliver max relief to the team.
So I conducted a team retrospective, I encouraged the team to speak. Some team members were more vocal than the rest. But we had a good discussion. At the end of it, I had my master story list or product backlog [list of issues faced by the team, which I had to help them resolve].
Though this was a good beginning, the issues were very superficial or abstract. I needed a better way to find out the real issues, a tool to do some form of root cause analysis or something like that.
So I started considering the whole team‘s activities as a set of workflows. For Ex. Upgrade to new version of software X. Or. Fix a bug in one of the architectural modules developed by them. And so forth. Thinking of the system as a graph [workflow], gave me some insights into what could be their potential bottlenecks in terms of process and people.
Solution: Soon I found myself applying Theory of Constraints [TOC] to find the process/people bottleneck in the system. Subsequently, I would discuss this with the team and see what they think can fix the problem. I was consciously trying not to push for certain practices. I wanted the team to own the practices. I could help them figuring it out, but I did not want the one screaming my head off about certain process that did not make any sense to any one.
This is what I call “Just-In-Time practice”. Figure out the problem at hand; pick up a practice that can address the problem in the simplest possible way. You have to carefully craft out the version of the practice that would give you the fastest feedback. In other words, set up the practice so that if it fails, it fails fast.
Example: The team had issues getting a stable release out of door at the end of the sprint. There were lots of last minute surprises to be handled.
After considering the integration process of the team, it was apparent that people were not checking in frequently and it resulted in integration nightmare at the end. So clearly the bottleneck was integration. And Continuous integration was the obvious answer.
But for the real “continuous integration” to work, you need an automated build process; you need all those mighty build servers set up running a full suite of automated tests and so forth.
What is the simplest possible thing that could possibly work?
Manual integration on developers machines before checking in. Relatively easier to achieve.
Once you have manual integration working. If you apply TOC to this workflow, you will find that the manual step on developer‘s machine can be a real bottleneck. Developers might forget checking in some files. Or they might forget running all the tests [mostly manual at this stage] or a zillion other reasons.
The next simplest thing that can possibly work is, have an independent build machine, which can just compile all the code and make sure it does not fail at that step. So now you have automated build working.
Repeatedly applying TOC to this process chain can eventually lead you to the real continuous integration in baby steps. Each step owned by the team.
Conclusion: This way you can apply TOC to identify the issue at hand and then use Just-In-Time practice to address the issue.
I would be interested to hear other people‘s experiences with coaching teams.