A Story of DevOps >> Episode 4. Assemble (Productivity and Teams)

This is the next in the series of articles on DevOps. Today, the topic is about teams and productivity. Now, like most of you, I am conditioned to find out what needs doing before finding the people who need to do it. This sounds sensible and logical and for most ‘Good’ organisations, this is fine. However, Collins, found that Great Companies start with ‘Who‘ first – the difference between Level 4 and Level 5 Leadership.

Collin’s 3 principles for being rigorous is making people decisions:

  1. When in doubt, don’t hire. Keep looking.
  2. When you know you need to make a people change, Act.
  3. Put your best people on your biggest opportunities, not your biggest problems.

In “How Google Works“, Schmidt states that the most important quality of a manager is their ability to hire great people and Google have a very rigorous process to hiring and retaining great staff. However, once you have great staff, they need to work as a team:

Heroes

Avengers is the coming together of a number of well know superheroes to overcome an overwhelming evil. Iron Man, Hulk, Thor, Hawk Eye, Captain America, Black Widow, Black Panther, etc. come together. At first its all about their individual skills and strengths all of which are impressive – Iron Man’s suit, Hulk’s invincibility, Hawk Eye’s bow skills, etc. However, when confronted by Loki and his legions, their individual strengths are not enough! They eventually recognise that their independent skills and haphazard behaviours are not enough to protect the planet – strength in diversity, unit, common goal and organisation are needed to save the world.

Productivity

Drucker wrote a paper in 1999 describing how Taylor’s Scientific Management improved productivity of the manual worker and ultimately led to the Industrial Revolution, thereby creating the foundations of the developed world. His challenge is that the most important role of management in the 21st Century is to improve the productivity of the knowledge worker. I would thoroughly recommend that you read his paper: Knowledge Worker Productivity.

"It is on their (knowledge workers) productivity, above all, that the future prosperity—and indeed the future survival—of the developed economies will increasingly depend." Peter Drucker

Drucker distinguishes six major factors that determine the productivity of the Knowledge Worker (taken from Knowledge-Worker Productivity: The Biggest Challenge)

  1. Knowledge-worker productivity demands that we ask the question: “What is the task?” (Task)
  2. It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge Workers have to manage themselves. They must have autonomy. (Aligned to A Culture of Discipline, Good to Great and Smart Creatives, How Google Works). (Self-Organising)
  3. Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers. (Innovation)
  4. Knowledge work requires continuous learning, but equally continuous teaching on the part of the knowledge worker.(Learning)
  5. Productivity of the knowledge worker is not—at least not primarily— a matter of the quantity of output. Quality is at least as important. (Quality)
  6. Finally, knowledge-worker productivity requires that the knowledge worker is both seen and treated as an “asset” rather than a ”cost.” It requires that knowledge workers want to work for the organization in preference to all other opportunities. (Aligned to First Who, then What, Good to Great) (Passion)

Subsequent work on this topic build upon the principles found by Drucker, especially those concerning knowledge work executed by technologists. Literature such as Peopleware(DeMarco and Lister), How Google Works (Schmidt), Good to Great (Collins), Scrum (Sutherland) all talk about how to improve the productivity of teams of knowledge workers. The Phoenix Project draws out the distinctions and similiarities betweeen the productivity of the manual worker and the knowledge worker when Eric references Production Line work when discussing IT work.

"The manager’s function is not to make people work, but to make it possible for people to work." Peopleware, DeMarco

A really great paper has been written on the 50 Ideas of How Google Works. If you don’t have the time to read the full book, have a look at these which provide a short narrative on each of the 50 ideas from ‘Building around small teams’ to ‘optimise for growth’- collectively they produce a culture and environment of high productivity, low fear, creativitiy and user-focussed value.

There is a strong correlation between the 6 major factors that determine the productivity of knowledge workers and the 12 principles of Agile:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (Task)
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (Task)
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (Task)
  • Business people and developers must work together daily throughout the project. (Self-Organising)
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (Passion)
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (Learning)
  • Working software is the primary measure of progress. (Task)
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (Learning)
  • Continuous attention to technical excellence and good design enhances agility. (Quality)
  • Simplicity–the art of maximizing the amount of work not done–is essential. (Quality)
  • The best architectures, requirements, and designs emerge from self-organizing teams. (Self-Organising)
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. (Learning)

In a later post, I may do a more in depth study in the correlation between the major factors of productivity and the Agile principles.

Dynamics

Over the last 3 years, I have seen a surge in productivity and quality, represented through high throughput of change, lower incident volumes and overall improved customer satisfaction – these are some of the key indicators identified in Drucker’s report.

A significant component of this is the way we developed our teams, aligned them to common goals and empowered them to deliver value.

We took the principles of Product Ownership and picked up key roles such as Product Owner and Scrum Master and adapted these into our organisation.

Firstly, we identified who the Products were and then we brought all the teams that build and support the ‘Product’ together into one team. We then provided education and learning opportunities and adopted practices that facilitated more frequent interaction and reflection.

