This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast, recorded at the Agile India 2019 conference, Shane Hastie, Lead Editor for Culture & Methods, first spoke to Jeremy Kriegel about design innovation and then with Doc Norton about why Tuckman was wrong and how dynamic reteaming makes organisations more resilient.
Key Takeaways
- Working to bring the design and agile communities together because there is a lot of synergy between and unfortunately there has been a lot of antagonism between practitioners in the two fields
- Agile done well compliments UX and design, however some of the agile anti-patterns have burned UX designers
- UX designers think holistically because customers experience products as complete things, they don’t experience them in pieces and if the product is built in pieces and those pieces don’t form a cohesive whole then the user experience is compromised
- When developers watch someone struggle with their product there’s a dramatic change in the way teams approach their work
- One of the common themes of agility is the need for stable teams in order to enable them to perform, however research shows that this is not actually true
- In Tuckman’s Form-Storm-Norm-Perform model there is an expectation that teams go through the four stages sequentially, however research has found that storming behaviour happens all the time and it happens more frequently on high-performing teams
- One of the dangers of stable teams is the emergence of “micro-silos” where knowledge is not shared between the stable groups
- There are a number of approaches to re-teaming which allow the benefits of stability while enabling knowledge sharing and build fluidity and resilience into the organisation
- One of the keys to effective re-teaming is self-selection
Subscribe on:
Show Notes
- 00:43 Introduction to the Design Innovation track at Agile India
- 01:11 Jeremy’s background and experience
- 01:34 UX Design traditionally followed a very waterfall process
- 01:56 This approach sounds nice in theory but never actually happened in practice
- 02:13 Agility gives permission to create a process that meets the real-world needs
- 02:31 Agility as a perfect match for design
- 02:38 Jeremy has been working to bring the design and agile communities together because there is a lot of synergy between and there has been a lot of antagonism between them
- 02:48 The agile community is more interested in UX & design than the design community is interested in agility
- 03:08 Agile done well compliments UX and design, however some of the agile anti-patterns have burned UX designers
- 03:17 UX designers think holistically because customers experience products as complete things, they don’t experience them in pieces
- 03:31 If the product is built in pieces and those pieces don’t form a cohesive whole then the user experience is compromised
- 03:48 Some of the design community have rejected the ideas of agile because they don’t see this holistic thinking happening
- 04:04 Describing some of the topics covered in the Agile India Design Innovation track (all videos available on the Youtube channel)
- Dual-track delivery
- AI design
- Marketing & branding
- User research
- 04:24 It’s about giving people tools to build the best product to serve the people you want it to serve
- 04:39 The mix of very practical with inspirational talks
- 05:21 Areas where UX professionals are struggling with today
- 05:24 Conveying the message about the value UX brings and integrating that with teams
- 05:40 What does it really mean to bring UX practices into a team?
- 06:01 Often UX becomes a recognised need as the target audience for a product grows – if the usability isn’t there then they can’t capture a larger customer base
- 06:17 When the pressure is on it is hard to make the cultural change needed to move from a feature-driven organisation to a user-centred organisation
- 06:31 Incorporating design is a cultural change that requires a shift in the whole organisation’s approach
- 06:45 A UX person will try to influence the team to think from a user-centred perspective
- 07:03 UX brings research and interviewing techniques to the development team so they can gain insights around how their customers work and where they are struggling
- 07:29 This shift in perspective brings empathy which results in better products
- 07:33 When developers watch someone struggle with their product there’s a dramatic change in the way teams approach their work
- 07:44 The story of a healthcare startup
- 08:29 The story of working in domain with absolutely no prior domain knowledge
- 09:49 The value of learning more and more about what you don’t know
- 10:38 The temptation to, and danger of, over-estimating how much we can empathise with users working in different domains
- 10:51 The more we engage, the more we test our understanding and get feedback the more we can validate our understanding and build better products
- 11:26 The integration between UX and agile development is still weak –
- 11:32 We still need to get the basics right – strongly integrating UX practices in an iterative way with agile product development practices
- 12:10 Advice for new practitioners for career growth – get your financial house in order so you can make decisions based on the best opportunities as they come up for you
- 12:51 Find good mentors – there are people who have deep experience who are prepared to help others learn in their own growth
- 13:30 Jeremy’s own experience learning from a mentor in his early career
- 14:10 Looking for positions where he could learn from more experienced people rather than being the lead
- 15:48 Introducing Doc Norton
- 15:38 Introducing the talk “Tuckman was Wrong”
- 15:58 One of the common themes of agility is the need for stable teams in order to enable them to perform
- 16:10 The fundamental message of Tuckman’s model is that teams go through the four stages of Forming, Storming, Norming and Performing in order to achieve high performance
- 16:34 This leads to a resistance to change team membership because teams will regress to earlier stages and performance will suffer
- 16:44 This is a theory, and it’s wrong – teams may not go through all the stages and they don’t necessarily go through them in the order we anticipate
- 17:02 Referencing the studies which have found these results
- 17:23 The research has found that storming behaviour happens all the time and it happens more on high-performing teams
- 17:33 There is a correlation between high-performance behaviours and storming behaviours
- 17:38 There is a difference between the storming in high-performance vs the early storming of new teams
- 17:46 This means there is no “regression” into storming, storming is a regular state for teams to be in
- 17:53 Storming is part of being a team
- 17:58 This means that the number one reason for not changing team members seems to be unfounded
- 18:05 Tuckman’s model is wrong, but it is useful so do not discard it – recognise that it is a model not a reality
- 18:21 If the premise for stable teams is not valid, why should we try to have stable teams and what are the alternatives?
- 18:26 A lot of the benefits from stable teams happen because of not over-allocating them with work and not putting people on multiple projects at one time
- 18:52 Stable teams have a benefit and are a good structure to support cultural change in an organisation
- 19:21 One of the dangers of stable teams is the emergence of “micro-silos” where knowledge is not shared between the stable groups
- 19:31 Examples of the problems which can emerge from too much stability
- 19:46 Once we have established norms and standards across the organisation, we can then share knowledge and learning by allowing people to move between teams
- 19:54 Managers do not move people – people opt-in and self-select for moving from one team to another
- 20:05 The goal is to achieve fluidity of people movement with high connection between the teams
- 20:12 This means the organisation becomes more resilient and more able to adapt to change
- 20:30 Exploring some of the re-teaming patterns, don’t reform every team every three weeks!
- 20:41 Have teams create their own onboarding process so they can easily ingest new members
- 20:58 When we are deliberate about how we bring new people into a team they can be very effective within weeks rather than months
- 21:05 When teams become good at bringing new people in, they can quickly grow as needed
- 21:10 When you bring more people in and they grasp the team culture you can split the team and you have two teams who have shared standards and norms and who can rapidly ingest new people as needed
- 21:22 This is a mitosis pattern and is a way to grow an organisation while retaining shared standards and norms
- 21:28 A common mistake is to take a high-performing team and disperse the members across other teams hoping they will influence their new teams, however the opposite is normally the case
- 21:49 Another pattern is “volunteer fire department” – a team rapidly forms to address a specific critical problem, solves the problem and disbands
- 22:02 Sharing team members – a few people swap from one team to another for a short period to share knowledge and skills
- 22:14 Fluidity is not remaking the whole organisation, it is organic growth and evolution
- 22:26 LinkedIn has the concept of “tours of duty” where people worked in one team for a period of time (6 -12 months) after which they have the option of continuing in that team or moving somewhere else
- 22:48 The result is predictability in movement between teams, people have options about what they want to do and a long enough commitment to get and give value in the team
- 23:00 Some organisations run internal job fairs at fixed intervals where people can select to move between teams
- 23:12 Some organisations have a more fluid approach where people move as they self-select
- 23:17 Most of these movements are self-selected rather than manager directed
- 23:41 The autonomy to self-select is a key success factor in these approaches
- 23:52 Tackling some of the fears about everyone self-selecting away from “boring” to “exciting” work. The reality is that we all have different opinions of what is “boring” or “exciting” so work does get staffed as needed
- 23:40 People migrate towards different work at different periods of their lives and creating an environment that allows for that increases retention
- 24:57 Examples of organisations that do this well –
- Valve (their employee handbook is freely available on the internet)
- Spotify
- Groupon
- 25:25 Telling the story of how Doc implemented this at Groupon and the outcomes they attained
- 27:13 How Menlo Innovations allows for reteaming on a weekly basis
- 27:44 Doc’s book Escape Velocity
- 28:00 Velocity is the most commonly used metric on agile teams, but it is not a good metric for many different reasons
- 28:16 The characteristics of the early teams where the idea of velocity came from had a very specific context which meant that velocity was a valid metric in that context
- 28:34 Most teams do not have the same characteristics and for them, velocity is at best meaningless and potentially a very dangerous metric to use
- 28:55 Alternate metrics which can help teams understand their health and effectiveness include throughput, lead-time, cycle-times, WIP, batch size and others
- 29:34 Too many teams get beat up over their velocity not being high enough
Mentioned:
