Optimize (Globaly!)

At this moment we have 4 Agile teams in different levels of maturity. These teams are working on 2 parallel releases. With almost all engineers “accounted for” we saw challenges with triaging smaller projects that do not “fit” the overall theme PO is driving with the Scrum team for the nearest release. These include internal Engineering projects, hot support issues, customer commits, etc. In pre-Agile world the decision was mainly driven by skill set appropriate for the project and the priority of that project relative to other projects. There is no reason why it would be different in Agile, but for some reason it became more difficult to apply the same criteria for decision making. My take on this is before we thought we are making the right calls as far as priority goes, while now we are forced (by Agile process) to have the honest discussion on cross-team priorities and figure out which team takes a hit.

One of the cybernetics principles (that I learned about from Jurgen Apello’s book “Management 3.0”) states that optimizing the outcome for a subsystem will in general not optimize the outcome for the system as a whole. I think this is one of the challenges with Agile transformation: keeping the global optimum in mind while planning the work for the multiple teams. Both Engineering Management and Product Management need to keep the entire picture in mind rather than focusing on themes worked by individual teams. This approach will undoubtedly force discussions with painful decisions, but this is Agile living to it's promise: shining the light on problems in the organization.. It's up to you whether to fix the prioritization and decision making process or not.

Knowing the path

In “Made to Stick” Chip & Dan Heath talk about “The Curse of Knowledge” as a term used to describe a situation where a person has a lot of knowledge on a subject, but has difficulty to assimilate it among his peers, or coachees. In “The Matrix” Morpheus and Neo exhibit classic coach – coachee relationship, where Morpheus asks the right questions at right times helping Neo to discover the answers instead of giving them out. During the past 2 years, and especially during last 3 months since the Agile pilot start I have experienced “The Curse of Knowledge” first hand and I saw how difficult it is to hold my tongue when the answer is obvious to me. I didn’t succeed to hold my tongue all the time and it was evident that when I did – the answers took longer to surface, but the effect was great: the sense of ownership and commitment from the group was much higher. It really seems easier that it is… I’m seeing every day my colleagues, whom I would define as excellent coaches, struggling with holding the tongue and rushing to give the answers right away.

With Agile mantra of self-organization, where managers “give-up” the decision making power delegating it to the team, the requirement for this new behavior becomes more evident and we all start paying more attention to the decision making process in the Engineering organization.
Here is an example. In the last sprint we had 3 user stories being worked on. At the sprint planning I have mentioned that the way to attack these 3 stories is one by one and not to work on all 3 at the same time (to the degree possible with all the constraints and dependencies). This idea seemed redundant and everyone was sure that if they work in the priority order of their tasks this will be achieved automatically. Few days before the sprint end the team has realized that none of the stories is likely to make it. This time, instead of bringing this idea up again, I asked few questions that have leped the team to come to this idea themselves. One team member suggested to abandoning the bigger story that had no chance in getting done in favor of other two stories that could be completed with the team effort. Another team member suggested next time the team attacks one story at a time – and this seemed reasonable. Eventually, we’ve attacked the last two stories with  as real team effort and got them accepted in time. I could have said “I told you so!”, but this of course would be counterproductive. When the team has come to this realization by themselves they felt ownership of this idea and were committed to try it again in the next sprint.