We then developed and assigned/recruited roles:

  • Product Owner: accountable for customer Value (Doing the Right Thing) throughout the full lifecycle of the Product from pipeline to service – the business owner/entrepreneur of the Product.
  • Product Delivery Lead: accountable for the Flow (Doing things as Quickly as Possible) for all types of work (Business Projects, Internal Projects, Change and Unplanned Work – See The Phoenix Project) including the productivity of the team – the servant leader.
  • Product Architect; accountable for Quality (Doing the Thing Right) from design through to service; involved in application architecture to problem management
  • Product Analyst; responsible for taking ensuring the team have the best possible understanding of what needs to be done and how it will best serve the customers. The translator of knowledge between business and IT and the role that assures the output meets the expectation throughout the lifecycle.
  • Product Engineer (Levels 1, 2 and 3); responsible for both the development and support of new features. Applying the “You build it, you support it” philosophy from Amazon. 3 Levels recognising the responsibility and contribution of team member from Apprentice to Coach.
  • Product Administrator: Junior member of the team, learning the ropes – the future of the team.

With the products and the teams in place, and with goals and targets emerging (See One Ring), we empowered the teams to deliver – which meant less interference from me (See Freedom). This requires a culture where truth is heard (Good to Great, Collins), there is increased trust at all levels (Leading at the Speed of Trust, Covey), leaders care personally and challenge directly (Radical Candor, Scott) which then leads to happier people (Scrum, Sutherland) and therefore more productivity (Happiness Metric, Scrum Inc.).

With Agile practices, visible workflow and visible workload, smaller increments of deliverables, greater communication and collaboration through ceremonies and less risk through smaller deployments, the productivity of the teams were greatly enhanced, as was morale.

The challenge is that this takes time – it requires all of us to go through the change curve and not everyone makes it – this requires great faith amid brutal facts. It requires the right vision, the right sponsorship, the right leadership, the right people and time… As Collin’s shows below, in the Flywheel Effect, there are a number of phases to go through and a process of ‘build up’ before you see breakthrough – Disciplined People, Disciplined Thought and Disciplined Action require character, patience, perserverence and hope. This is why there are lots of good companies and not many great ones.

So, like the Avengers, capable strong people in their own right, came together with a common goal, responsible for the whole product (Build and Support), empowered with mastered practices to do far more that any one of them could individually. We still have a long way to go and in some cases the challenge is now not with the performance of IT but the rate the business can identify and adopt change – a topic for a later article.

Ironman: We are the Avengers. How do we cope with something like that? 
Captian America: Together. 

More in this series:

  • A Story of DevOps
  • Episode 1 >> Origins (Traversing the Change Curve)
  • Episode 2 >> One Ring (Alignment and Empowerment)
  • Episode 3 >> Freedom (Leadership)
  • Episode 4 >> Assemble (Productive and Teams)
  • Episode 5 >> Shield (Tools of the Trade)
  • Episode 6 >> Kryptonian (Value, Flow, Quality in a Complex World)
  • Episode 7 >> Jedi (Mastery)
  • Episode 8 >> Balrog (Confront the Brutal Facts)
  • Episode 9 >> Kryptonite (Anti-Patterns of DevOps)
  • Episode 10 >> The Suit (Digital Transformation)
  • Episode 11 >> Infinity (Automation and Orchestration)

#AStoryofDevOps #DevOps

Raj Fowler

I am a natural, enthusiastic and authentic leader who understands the impact of IT as a differentiator for business performance and how organisational culture directly influences IT and business performance. With a strong appreciation of the changing technology environment, I have spearheaded a transformation of organisational ‘ways of working’ through adoption of the philosophies and principles that underpin DevOps, Agile and Lean. As a result, I have a track record of delivering operational excellence whilst improving IT agility, security and responsiveness enabled through close business relationships, technology-led thinking and inspirational leadership. 3 years ago we delivered about 50 to 100 changes per annum across about 80 business systems, all of which we managed using our standard plan, build and operate practices. Change was difficult and the transition from project to service was painful. I lived the opening chapters of the Phoenix Project on a regular basis. I now manage over 100 business systems and we categorised 7 of these as Products which include ServiceNow, Salesforce, Cognos, SuccessFactors, SharePoint. SAP and Bespoke Applications where we have established Product Teams. These are teams that build and support Product using DevOps philosophies. As a result, we delivered over 2500 changes last year whilst at the same time improving the service by 30%, improving customer satisfaction and employee morale. Using the "you build it, you support it" (Amazon) mentality, change is no longer a big event but a normal everyday occurrence and the usual spikes of incidents are no longer there, in fact with each change we deploy, the incident volumes reduce! Teams are not only delivering new features but are cleaning up their code and removing technical debt with every release. As a result, we have made a significant impact to the efficiency of our internal functions which in turn helps the competitiveness and profitability of the enterprise.

Have Your Say: