BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News QCon New York Day 1 – High Velocity Development Teams Track Summary

QCon New York Day 1 – High Velocity Development Teams Track Summary

Bookmarks

QCon New York 2017 kicked off with Matt Sakaguchi giving the opening keynote titled "What Google Learned about Creating Effective Teams", in which he told the story of his "back door" path to becoming Site Reliability Manager at Google, via the police force, retail stores and leading teams, and being diagnosed with cancer.  He related incidents from his past where the important teamwork factors had come into play and explored the impact they had on him.  He said that "Engineering is easy, people are hard".

He briefly addressed diversity issues and stated that "A lot of people in tech are unable to bring their whole selves to work". He pointed out that making a team environment better can, and does, have a profound on people's lives. He went on to explain the results of Project Aristotle which explored the characteristics of effective teams. Then he showed the five dynamics exhibited by effective teams at Google.

These five factors mean that how a team works together is more important than who is on the team.

He ended by encouraging the audience to set the tone for psychological safety:

Debbie Madden was the first speaker on the High Velocity Development Teams track.  She spoke about the Top 5 Secrets to Improving Team communication.  She pointed out that "ideas are a dime-a-dozen; it's the best teams that win, not the best ideas" and that teams need to communicate effectively to be successful.

She provided five key pointers to becoming more effective communicators:

  1. Recognize chaos – know where you are on the Greiner Curve  and respond accordingly
  2. Change it up – at least every six months retrospect on every meeting and other aspects of work and find ways to be more effective
  3. Communicate the Why – "Start with Why" and make sure everyone on the team understands the reason the team and organisation exists
  4. Prioritize team productivity – individuals will sacrifice something they want for the good of the team
  5. Protect team health – build trust and create psychological safety

Cat Swetel then spoke about "Development Metrics You Should Use But Don't" in which she explored metrics around:

  • Quality
  • Responsiveness
  • Productivity
  • Predictability

She explicitly did not include measures of Value in her metrics as those are often outside the direct control of the team, however the four aspects do significantly contribute to providing value in a product.

She stated that Time in Process is the core metric which any team should be looking at and that by doing so we can measure all four aspects she listed.

Time in Process is defined as Units of Work per Unit of Time. The actual units don't matter as long as they are consistent. To be able to measure this teams need to explicitly understand and clearly identify when any piece of work starts and when it ends and these points need to be consistently recorded.  For more granular measures which the team can then use to fine-tune performance, adding start and end times for the different workflow states makes the data more useful.

Swetel showed a variety of graphs which can be derived from the Time in Process data and how they can be used to express the four aspects.

She proposed that teams use Cumulative Flow Diagrams and Little's Law as tools for understanding the state of work and the rate at which teams are able to deliver that work.

The next speaker in the track was Conal Scanlon who spoke on "More Reliable Delivery with Monte Carlo & Story Mapping"

He pointed out that in most organisations today the planning approach uses some sort of Expert-Based Estimation using an abstract size metric like Story Points or Function Points or relative sizing. He states that these have inherent problems that result in marathon meetings, apathy about the numbers and no predictability. He proposed using the Monte Carlo technique instead.

He described the process:

  1. Define a domain of possible inputs
  2. Generate inputs randomly from a probability distribution over the domain
  3. Perform a deterministic computation on the inputs
  4. Aggregate the results
  5. Forecast

He emphasised two simple but important rules:

  1. Every forecast includes a date range
  2. Every forecast includes a probability of hitting that date range

He presented an example using a team who has delivered three sprints and taken an average of five days to deliver a single story.   By running multiple simulations using a statistically correct spread of durations he was able to predict  the range of durations for the project and the relative probability of hitting specific dates:

Confidence Level

Days

50%

82

85%

92

95%

96.67

He briefly touched on #NoEstimates and pointed out that trying to size the items in the backlog is generally a waste of time.  The examples he provided were achieved by simply measuring throughput and counting the number of items.

He then described the technique of Story Mapping, drawing on Jeff Patton's work on the topic, especially his book.

Story maps start with defining the personas who will interact with the product, then build the backbone of the process and identify the activities and tasks the personas will want to complete using the product.  Then you can partition the map into logical releases, using the guidance:

"What's the smallest change we can make to learn what we need to learn?" and "What's the smallest amount we can build to achieve the desired outcome?"

Jason Yip then spoke on  "What Does Speed Mean in Software Product Delivery?", drawing on his experiences at ThoughtWorks and Spotify.

He spoke about two aspects of speed – what feels fast and what actually is fast. 

On feeling fast he explored the various friction points in development.  Friction is when "it feels like the work is fighting you", such as:

  • Unclear goals (ensure there is clarity and alignment)
  • Email tag (talk to each other)
  • Clicking around a UI (use shortcut keys)
  • Confusing code (write clear, clean code)
  • Too many meetings (set aside meeting free days, remove any unnecessary meetings)
  • Not knowing what to work on next (go and find out, don’t wait)
  • Repetitive activities (automate them)

He introduced the concept of Refined Annoyance as a technique for identifying friction points and then actively addressing them rather than passively accepting the situation.

He shared his ideas on how to ensure refined annoyance is present in the people on the team, starting to looking for it during hiring and including techniques such as pairing and role modelling the behaviour.

He then explored the ideas around actually delivering fast, which is about designing the system for rapid delivery.  He identified three common impediments to actually delivering fast:

  1. Zombie projects
  2. Unclear delivery accountability/decision making
  3. Large launches

He gave advice on how to address all three. 

Zombie projects are ones which should be dead but are sucking up capacity to deliver.  Have a clear priority for projects and if something becomes low priority kill it off, don't leave people partially allocated to work on it.

Make sure there is absolutely clear accountability for different types of decisions and that everyone knows whom to ask about what.

He explained the allure of large releases along with the risks associated with them, and advised to always break work down into small chunks and deliver iteratively & incrementally.  Quoting Kent Beck:

In XP we don't divide & conquer – we conquer and divide. First we make something that works, then we break that up and solve the little parts.

He ended by exploring why we are still addressing these issues, despite the fact we’ve known about the solutions for years?  We need to tackle the system-level challenges and design how we deliver as well as tackling the friction points in the delivery process.

Josh Evans then spoke on "Refactoring Organizations - A Netflix Study"

He started by telling the history of streaming services at Netflix and describing the team environment, particularly on how two teams were expected to integrate their work.  He referred to Conway's Law and showed how it describes dysfunction in organisations.

He then looked at applying design and refactoring patterns we are familiar with from software engineering to the design of the organisation.  This starts with selfless leadership which looks at any decision and its impact first on the company, then on the team and finally on the decision maker, in that order.

He asked why we refactor and said it is to improve or sustain:

  • Functionality
  • Engineering velocity
  • Functional and operational quality

As we scale!

In an organisational context, saleability is:

The ability for an organization to easily add people and domain responsibilities in response to increased work and complexity

The ease with which an organization or team can adapt to shifts in business strategy

He went on to provide examples of different patterns and how they are applied at the organisational level. 

Organizational Polymorphism:

The Netflix culture is based on:

With the right people

Instead of a culture process adherence

We have a culture of creativity and self discipline, freedom and responsibility

One way this is embodied is in the idea "You build it, you run it" where the people who build a service run it and maintain it.

Prioritize & Queue

He spoke about having an overwhelming queue of work for a team of only six people and how using the Prioritize & Queue pattern meant the work flow was managed effectively.

Context Switching & Thread Starvation

He presented a clear visualization of context switching and discussed the need to enable people to keep focused on one thing at a time.  This also requires spreading knowledge and skills so on one individual becomes a single point of failure.

He ended by discussing the importance of EQ. It’s not all about the structural changes: it is necessary to understand that people are emotional beings with emotional reactions. 

The contrasted EQ and IQ:

IQ                                                        EQ

Task-oriented                                  Feeling-oriented

Logical                                               Emotional

Literal                                                Social

Detached                                          Empathetic

Autocratic                                         Democratic

 

He closed with the advice:

Put architecture first

Leverage technical analogs

Know when to use IQ v EQ

Be selfless

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT