A few weeks ago, Kevin Rutherford and I ran a session at the Agile Manchester conference called “Agile: it’s not just about the development team“. In many businesses the perception is often that the development team is the bottleneck and that if only they could go faster then more customer value would be delivered and the business would be more successful (this is probably a fallacy in more cases than businesses would like to admit as the development team is often being asked to churn its way through a fixed backlog with little or no measurement of whether any part of that functionality delivers customer value, but that’s another story).

The Workshop

The session explored the potential impacts of shifting the perceived bottleneck away from the development team. As the description says:

“Many businesses perceive software development as a blocker. If only the development team could work faster and deliver software at the rate imagined by the wider business. However, what if their dreams came true? Imagine you had a development team that could deliver working software into production every hour. What would that mean for your business? Would your business be able to cope with it and what’s more, would it be able to capitalise on it?

This workshop will explore the challenges that can occur when the perceived development bottleneck is removed. Kanban tells us when you remove one bottleneck this exposes others, so which ones would become apparent in your business? Will the new bottleneck be product management, sales, support or another part of the wider business? What problems would be exposed in those areas and how could these be addressed? Are these issues actually impacting your business currently? When all these things are considered, you may question whether development is actually your most pressing bottleneck.”

Participants worked in small groups. Each group was asked to take on a role in the organisation and asked what they thought the impact would be of this newly accelerated development capability. The groups exchanged thoughts and ideas, built them into a coherent viewpoint and presented them back to the wider workshop. The participants were split about 50/50 between hands-on developers and others involved in wider software development roles.

We ran a dress rehearsal of the session at Advanced Legal a couple of weeks previously (more of this in another blog post) and it was interesting to see the similarities in the outputs from the group work.

The Outputs

The main benefits of a workshop of this form are in the discussions between the participants in their groups and when discussing the outputs as they are presented back to the whole workshop. However, there are a few themes that can be pulled out of the gallery below which shows the posters created by the 6 different groups.

One thing to note is that part of the context we gave to the groups was that the application is delivered via the cloud. This gave them the option of continuous delivery directly to their customer base in order to maximise the impact of the newly-accelerated development team.

The main observation is that many people in the organisation would need to work more closely. If features were potentially coming through the pipeline very quickly then there would need to be a high level of communication between the development/product team and the sales and support teams, otherwise features could be out in the field before the latter teams knew about them!

It was interesting to see how people saw the role of support changing. It evolved from being perceived as a reactive, bug tracking function into a far more proactive model in which the support team were the people with the closest relationship with the customer. Since defects could potentially be fixed and shipped in a matter of days (if not hours) then the amount of time they would need to spend managing the bug list and communicating bug status back to customers was much diminished. However, as time is freed up from simply managing bad customer experiences, this can be re-focused on helping customers to use the product in a better way and actually enhance their experience of using the product. Support could post videos on Youtube of how to take advantage of new features, innovative ways in which other customers are using the product and ways to avoid common pitfalls. They could offer more live chat with customers to help them use the product and even to start to form a relationship with the customers over chat, twitter and any other support forums. In many ways, the role of support started to blur with the relationship management you might typically find in an sales-based account management role and with some of the customer communication you might typically find currently located in the marketing department.

The sales and marketing teams would also need to change their approach in this new world. The idea of planning around a yearly or 6-monthly release cycle would probably need to change to a continuous flow without big product launches or version releases on which to piggyback customer contact. There is the question of whether sales and marketing might want to intentionally batch up the feature releases in order to create a release event, at least while they transition to this new world. If support has ongoing interaction with the customer as described above then it starts to question the role of specialist sales people. Does the sales function manage the customer relationship or the support function or does it even make sense to differentiate the two? And let’s not even get started on how sales incentives and bonuses fit with this new world.

In conclusion

It is interesting to see how people respond when you take away what is almost a given for a lot of organisations and how they start to see the questions it may pose for other parts of the organisation. I’m especially encouraged how the hands-on developers have responded in the workshops. There is usually a perception that in most organisations there are the software development teams and “the business” and that the two often don’t understand eachother. However, the developers in the workshops have come up with some good business insights that suggests a closer relationship might be of benefit in both directions.

Having run this twice now I would be fascinated to run it again in other contexts (organisations or mixtures of people) to see if the answers are consistent. If I get a chance then I’ll let you know the results.