lessons from implementing agile across the entire product ......implementing agile across the entire...
TRANSCRIPT
Lessons From Implementing Agile Across the Entire Product Lifecycle
About MeLarry Cummings [email protected]
▪ Atlassian Certified Professional
▪ Product Developer▪ Agile practitioner▪ Interested in teams, process and community
Agile is not just for software teams
Based on value and principles.Product work is done by many teams, not just software development teams.
Who is this talk for?
Anyone interested in scaling agile, especially:● Product Owners / Product Managers● Team Leaders● Process Leaders● Executives (if they can stay focused)
What will we cover today?
● Does "being agile" even mean anything anymore?● The Journey from Agile to Devops
(as an example)● How to tell which teams are ready to work
in an agile way● What you should do with this information
What does "being agile" actually mean?
Agile doesn't say anything about how to do the work
meme history
Boards are where your team makes commitments
Image attribution
Modeling the Product Lifecycle is about chaining together very different Definitions of Done
Kanban and Scrum show you and your teams how to plan and track work
● Flexible enough to be appliedto any work effort
● Work well together because both are based on agile principles and values
● Good starting points, butteams frequently modify or create new tools and processes
Less and Safe are frameworks for scaling agile
● SAFe is very detailed● LeSS is very broad● You should lean on ideas in both● There is no royal road
SAFe▪ Process based▪ About long
term planning▪ Not a fan but
it’s still very useful
Image attribution
LeSS▪ Activity Based▪ About creating
a learning organization
▪ I like this one better
Image attribution
Let’s get realFrom Agile to Devops as a series of boards
star
tups
and
silo
s
Figuring out what you should build next
Once you start to see success everyone becomes interested in having a more coordinated approach.● We are listening to customers that are
now using our products● We have more good ideas than we can execute● We have to coordinate work across multiple
production teams
silo
pro
duct
team
s
Do you even need to scale the Software Development Life Cycle?
Not necessarily, especially not if:● Your silo can run as a self contained unit● The people impacted by the change
understand that you are a self contained unit● Coordinating production among
multiple teams isn’t a big deal
Do you even need to scale the Software Development Life Cycle?
Probably yes, because:● You have departments that
always work together● Users expect a seamless experience accross all
your products● Coordinating work and understanding
dependencies are difficult
You really have no choice you will be scaling agile because
Agile teams => successful productsWhich creates many teams that require coordinated delivery● Teams have conflicting priorities● Teams can’t break what works for other teamsUltimately, complex products create communities that take your product in unexpected directions
enterprise scaled Agile
problem icon package icon attribution
enterprise scaled Agile
problem icon package icon attribution
Defects and. Bug tracking
When we get successful we also start to call things bugs, defects, problems, incidents et. al.▪ How big is the problem/bug/defect?▪ Did we let the bug loose or is it something
we didn’t know about? ▪ Can we score the problem?▪ Bugs in production are harder to fix
because you have the burden to correct
Scoring Defects
Useful to identify how much attention we will be paid to defects
Purely quantitative External Judgement Internal Judgement# of users affected +
(keep it simple) quality score +
(UX, social media, paying
customer/partner)
risk score(legal, operational,
regulatory, strategic alignment)
Doing it again, and again, and again...
How do we keep it all moving to market quickly?● Let’s do all of these activities “during production”● Let’s have all teams work with customers● We’re fastest when we let teams find their own
ways of speeding up, right?● We do a lot of the same things every time, why
haven't we automated that?
The culture shift of continuous delivery
DevOps is not technically difficult.But making everyone’s priority value based customer deliverythat’s really hard!● Lily pad approach, not a ladder approach● Distributes the authority to take risks
Automation of everything that makes sense to automate,everything that can be, will be automated ● Speed up delivery by releasing to production immediately● Freaky fast actual resolution of problems
How to tell which teams are ready to work in an agile way
You can scale Agile if
● Each team has a common definition of done● Product Owners understand and fulfill their role
(especially owning the backlog priority)● Emphasis on giving the teams permission
to organizes themselves● Your whole organization is “bought in”
to the benefits of Agile
Consensus on why we're doing this
Actual benefits of Agile Misperceptions of AgileOutperforming competitors by creating a learning organization
Creating an outstanding culture by providing room for autonomy, mastery, and purpose, thus attracting talented people
Mastering continuous product discovery as well as product delivery
Minimizing risk, and improving the return on investment for product delivery organizations,
To become more efficient in delivery
To deliver faster
To improve the predictability of deliveries
source
“ Agile is worthless unless it serves as a catalyst for continuous improvement.
John Cutler Why Isn’t Agile Working?
Agile scaling frameworks can divert attention from execution.
I find this infographic more useful than the framework scaling graphics, because it shows the values and principles and how they delivery quality during execution.
Image attribution
You can distribute risk to improve quality; we used to call this craftsmanship
Image attribution
Reporting
● Needs to respect the rolesIf you’re not getting the reports you’d like, you may have to make them yourself
● Reports should be adapted and adaptable● Real time reports with
more signal and less noise● Set expectations,
have a clear narrative
Roles and leadership
● Product owners are servant leaders● Executives are ambassadors to the market● Team leaders and subject matter experts
give your teams the ability to innovate
Your ability find and foster effective product ownership is the hardest partOrganizations that struggle with scaling agileare struggling with learning how to recognize and nurture effective product ownership
Image attribution
What you should do next
Create a permanent Agile Transformation team
Continuous improvement will mean continuous commitment of people● Culture changes take time● Teams transform at different rates● Agile is not a cure-all but it’s definitely cost effective● Include qualitative metrics
Mandate or pilot?
● Scaled agile pilot efforts land in what i’ve described as silo scaled agile and enterprise scaled agile
● Scaled agile Mandate efforts usually go to DevOps
Roles are more important at scale
Who are the:● product owners● scrum masters● subject matter experts● team leaders ● agile champions
Invest in your people so they have time to make the move
The improvement in quality and adaptability is worth the investment in changing how you work.
Q&A
