Lessons From Implementing Agile Across the Entire Product Lifecycle
About Me Larry Cummings larry.cummings@isostech.com 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 applied to any work effort ● Work well together because both are based on agile principles and values ● Good starting points, but teams frequently modify or create new tools and processes
Image attribution
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 real From Agile to Devops as a series of boards
startups and silos
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 product teams
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 products Which creates many teams that require coordinated delivery ● Teams have conflicting priorities ● Teams can’t break what works for other teams Ultimately, 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 + quality score + risk score (keep it simple) (UX, social media, (legal, operational, paying regulatory, strategic customer/partner) 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?
Congratulations, you just invented DevOps! source
Software teams already have the tooling figured out source
The culture shift of continuous delivery DevOps is not technically difficult. But making everyone’s priority value based customer delivery that’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 Agile Outperforming competitors by creating a To become more efficient in delivery learning organization To deliver faster Creating an outstanding culture by providing room for autonomy, mastery, and purpose, To improve the predictability of deliveries 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, 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 roles If 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 part Organizations that struggle with scaling agile are 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
Contact Us isostech.com/atlassian -fast-track 480.366.5784 • info@isostech.com • isostech.com
Recommend
More recommend
