Spotify have shared a lot of the things that have worked well, but they do also have challenges as well – one is alignment across teams as the organisation gets bigger so they have been working on visualisation and prioritisation
Check out her slides for the full summary of her talk, but here are my notes from the talk:
distance does not make a huge difference once you are not co-located – whether a floor away or across the world
challenges – time zones, culture, accountability, multiple competing stakeholders, latency in communication, availability and willingness, no body language
Korrine Korr
Albert Mehrabian principle – to interpret meaning it comes from 7% words, 38% tome and 55% non verbals – which explains why we have so much breakdown in virtual communication, on the phone the breakdown is 8% words and 82% tone
success factors – top notch leadership, clear goals, periodic face to face, frequent communications, attention to cultural differences, maximised communication quality
a virtual leader needs to amp up the skillet of a good leader – communication, listening, open dialogue, goals, team dynamics, culturally sensitive, results focussed, handle conflict
need to develop a shared team vision
develop a social contract – ask what are the values, then to get around understand and cultural differences ask them to explain what that will look like
fave to face inductions for new starters has a better chance for success
high clarity processes, the team performance grows as the dispersion grows
select people who are self starters, tech savvy, autonomous, actively reach out to collaborate
manage by outcomes not activity (as you can’t see them) – so need to agree the objectives, collectively make a plan, collectively monitor performance
GROW coaching model works well for remote workers, ask them what the goal is, what’s happening now, where are you at, what could you do, what do you need from me
build one on one relationships – regular deliberate contact, focus on those most remote, have purely social conversations to build connection
swift trust – trust that builds easily, SES has this because they know others have training, but one breakdown in conversation this breaks down
need to move from swift trust to real trust – do you know the needs and expectations that you team needs from you and you need from them, these need to me be met for trust, it’s a simple conversation we often don’t have, you may need to lead the conversation for others to reciprocate
virtual meeting – need to amp up how you chair, what are the protocols (eg mute when not speaking, raise hands, etc)
virtual celebrations – have lunch or celebrations at each end
have a ritual or something at the start of a call – a fun example is 2 truths and a lie or a list of words that can be snuck into a conversation
consider the richness of your tools
Korrine alluded to these YouTube videos on virtual meetings, worth a watch!
Craig catches up with two luminaries in the Agile and Lean space, Mary and Tom Poppendieck at YOW! Conference to talk about agile, lean, rapid feedback, culture and leadership. The discussion points include:
Making the link between lean and software development and discovering that waterfall makes no sense
Michael Hamman, Lyssa Adkins and Michael Spayd of the Agile Coaching Institute talk about Integral Agile and the personas of Agile Coach, Enterprise Agile Coach and Organisational Leader.
Watched a couple of short, unrelated videos on TED today from entrepreneur Derek Sivers.
When starting a movement, it takes a leader but the first follower is actually an underestimated form of leadership in itself. … The first follower is what transforms a lone nut into a leader! There job is to make it OK for others to join and to make it more safe.
Whatever brilliant ideas you may have or hear, the opposite may also be true. He gives the example of naming streets in Western culture, but blocks in Japan and how eastern doctors get paid for keeping you healthy, not treating you when you are sick.
Keep your goals to yourself because telling someone your goal makes it less likely to happen.
organisations have centres of excellence – how do you spread it from the few to the many without screwing it up? (examples – Hendrick Motorsports growing from 2 to 4 teams, McDonalds opening 1,460 stores in China)
shared mindset (what people should and should not do) is crucial to scaling up – Apple has a secrecy mindset, Amazon has an openness mindset, so there is no one right way
a mindset is required to be successful at Agile – going to a talk or reading a book is not enough, you need to grind out the message and do the same thing day after day and live by it (Facebook – employee on boarding is a six week bootcamp where they work on 12-13 short projects, focus is to inject people into the mindset and determine their best fit at the organisation)
the never ending danger is that things might go bad (Onward Memo by Howard Schultz – growth of Starbucks from 1,000 to 13,000 stores, in the rush to get a huge footprint, the mindset got watered down – got excited by growth and left the excellence behind)
Choice Point 1 – More vs Better
strategic tradeoff
voltage loss – things get lost in the translation, sometimes this is worth it because it is half as good as the best but twice as good as it is now
learning curve problem – takes people a while to get good when spreading knowledge from the few to the many
overload problem – burden of the management team in trying to maintain momentum
Choice Point 2 – Alone vs With Others
collaborate with competitors (Glad Press ‘N’ Seal), open source is one extreme, do it alone is the other (everybody at Pixar is an employee, nothing is outsourced
Choice Point 3 – Catholicism vs Buddhism (Replication vs Localisation)
roll out to the masses or a central set of beliefs
cranking out clones – works in manufacturing like Intel plants, Sees Candy and In-N-Out Burger either work in a market or not (pull out if not)
replication trap problem – Home Depot is a DIY model and when they rolled it out in China it did not work in their culture
localised solution – Buddhist approach to tweak just as much as needed to make it work
Scaling Principles
link hot causes to cool solutions – fire up contagious emotions first, humans are irrational, to motivate people get them emotionally cranked up (but the danger is that they get angry) so need to have a solution to cool their energy (watermelon offensive at Stanford for bike safety involved smashed watermelons and subsidized helmets or the first all-hands meeting at Apple after Steve Job’s return where the share price was not good so Jobs declared war on Dell and charged up people to make Apple great or get out)
live a mindset, just don’t talk about it – do actions that are consistent with the direction you want them to go, what we tell them doesn’t matter it is what they do that counts
when in doubt, cut it out – reduce cognitive load but deal with necessary complexity (A.G. Lafley keep it “Sesame Street simple”, Baba Shiv experiments on cognitive load for 2 vs 7 digit numbers), go simpler when trying to sell a message
when systems get larger and more complex, you need to deal with the complexity – Ben Horowitz “give ground grudgingly”, add people and processes only when things start to break down
Hackman’s rule for teams – over 6 people problems arise, more than 10 you are really in trouble, optimum is 4-6 people, Navy Seals and fire teams have 4-5 people, any more is more complicated
Dunbar’s number is 150 (100 to 230) – the cognitive number of relationships we can manage, pirate ships only have about 100 pirates per ship before dividing, Twitter average is about 100-200 followers
as the team gets bigger you spend more time on the dynamics and less time doing the job
little things pack a big wallop – subtle cues mobilise mindsets – design things that people barely notice but have a huge impact on their behaviour (background music, language, smells and sounds affect people’s behaviours)
Kathleen Vohs money research – people are less likely to ask for help or give help, will work alone when money is the object – leads to selfishness and self sufficiency
think about the little cues you are sending
connect people and cascade excellence – get one group to mentor the next to spread the excellence, grow your own replacement to get a promotion (Zynga), make your initial group diverse because more variation will give you a bigger impact
the mindset is the steering wheel and incentives are the juice – money is an incentive but so are pride and shame, how can I embarrass them or how can I make them proud (using mimes to mimic jaywalkers, Ben Horowitz fines people $10 a minute they are late for a meeting – it is not the money that motivates them it is the embarrassment, gets them to pay him on the spot!)
don’t put up with destructive beliefs and behaviours – bad is stronger than good, bad behaviours are ingrained more deeply, to spread excellence you need to stop the behaviours, bad behaviours are 5x worse than the good, destructive team members that can’t be reformed can bring down performance by 30% to 40% because you spend more time dealing with them rather than the work (Barry Feld of Cost Plus World Market would look for two things when visiting a store – greeting me and the customers and are the bathrooms clean)
Traps
don’t mistake swarming for scaling – raising awareness is not enough
too fast, too far – when people say they want to scale quick and fast, they are looking for the easy way (you are fighting a ground war not an air war)
When scaling you need to be master of addition and subtraction. – everytime you add something good, you need to remove unnecessary and bad things to make way for the good.
leadership is the next step beyond management – to a soft skills focus
productivity – undermining / resistance -> passive compliance -> active participation -> committed dedication -> passive innovation – move up the scale with good leadership
model desired behaviour – same attributes of a good leader are modeled over many years and in different countries – honest (will not knowingly follow someone who is dishonest), forward looking (describe the future state), competent (don’t want to be embarrassed by our leader), inspiring (The Leadership Challenge), a leader needs to shield the team, remove impediments, carry food and water and re-communicate the vision
communicate a vision – like driving in fog, without clear vision you need to slow down, clear direction allows focussed effort and speed, Jim Highsmith’s kick off meeting vision exercise, reinforce the vision frequently
create a learning and sharing environment – “if you have two hands to work with and you use one to cover your butt, you only have on hand left to work with”, set an example and admit mistakes and share information, ask questions of your team, make it OK to discuss the bad stuff
share information / power – agile tools allow move from micro management to navigation and communication
importance of the team – COCOMO Estimation model (Barry Boehm) shows that people factors has a multiplication factor of 33 (there is a 10x difference on good people over good process)
challenging the status quo – retrospective, “areas for improvement” works better in some cultures over “what didn’t work well”, retrospective action wheel, gathering lessons learned is one of the most frequently dropped agile practices
innovation and learning – if people are trying hard, then mistakes don’t really matter, Toyota collects lots of ideas with small incentives rather than one big idea
encouraging each other – treat people as volunteers, paying people just incentivises people to show up but volunteers are passionate, say thank you and why you are thanking them and what the benefit was, celebrate interim goals frequently, at the end is too little too late
Leading Conflict: A Systems Intelligence Approach to Conflict Facilitation for Leaders
This workshop presented by Michael Spayd and Lyssa Adkins was one of the highlights of the conference for me. The key takeaway for me was that “everyone is right… partially!” The slides are available here.
The workshop started with a discussion on the conflict we see on teams and then about why we came to the session and what we had hoped to get out of it.
systems oriented leadership – structured, holistic, organic, complex, end to end – move from the work level to a birds eye view
relationship systems intelligence – we are all in relationships – personal, work, departments
the human system is not in alignment with what agile does, leadership begins inside
see conflict through the right view – the right view leads to the right action, everyone is right partially, self organisation happens when all perspectives are represented, conflict is something trying to change in a system and not a problem to be managed
We then had a discussion around what is the benefit of the right view, is it difficult?
what is the difference between finding someone wrong as to finding someone right – go and hunt out why they are right
container – not necessarily physical but made up of behaviours, norms and culture of the team and environment
We then did an informal constellation exercise – 20 people in a circle, put the subject on a piece of paper in the middle, make a statement if it is true stand close, if not true stand away then ask those in the constellation what it means to you, need to talk from experience not what you think, remember people are right partially (take a soft focus). It is called a constellation because it looks like a star in the sky, speak from your experience, only people who wish to speak should
container – culture of the team, want to raise level of positivity and decrease level of negativity and toxicity, educate team about conflict and team agreement about digging into it
positivity and team performance – continue to abdicate your position is bad, needs to be balanced with inquiry – “not sure I agree with you, but tell me more”
all teams have an emotional bank account – positive interactions are a deposit and negative interactions are withdrawals, what is positive for your team and what is “flipping the asshole bit”
emotional withdrawals – blaming, defensiveness, stonewalling, contempt, excessive advocacy – contempt is most prevalent on software projects
emotional deposits – appreciations (noticing people doing little things, in front of the group), acknowledgements, more inquiry and less advocacy
never praise people for the work they do, but for who they are, turn up acknowledgements and turn down appreciations
appreciative inquiry – look at the strengths of teams
We then had a discussion around our teams positive /negative ratio
dealing with cultural conflict – inquiry openness, use my land your land ” in my land we…, what happens in your land?”
teams move around the quadrants – prison camp is not sustainable, happy camp and sweat shop are intolerant
conflict protocols – team needs to come to consensus, leader needs to take a facilitator / coach role – what is the environment and behaviour we want when we are in conflict, everybody’s job is to call out the protocols when needed, not enforce them
be a facilitator – more helpful than resolving it, keep reviewing the right view beliefs (fake it till you make it), understand your triggers
process the conflict – reframe the conflict” “I wonder what this conflict is trying to tell us”
don’t want debate or vote, a prelude to a discussion to find out what’s true
we get triggered by people who are like us who exhibit behaviours we don’t like
He kicked off the session with a live poll by getting the audience to answer the question “what goes wrong with product ownership” and then got everyone to move around the room based on experience, how well the product owner works (they don’t correlate!), internal versus external product development and the ability to change products
why is there a difference between developers and customers?
single product owners don’t work – whole teams own products
processes aren’t designed for success (including Agile ones)
safety isn’t success – Nordstromare a big successful company so they have lots of rigour around their process, nothing innovative gets through the net, so they built an innovation lab
waterfall model – step after step models have no feedback, Royce was trying to explain why it was a bad idea, experts have been trying to tell us why this is bad since the 70’s, traditional development models are safe
agile is the new waterfall – product owner creates stuff and gives it to someone else – someone to blame like the preceding process in waterfall
velocity isn’t value – being great at delivering software using agile then you should realise that it doesn’t matter, if we build more shit we just have more shit, we are not here to build software we are here to change the world, everything that happens (outcome) is after delivery, so need to maximize this, difficult to measure
underpants gnomes – a meme for something people are building but have no idea why
to get value you must form a hypothesis on how you’ll get it – this is the first shift companies need to make – how will we measure the output
one balanced team not client vendor – if we want to fail we can probably fail cheaper abroad
ideal product should be valuable, usable and feasible, product manager understands the value, UX or BA understands the usable, lead engineer understands the feasible, this is a balanced team – how should we build it, will they use it and how much will it cost
working as a team of comakers, we need to do a lot of mind reading, visibility is not good enough, shared understanding is what we are striving for
discovery complements delivery, morale suffers when we just build stuff, the thrill is seeing how well it works and debating the results and planning the next approach
story maps describe outcomes that we are shooting for
personas – don’t necessarily need to be accurate documentation but facilitate shared understanding
need face time with real people to understand, go watch people work to learn, then build models to map what you learnt (experience or journey map), when users explain a problem that should trigger an idea, share product story or product as part of a regular internal tradeshow
we need to understand the problems and find solutions to get us there, MVP (minimal viable product) should be the least we can build to solve a particular problem,
a newer version of MVP is lean startups (build -> measure -> learn) MVPe, smallest viable experiment so that we can learn and eventually earn
ready for release board – for each card, an explicit measure step and metrics, then before it leaves the board they need to learn
Nordstrom Innovation Lab learning loop – Replace the Mirrors – look for the number of learning loops, no idea on their velocity but we know how much they learned, just budget for learning – “life is better here, even though we fail most of the time”
you fail most of the time at predicting outcomes and getting value (Marty Cagan – Inspired)
making good product decisions is hard, focus on how fast we learn and how fast we get things out there
don’t focus on velocity and worry about who’s fault it is, focus on the things that matter
To succeed:
adjust your head – get out of the old client vendor model, be less like a waiter and more like a doctor and solve problems
take on the persona of a music producer – listen to bad music and help make others ideas better
be the film director – focus on the talent of the people you are working with, give direction and passion without stealing ownership
disagree – fewer people to execute, focus on importance, deliver benefits quickly, tackle issues like mobile and embedded
agree – not about how many people are doing this or certifications, there are plenty of problems to solve, a foregone conclusion, let’s tackle the bigger issues, adoption is superficial metric, plenty of challenges beyond pure software development
can you define ALM?
no agreed definition, lean concept of flow, includes the tools and processes
typically think about standard phases but the end to end lifestyle doesn’t work, now need to look at DevOps and cloud now, more complicated to deploy now
ALM tools are a misnomer, output of SDLC, fundamental issues with tools currently, we do not develop and done any more, need to start thinking about products and products have lifecycles
going forward will be more about traceability of past development and operations
worst thing is the name
what should we call ALM instead?
Application Lifestyle Context
Gartner are talking about this internally
nirvana…, once the new taxonomy is decided it will be antiquated, we are here to improve!
dynamic end to end process, software lasts decades longer than we expect it too, needs to sustain life
ripple effects of agile disrupts it
Gartner’s prediction of 80% of software development teams doing agile by 2012, where are we?
at least 80% of all IT organisations have some agile and 20% of large organisations, on everyone’s mind, businesses are talking about it, will probably still be another 10 years because big change takes that long
estimate that 40% of organisations are using agile, has blown past all the other methodologies, businesses realised recently that they’re not innovating
are we seeing issues with organisations part doing agile and part traditional?
often the only way organisations are initially successful, different processes (eg. software and embedded), needs to rolled out staggered and incremental
fair adoption in development teams, but now what does it mean to be a tester, lots of centres of excellence still exist, Facebook deploying every 25 mins scares the heck out of most traditional organisations, companies need to get to the right fit
majority of Agile teams are not purely Agile, use water-scrum-fall, slimming down requirements and deployments is not sprinting, Facebook analogy does not fly with corporate clients
need to begin where people are, approach what is the best for the organisation and adjust for the context
how do you measure effectiveness of Agile methods and compare them?
prefer not to speak about methods but rather patterns and practices, compare using customer satisfation, ROI long term for the organisation, organisations still like function points delivered because it is easier to count
one of the biggest pluses is on quality and that is subjective and hard to measure, metrics that can point like customer satisfaction, rework and defect counts, time to market also better, it is often a leap of faith
velocity interest is going down in industry, but many in the executive suite only think about velocity, a loaded word
don’t know soft value if you don’t baseline, now we just fix metrics inline and not all defects and features are equal, need to measure qualitative benefits to the business, will see more as metrics around Agile evolve
need to pull testing and quality in all the way through, drive better quality and user experiences
describe how you evaluate the tooling landscape?
most observations come from end users, tools aren’t the key most important thing, want to understand where the market is going and what is the right fit
biggest differentiator is picking the right tool for the job and the organisation
there are tools that enhance Agile that were not built for Agile, and there are specialised tools for Agile, vendors do put thought into who they are targeting so you need to listen, we don’t live in a world where everybody gets their tools from a single place
After Dark
A huge thanks to my friends at Atlassian and Opower who allowed me to tag along to an awesome Tex-Mex joint in Grapevine called Uncle Julios.
The introductory keynote at Agile 2012 in Dallas entitled Scaling Up Excellence was delivered by Bob Sutton, Professor of Management Science and Engineering at Stanford University and author of numerous business books including “Good Boss, Bad Boss” and “The No Asshole Rule”.
stop doing stuff that does not deliver value, not laying people off
spend time doing the right stuff, not the wrong stuff
think systems, not software – Southwest think employees, customers and then shareholders
optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
a separate testing team is silly – just handoff / afterthought, need to build quality into your product
need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
setting up a new product is a set of learning loops
watch for what is making people uncomfortable
understand your customers not by bringing an idea but by taking the team to understand the problem
there is always demand in a service company – fix issues as fast as possible, but that is not the game
consumability – how much effort does the customer need to go through to get value?
customers decide value… and therefore decide waste
measure productivity on value delivered, not features
work in progress is waste – customers are not interested in your long list of things to do
good Agile teams have a low number of defects
map end-to-end flow to find the biggest opportunity in your end-to-end process
40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
every organisation that calls itself professional should be doing TDD
expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
marketing leader – for a successful product you should be able to name this person
technical leader – keep two top engineers free to roam around and give guidance
Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
people who have dome something before should know how to deliver within the constraints
when managing an organisation you need to manage the capacity, you need to have a stable flow
kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
product-centric development – 54% of Fortune 500 companies are heading in this direction
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!
Renee and Craig are at the Agile Australia conference and talk to Anders Ivarsson, an organisational coach at Spotify, and learn some of approaches that make Spotify tick:
Korrine Korr
Craig Smith 
You must be logged in to post a comment.