What do you want to improve? Being/doing/scaling Agile isn't the point
•Download as PPTX, PDF•
5 likes•1,756 views
Given a desire to improve our software development endeavours, we tend to apply models and frameworks like Scrum, Kanban, LeSS, SAFe, even a custom implementation of Agile itself, without really understanding what our current model is, or what we value. This approach leads us to do things and reject things in an ad-hoc way; not knowing whether the change will actually result in improvements in the areas where we need it most. At an organisational level, we often don’t even want or value “agility”. We default to notions of “making the organisation agile” or “scaling agile” without confirming if that is what is actually desired. This talk will take the audience (minus an agenda) through three simple steps to improvement, by: 1) Understanding goals; 2) Understanding desired cultural values on key dichotomy scales; and 3) Synchronising in iterations. At a small company/single product level, following these steps might result in a group of people synchronising to product goals as a Scrum team. At a larger company/multiple product level (aka “at scale”), it might result in teams across departments being synchronised to organisational goals via organisational sprints/iterations. The audience will come away with practical steps to effecting team, multi-team or full organisational change, in the area of product development. Underpinning these steps will be the key message that Agile, Scrum, Kanban and Lean Principles can aid the improvement journey: but none of these things should be a goal in itself.
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Similar to What do you want to improve? Being/doing/scaling Agile isn't the point
Similar to What do you want to improve? Being/doing/scaling Agile isn't the point (20)
More from Killick Agile Consulting Services
More from Killick Agile Consulting Services (20)
Recently uploaded
Recently uploaded (20)
What do you want to improve? Being/doing/scaling Agile isn't the point
- 1. What do you want to improve? Being/doing/scaling Agile isn’t the point @neil_killick
- 2. Improve
- 3. I’m gonna have to Agile the shit out of this!
- 4. – feelings of anxiety and discomfort resulting from simultaneously holding contradictory or otherwise incompatible attitudes, beliefs, or sets of assumptions” Source: https://flowchainsensei.wordpress.com/2012/04/29/the-nine-principles-of-organisational-psychotherapy/ Photo: Contradiction by wornish “Many organisations, particularly in times of stress or change, suffer acutely from ‘organisational cognitive dissonance’
- 7. Vision
- 10. Where we are Collective Mindset Sliders
- 11. Collective Mindset Sliders Where we should be
- 13. Capability 3 Capability 4 Capability 5 Capability 6 Capability 7 Capability 8 Capability 9 Capability 10 Backlog Doing Capability 2 Capability 1 Next Team 1 Team 2 DONE No. 1 priority capability - which teams are required to deliver it end-to end? Teams 1 and 2, in this case Capability 11 Capability 12 Backlog of customer capabilities, ordered by value
- 14. Capability 1 Team 1 Team 2 Capability 2 Team 1 Team 3 Capability 3 Capability 4 Capability 5 Capability 6 Capability 7 Capability 8 Capability 9 Capability 10 Capability 11 Capability 12 Backlog DoingNext DONE Next priority capability also requires Team 1, but Team 1 is focused on a higher priority capability - leave them alone! If Team 3 starts without Team 1, they may end up either having to interrupt Team 1 (who are working on a higher priority feature), or leaving Capability 2 unfinished to start another Let’s put a blocked sign on the capability to signify that a lower priority capability is being selected
- 15. Capability 1 Team 1 Team 2 Capability 2 Team 1 Team 3 Capability 3 Team 3 Capability 4 Capability 5 Capability 6 Capability 7 Capability 8 Capability 9 Capability 10 Capability 11 Capability 12 Backlog DoingNext DONE Team 3, and every team in fact, should pull in the highest priority capability for which they have no dependency on a team working on a higher priority capability
- 16. Capability 1 Team 1 Team 2 Capability 2 Team 1 Team 3 Capability 3 Team 3 Capability 4 Team 4 Capability 5 Team 6 Team 5 Capability 6 Capability 7 Capability 8 Capability 9 Capability 10 Capability 11 Capability 12 Backlog DoingNext DONE Capability 4 Team 4 Capability 5 Team 6 Team 5 Capability 3 Team 3 Teams pull in work
- 17. Capability 3 Capability 1 Capability 4 Capability 5 Capability 6 Team 4 Team 5 Team 6 Capability 1 is “Done”, so teams 1 and 2 are available to pull in the next highest priority capability that they have the ability to work on Team 3 Capability 2 Team 1 Team 3 Capability 7 Team 2 Capability 8 Capability 9 Capability 10 Capability 11 Capability 12 Backlog DoingNext DONE Team 1 should work on top priority (blocked) capability Teams 1 and 3 should now co- ordinate to put focus on the higher priority capability
- 18. Capability 3 Capability 1 Capability 4 Capability 5 Capability 6 Team 4 Team 5 Team 6 Team 3 Capability 2 Team 1 Capability 7 Team 2 Capability 8 Team 1 Team 4 Capability 9 Team 2 Team 6 Capability 10 Team 3 Capability 11 Team 5 Capability 12 Backlog DoingNext DONE
- 19. Iterate
- 20. Survive
- 21. ★ Company vision ★ Customer capabilities ★ “How the work works” ★ Synchronise as a company ★ Iterate as a company So, what is the point?
Editor's Notes
- There will always be a desire to get better - this is how execs try and motivate staff We tend to default to Agile and Scrum, but is that actually wanted? In this talk I’m going to argue that we’re missing the point by talking about being/doing/scaling agile We need to identify what we’re trying to improve and why - I will give you some tips to help you do that
- Stand up if your company or team is involved in some kind of Agile adoption? Stay standing up if you know who started it Stay standing if you know why, i.e. what they’re trying to achieve Development teams default to Agile, but do we even know if that is what the leaders in the organisation want? Requires organisation to change, but have we asked? If they don’t want it, are we likely to be successful?
- Mixture of mindsets within the organisation, even within “agile” people Causes perpetual headbutting when trying to improve how the work works
- Local optimisation - We can’t work together due to org cog diss, so we focus on our own team, our own goals Every team is trying to justify its existence - showing they are efficient and not the problem Teams and departments are not in step with each other - they are locally optimising Will improving our team improve the company’s results?
- What is the goal? Someone, somewhere, wants something systemic to improve. But what? And why? True improvement can only be from the company’s perspective
- Provide strategic clarity - What are we trying to achieve as a company? New customers? NPS? Enter new markets? Short/medium/long term Knowing this will help every employee make good decisions daily
- Define ALL product development work as customer capabilities which are believed will deliver company goals Ensures we are always focused on meeting our customers’ needs Order these capabilities regularly in accordance with current company goals
- Need to know how the company leaders want things to work - do they care about agility? Do they believe in self-organisation? Is lean/agile appropriate? What is the “right” mindset? To be effective we must minimise org cog diss
- Shows collective mindset of organisation, and desired mindset of leadership Shows if lean/agile is appropriate, and which areas require most intervention Gives people a decision to make - can’t survive in system with “wrong” mindset
- Extreme swings require more drastic intervention
- Align company around what is important NOW Companies have lots of goals How do we make sure people are focused on the most important ones at the right time? Do folks understand the goals? Are any of them in conflict? Synchronise dependencies Feature teams Push dependencies down the priority queue - here’s an example
- Coordinating: This might be a simple matter of waiting for the other team(s) to finish what they are working on (if it's close) Augmenting teams temporarily Pausing lower priority work. The teams can decide what's best based on the situation.
- To be really effective at achieving company’s goals we need the ability to learn and adapt to new information, both internally and externally Once we are synchronised, we can do this by iterating We can embrace changing requirements, thus being more customer-focused Don’t need to keep spending time and money on a solution we have learned to be wrong - “pivot” Systemically avoiding risk of sunk cost fallacy
- Why science the shit out of everything? Is science the point? Potatoes? Survival? Is being/doing/scaling Agile the point? Agile, Scrum etc. can help us become more effective at delivering quality, valuable software early and often to customers - but they are a means to an end, not the end itself - when you start talking about scaling these things, that becomes even truer
- What are we trying to improve? What is our goal? How will we know we are improving what we want to improve? If we can’t answer these questions, how likely are we to be successful? What are YOU trying to improve?