Spotify, how we scale agile and what doesn't work the way we hoped it would
Spotify is no longer a small company comprised only of techie music enthusiasts from Sweden. It now has 2000+ employees spread across the globe and is a global major player in the music and entertainment space, and they have no intention of slowing down.
Such rapid growth carries big challenges. How can they continue to improve their product at great speed, while growing the numbers of users, employees and supported platforms and devices? How do they keep our agile values as they grow?
Outline/structure of the Session
Joakim Sundén and Benji Portwin, Agile Coaches at Spotify, will share how Spotify is addressing these challenges and how some things just don’t work. They will talk about autonomous squads, chapters, tribes, alliances, guilds, hack weeks, and a lots of things that have failed (and what we learnt)!
Those attending should have a few "awesome, it's not just us" moments; whilst learning about how Spotify operates, for better or worse. You will learn one method of scaling agile, including how agile coaches are now used and be able to ask questions across the board.
People who believe that agile can scale
schedule Submitted 7 months ago
People who liked this proposal, also liked:
Why one size doesnt fit all? - Selecting scaling framework.Nilesh Kulkarni
schedule 6 months agoSold Out!
Why one size doesnt fit all? - Selecting scaling framework.
This session will focus on what are the aspects organizations should consider when they want to scale agile implementation in organization. There are several frameworks out there like SAFe, LeSS, Spotify, and so on. what is it that organization is trying to achieve and how a systematic approach of scaled agile implementation can help the organization.
Attendees will be able to understand what aspects should be considered before organization decides to scale agile. How to scale agile and when to do it largely depends on what organization is trying to achieve. Each organization is operating it in different way so there is no defined formula or framework that will work for all. But guidelines from this session will help the members to identify their needs and then take further action. These guidelines can help the organization to successfully scale agile irrespective of which framework is selected.
What's Measured Improves: Metrics that Matter
“Every line is the perfect length if you don't measure it.” - Marty Rubin
So your organization has embarked upon a transformation to be more nimble and responsive by employing the latest tools and thinking in the Agile and DevOps arena. In this transformational context, how do you know that your initiatives are effective? Empirical measurements should provide insights on business value flow and delivery efficiency, allowing teams and organizations to see how they are progressing toward achieving their goals, but all too often we find ourselves mired in measurement traps that don't quite provide the right guidance in steering our efforts.
Rooted in contemporary thinking and tested in practice, this talk explores the principles of good measurement, what to measure, what not to measure, and enumerates some key metrics to help guide and inform our Agile and DevOps efforts. If done right, metrics can present a true picture of performance, and any progression, digression of these metrics can drive learning and improvement.
It is our hope that this session inspires organizations and teams to start or take a fresh look at implementing a valuable measurement program.
Mob Programming: A Whole Team ApproachWoody Zuill
schedule 7 months agoSold Out!
Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.
Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.
Quantifying Cost of Delay: Why is it the “one thing” to quantify? How do I do it?
Don Reinertsen says that if you only quantify one thing, quantify the Cost of Delay. As we’ve talked about before, quantifying Cost of Delay not only helps improve prioritisation, it also help with making trade-off decisions, creates a sense of urgency, and changes the focus of the conversation. Maybe this has got you interested in experimenting with it, but you’re not sure how to get started? If so, this workshop is specifically for you!
When people hear about Cost of Delay they sometimes doubt whether their organisation is ready for it. They say things like, “We don’t have the maturity for it”, or “We couldn’t do that because our stakeholders wouldn’t support it”. We’ve heard people say this too. And yet, in hindsight, people find it much easier than they thought! We will show you how to get started with using Cost of Delay, despite these doubts.
The first essential building block is to understand the value. To help structure the conversation we will use a simple economic framework to surface the assumptions and drive to the economic impacts. The second essential building block is to understand the urgency. For this, we will look at different urgency curves to help us understand how value is likely to decay over time. Combining these two gives us the Cost of Delay helping us to question and better understand what our gut tells us about value and urgency.
Practice makes perfect!
To get going, we will start by looking at some simplified scenarios that help you put what you’ve learned about Cost of Delay into practice. You’ll work at your own pace through some simple exercises that test different aspects of your understanding. To really embed it, once you’re done you’ll get a chance to help others around you – you become the teacher. We will then quickly reflect on what we’ve learned so far.
Then, we’re all going to work on quickly estimating the Cost of Delay for a real life example for a real company. You’ll do this in pairs making assumptions you need to get to a cost of delay for the feature in dollars per week. To help us learn about what the key assumptions were we will compare results across the group to help us understand what the value might be and the areas of greatest uncertainty.
To wrap up we’re going to ask you to do a mini-retrospective about what you’ve learned and what your puzzles are. If we have any time left, we’re happy to help you have a go with a feature or project you are working with.
Lean Enterprise: Maersk Line's journeyÖzlem Yüce
schedule 7 months agoSold Out!
- Does your organisation treat I.T. like a factory, taking orders from “the business”?
- Does your funding and approval process force you to work in large batches with commitment to fixed time, budget and scope?
- Do your KPIs lead people to optimise for their role or department?
- Do your legacy applications limit how fast your organisation can innovate?
- Is your fuzzy front end full of queues, analysis paralysis and fighting for approval?
If you want to hear about how Maersk Line, the world’s largest container shipping company wrestled with and changed each of these, this session is for you!
Our journey starts with a revolutionary approach: A $60m mega-project to deliver a new customer facing website. Set up as a “startup” within the company, we attempted to implement and scale Scrum. You’ll learn what worked, what didn’t and what we learned along the way – and how it was ultimately seen as a huge failure in the eyes of senior management.
We then pivoted to take a more evolutionary approach. This time by tailoring and adapting a set of Lean-Agile practices that would fit our context and culture – and mostly focused on increasing end-to-end speed. We studied the whole system and selected 8 Lean-Agile practices that could scale up to the enterprise level and across the whole portfolio:
The challenges of driving change in a Fortune 500 behemoth
How focusing on changing the whole end-to-end value-stream helped to reduce cycle time (and how that also hindered us).
How important changing the funding model was
How to argue for changing KPIs that damage the whole
How to “Do Agile” and make massive improvements in cycletime *without* any changes in downstream practices like automated testing and continuous delivery.
How we changed the common perception that Agile is for Greenfields only.
Value and Urgency: The Power of Quantifying Cost of DelayÖzlem Yüce
schedule 7 months agoSold Out!
“If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen
Everyone seems to talk about Cost of Delay, but few are actually quantifying it. And yet doing so helps us to better manage stakeholders, improve prioritisation and change the focus of the conversation away from cost and dates onto delivering value quickly.
In this talk you will hear about how quantifying Cost of Delay of our ideas helps with:
– Improving prioritisation
– Managing multiple customers
– Trade off decisions across the whole portfolio
This is not a theoretical session, we’ve actually done this in lots of organisations: public and private sector, in large, medium and small organisations as well as using Cost of Delay across a $100m portfolio at a Fortune 500 company.
When people hear about Cost of Delay they sometimes doubt whether their organisation is ready for it. They say things like, “We don’t have the maturity for it”, or “We couldn’t do that because our stakeholders wouldn’t support it”. We’ve heard people say this too. And yet, in hindsight, people find it much easier than they thought!
From this session you will walk away with all the necessary knowledge and practical tips to get started with Cost of Delay and you will have seen lots of actual examples of Cost of Delay calculations from other organisations who have done this. You’ll also hear some interesting before and after results that might help you to make the case in your organisation. In our experience, quantifying Cost of Delay really helps to discover, nurture and speed up the delivery of value.
Agile HR – Fact or FictionFabiola Eyholzer
schedule 7 months agoSold Out!
There is growing interest in learning more about Agile HR and its impact on individuals, teams and organizations.
It is important to separate fact from fiction: What are the real threats and opportunities of bringing Lean | Agile values, principles, and practices to HR? What can we expect in the future? Through anecdotal evidence and case studies, the session will explore the potential of Agile HR as well as provide guidance on how to approach the transformation.
Issues covered in the presentation include: information on how to embrace the new talent contract, create inspiring, engaging, and fun places of work, shift to an iterative performance flow, take the issue of money off the table, support growth within an Agile enterprise.
Be the Change - Key learnings from my coaching and personal transformation journeyBalaji Ganesh N
schedule 7 months agoSold Out!
Introduction and context setting:
Everyone has heard the oft-quoted maxim about leadership from ancient Chinese philosopher Lao Tzu, legendary founder of Taoism and author of The Tao Te Ching:
“A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.”
In the words of Michael Shinagel from Harvard University:
“Leadership is a protean art that defies a simple definition. It can take the form of a brash “command and control” style epitomized by General George S. Patton: “Lead me, follow me, or get out of my way.”
Or it can take a subtler form of leadership as exemplified by Nelson Mandela: “It is better to lead from behind and to put others in front, especially when you celebrate victory when nice things occur. You take the front line when there is danger. Then people will appreciate your leadership.”
Perhaps President John F. Kennedy put it best when he observed, “Leadership and learning are indispensable to each other.” Leaders learn to become leaders, and they continue to learn in their role as leaders.”
Learning is indispensable to leadership and coaching is one of the least focused or talked about aspects of leadership. Coaching helps leaders catalyze individual strengths towards peak team and organizational performance. In this proposal, I would like to share and dwell upon the lessons which enables leaders to become effective Change Agents and enable mindset changes that are an essential aspect of every agile transformation.
Learning 1: Remove self limiting beliefs and become more self aware
1.1 Never limit yourself by the past
Early in my career the CEO of the organization that I worked for shared with us what is popularly known as the “Elephant Trick” in one of the open forums. This goes like:
“The best advice I ever got was from an elephant trainer in the jungle outside Bangalore. I was doing a hike through the jungle as a tourist. I saw these large elephants tethered to a small stake. I asked him, 'How can you keep such a large elephant tied to such a small stake?' He said, 'When the elephants are small, they try to pull out the stake, and they fail. When they grow large, they never try to pull out the stake again.”
Time and again, I have found this insight inspiring whenever I had to influence myself or the teams that I worked with to move out of the comfort zone, go beyond the past failures and expand the horizons. This is at the core of what is better known as “Growth Mindset” these days.
I always nudge my teams that while it is my job to enable them to move out of the comfort zone and challenge the status quo, it is their job to tell me when they have reached the limit and need help. Failures are fine as long as they lead to learning experiences that helps shape a better future. This approach helps teams to let go of their limiting self beliefs, past failures and harness the power of a “Continuously Learning Mindset”.
1.2 Perception is reality
There are very few of us who are not surprised by the 360 degrees feedback that we get on an annual basis.
Whatever may be the reality, how people perceive us is what determines the way they interact with us on a day to day basis. We create perception through every action that we take or do not take. As we go about the business of carrying out our life, people will make judgments about our appearance, personality and capabilities
It is very important to constantly communicate with the stakeholders and be consistent in “Doing what you say and saying what you do”. Providing and seeking feedback regularly helps reduce the gap between perception and reality.
Learning 2: Change behavior, not culture
We often hear that employees are irrational in face of change and find all possible reasons to avoid it. I do not agree with same. Majority of the times, the irrational ones are the organizations who set objectives, processes, job description in a way that people stick to them and are surprised that they resist while being exhorted to do the opposite.
So, where does real change start ? Real organizational change starts from changing behaviors. Behaviors in turn are triggered by performance management, rewards and recognition systems. It is important that are
As Eliyahu Goldratt mentioned ““Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way… do not complain about illogical behavior…”
It is also important to recognize the behaviors that lead to the outcomes as much as we recognize the outcomes themselves. This helps shape the organizational culture that we would like to build and is at the core of building light house teams with high trust and ownership that set the trend for the rest of the organization.
Learning 3: Asking people to collaborate does not foster collaboration
An example that I recollect is of two teams who had tangential goals and were asked to collaborate. One of the teams was measured on identifying the maximum number of defects and errors whereas the other team was measured on the velocity of the deliverable and Time To Market (TTM). As many would agree, similar environment prevails between development and QA teams in most organizations.
Lesson learnt is “Don’t ask people to collaborate if they know that, in the end, there will be a winner and a loser. “ At the heart of most team / organizational dysfunction lies a non-aligned goal setting, performance management or rewards and recognition system.
So how then do we make teams collaborate and achieve synergies. This is where the power of “Shared Vision” kicks in. Measuring teams on a common high impact outcome helps them to collaborate with each other. I realized that measuring teams on a common goal of Time To Market (TTM) and business value creates excellent collaboration between development and QA teams.
Learning 4: Develop clarity of thought
Wherever there is clarity of thought, there is also commitment, focus an flow. It is essential to focus on the basics like creating trust and ownership in the team, getting and acting on early customer feedback, writing excellent code, automating repetitive processes, thorough regression testing and creating continuous incremental business value. Most of the times people chase the latest fads like mob programming, latest technology without really understanding if that is really required to solve the problem on hand.
It is also important for the leader to ask the right questions. Leaders should focus on “why” people do what they do vs. “what” they do. Asking the powerful question “why?” forces people to think deep. They can then peel back the layers of excuses and get to the root cause of the problem. For example, if employees have failed to meet a goal and are asked “why” questions rather than “what” or “how” questions, they might give responses like, “I didn’t prioritize my time.” So, the leader must then go farther and ask, “Why didn’t you prioritize your time?” When the employees say they have too much on their plate, the leader must ask “Why?” once again. The final answer: These employees are working on many tasks and cannot distinguish between what is and what isn’t a priority. With the real problem revealed, the leader can now take appropriate action, perhaps setting up time to help them prioritize their many tasks.
Learning 5 :Creating teams with "Purpose"
Most of us are aware of Dr. Viktor Frankl who became well known to the world through his book "Man's Search for Meaning" which is devoted to studying, understanding and promoting “meaning.”
In his words, as given below:
"Everything can be taken from a man but one thing: the last of the human freedoms—to choose one’s attitude in any given set of circumstances, to choose one’s own way.When we are no longer able to change a situation, we are challenged to change ourselves. Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom."
“He who has a why to live for can bear almost any how.” — Nietzsche
Wherever people understand the "Why" behind what they are working for, this automatically creates an environment of high commitment, pride in work and ownership. Storytelling is also an effective mechanism to help people relate to the situation on hand and engender higher levels of involvement.
Usage of purpose alignment matrix and four questions (who do we serve ?, What do they need and want most ?, What do we do better than anyone else to meet those needs and wants ?, What is the best way to deliver these products / services ? ) helps establish the team's purpose
While compensation is definitely a hygiene factor, it does not by itself motivate people toward better performance.I have personally found Dan Pink' s model of Purpose, Autonomy and Mastery quite effective when deployed at the work place.
Learning 6: Steer clear of common decision making bias and pitfalls
As leaders, we should be aware of and steer clear of the following common biases. I will cover these in more detail during the talk with specific examples.
- Attribution bias
- Zero risk bias
- Recency effect
- Information bias
- Ostrich effect
Agile Clinic – Strengthen Your Organization Agility
When a company thinks about transformation or a change from legacy traditional software development models to Agile, they first think of bringing in External coaches or Scrum experts. In another situation when the companies want to increase their maturity in agile, they still will want to hire people from outside who are experts in this arena. This discussion is all about how we could groom people internally to sustain and increase the credentials within the organization rather than relying always on external coaches.