Lessons From Implementing Agile Across the Entire Product - - PowerPoint PPT Presentation

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

• rganization

▪ 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 + (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?

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 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 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

• wnership 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

480.366.5784 • info@isostech.com • isostech.com

isostech.com/atlassian-fast-track