The outcome of the initial sense-making workshop highlighted what in essence, is a longer term vision and strategy for the team, and could be used to establish the goals for this particular team (check out an earlier post on Agile goals). The workshop has indeed left the management team a little nervous about jumping straight in and tackling the BHAGs (Big Hairy Audacious Goals), and felt that we should instead start addressing potential low-hanging fruit first. Of course, this is a natural reaction to change, but not entirely unreasonable. Recall the scorecard assessment shown on the left.
To jump in an solve the "Efficiency of Team Structure" problem is bound to be quite disruptive, especially when the teams have just started experimenting with some internal improvements on their own. Added to that, the department structure that's currently in place, doesn't lend itself well to having fully cross-functional teams. Added to that, some department managers have yet to settle between themselves the expectations & services provided by each area. We can clearly see how going agile puts pressure on traditional segmentation of departments by role, e.g. Development vs Systems Integration vs QA, etc.
Personally I've been advocating for a single, unified, cross-functional team approach for some time, but have faced the classic resistance from managers because its new territory, not really been done before, alarm bells ringing. This hasn't been made easier by the surprising rapid increase in headcount and growth of all the departments, dealing with multiple projects and platforms, that the guys just didn't have time to sit back, and discuss overall strategy & direction for each service area.
We continued to plough ahead, this time, going back directly to the foot soldiers in all teams, where each manager was asked to hold internal team retrospectives, addressing these three questions:
- What are your current top, pain-in-the-ass issues, your most frustrating bug-bear?
- What do you think the Root Causes are?
- What would be a potential solution to the problem?
The low-hanging fruit that came out from this: Improvements in Pre-Planning, Improving Control in SI (System Integration). Interestingly, these areas map nicely into the scorecard assessment that encapsulates the eventual goals, covering: Quality of Planning and Level of Control, no surprises there.
As the neutral facilitator, who's run a few of these workshops over the last year, the following is quite evident:
- Different perceptions & understanding what's required from an Agile Project, including misplaced assumptions
- Lack of clarity about the department's new structures, understanding the difference between Development, Delivery including quality
- Clash of expectations (where does agile fit in, when to switch to traditional SI model, etc.)
- Sentiment of lethargy or inaction - most of the improvement actions have been identified before, but no-one has had time, or had taken ownership of driving the improvement, no follow-through
- Bigger people, softer issues around team camaraderie
|Above & Below: Outputs from the session|