Michael Cote from Pivotal on Programming the Business

• 0:22 Introduction & background
• 3:58 Working with the people who are responsible for managing software development as a core organizational capability (“programming the business”)
• 4:35 It’s possible to move from deploying on a yearly basis to a daily basis
• 5:15 It’s a given that things need to be automated to enable this type of change, but that’s not enough
• 6:12 Adopting a new process or approach often improves things dramatically, frequently because what was being done before was not effective rather than because of the effectiveness of the new way
• 7:00 Most large organizations are trapped in their current ticket-driven flow of working and don’t have the automation infrastructure in place to be able to move to more productive approaches
• 7:47 All the literature and conferences talks about the importance of automation and “it’s obvious” that we should be doing it but many organizations aren’t there
• 8:24 The common situation that development teams find themselves in when attempting to adopt automation
• 8:55 Service management has become a constraining factor in many companies
• 9:20 Often “change control” is actually “change resistance”
• 9:50 From an operations perspective, the best way to keep the software running is to ever change it
• 10:32 If you’re not deploying to production, it’s not very helpful to do frequent code-complete builds
• 10:58 This means making change from the operations perspective
• 11:22 Achieving this change requires addressing the challenges in the pipeline incrementally, peeling them away like an onion
• 12:22 With smaller organizations it is possible to get everyone together and collaboratively tackle the problems; this is far more difficult in large companies
• 12:57 At scale, the management behaviours and attitudes are the key to success
• 13:32 The most basic change is to address the compensation and reward systems which are preventing effective collaboration
• 14:10 This starts with the layer of leadership above middle managers
• 14:25 Change the structures so teams are focused on products, not projects, ensure all the roles needed are in the team and that they are fully dedicated to working on the product
• 15:20 At the leadership level in large orginazations it is rare that your peers want you to succeed because of the zero-sum incentive structures
• 16:28 To start moving to the product structure takes significant work to figure out the truth of the current architecture
• 17:42 This means someone very senior in the organization needs to be wielding the pickaxe to break the current concrete structures
• 18:32 Every organization is uniquely screwed up in tactical ways, so there is no single pattern or approach which can be applied across the board
• 18:48 Exploring the evidence which shows that pair programming is a valuable approach which does improve quality and productivity, yet most people still don’t want to pair
• 20:03 More junior people are prepared to pair because they can see the benefit of learning
• 20:17 More senior people are the most likely to resist pairing because they see it as demeaning and it means that other people are learning what they are the expert in, the hero
• 21:02 Incentive structures reward hero behaviour as success over preventing failure
• 21:47 A developer typically spends 2-3 hours per day actually programming
• 22:17 When pairing the amount of time focused on programming easily doubles
• 23:12 Generally people don’t want to change, so it is important to find ways to make the change better for them
• 24:22 The rift in many organizations between “the business” and IT means that business people don’t expect the software to be agile and responsive to their needs
• 24:35 You can generally make software do whatever you want in a reasonable amount of time
• 24:57 There are ways to plan and structure you software so that one of the core features of the product is that it can change frequently
• 25:17 There are all sorts of ways that you can build the ability to experiment into a software product
• 25:35 The historical relationship means that generally business people don’t even think about asking IT to run experiments
• 25:54 Find and use language which makes it OK to learn through experimentation and failure
• 27:06 If the developers know that they will be punished if things don’t work perfectly, then they wont experiment and take risks and will be very change-resistant
• 27:40 If we can deploy our software every week, then at most there will be a problem for a week – that is a manageable level of risk, and the more frequently we can deploy the smaller that risk becomes
• 28:04 This also means that we can run business experiments more frequently, learn from them and build products that people want
• 28:31 If we can change the software frequently, maybe we should use that capability and make it better
• 28:48 Businesses which were founded in the tech space are inherently agile and they run using these approaches all the time.  The challenge is bringing “traditional” businesses down the same path
• 29:48 The app ecosystem on phones is an exemplar of how the approach of experimentation and learning is being put into practice  
• 30:12 Explaining the example of how frequently the American Airlines app changes and constantly delivers new features and new ways of interacting

Mentioned:

• Pivotal
• Twitter: @cote
• Podcast: Software Defined Talk