Software Engineering :: Agile :: Courses :: Agile in the Real World

⪼ Made with 💜 by realpolyglot.dev

Software Engineering :: Agile :: Courses

About

by Jeremy Jarrell

Bending Agile to Fit Your Team

Incremental or Iterative

...

Agile is an Approach
If you boil agile down to it's minimum, you pretty much get scrum
Waterfall is a defined process: The same inputs and process always yield the same outputs
Scrum is an empirical process - Gather experience and adapt accordingly
Incremental !== Iterative
Incremental = Product is delivered in small chunks - Highest priority features first - Features are complete at delivery
Iterative = Skeleton product delivered first - Successive releases refine the product - Incorporates customer feedback throughout delivery

Shipping Products Bit by Bit

To get the true value out of an agile approach, incremental and iterative delivery must be combined.

Iterative Delivery

To get the true value out of an agile approach, incremental and iterative delivery must be combined.
Build the *Most Important parts of the product first as a working skeleton
Demo To Customer
Fill in what's missing based on customer feedback
This allows development teams to deliver a more holistic product earlier in the development cycle
The product may be light on features initially; however, it allows the customer to provide feedback sooner rather than later
Refined through successive releases
Gives the user an opportunity to interact with the app in a meaningful way and provide better feedback about how the features of the app interact
Helps avoid investing in polishing a feature only to find out that it's not what the user wanted and having to throw all of that work away

Incremental Only

this is basically mini-waterfall

Incremental & Iterative

Allows user to interact with a single stock with a static index and static date/time range instead of building date/time controls and include only fixed links instead of a synopsis

Next iteration provides user with index selection and date range controls

Final iteration allows user to select a second stock for comparison and provide synopsis for news events

Finding the Agile That Works for You

...

Scrum + Kanban (Lean) = Scrumban

Resources for Getting Started With Scrum

Help! My Product Owner is MIA!

Meet the Product Owner

What is a Product Owner?

Provides Vision and Boundaries
Customer Facing
Most important role, but toughest to learn
Significant shift for many product organizations: From "getting out in front" to "just-in-time"
No clear incentives: Benefits take longer to realize

Sprints (i.e. Iterations)

A timeboxed effort, in which a team attempts to deliver a potential shippable unit of software.
While it isn't always necessary to ship at the end of the sprint, there should be no reason that you cannot ship at this point
Sprints tend to be 1-week in length, up to 4-weeks in length; though, 2-weeks is the most common for most teams
It's not as important which sprint-length is choosen; it's more important that the sprint-length be consistent and the team is comfortable with it

The Product Owner and The Team

outside team

inside team (improves odds of success)

The Product Owner is responsible for gather feedback

Feedback is necessary in order to Iterate

Problem: My Product Owner Isn't Available

This can typically happen when the product owner is a high-ranking executive and simply doesn't have time to work with the team
Product Owner works remotely AND doesn't make the effort to interact with the team on a daily basis or the product owner simply refuses to participate in the process

Symptoms

Product Owner doesn't attend meetings (Daily Standups & Sprint Planning)
Only communicates electronically (i.e. Email, Jira)
Feedback arrives too late for team to act on it
Feedback requires clarification which never comes or arrives too late for team to act on it
Not engaged during demos
Provides feedback offline/asyncronously (lack of engagement)

Solution

Proxy Product Owner: gives someone on the team authrity to make decisions on behalf of the product owner
Work with the product owner to choose the correct individual
Can be a more junior person or could be a developer on the team with an affinity for product ownership
Establish boundaries: Which decisions can proxy make on their own and which will they need to consult with product owner for

Advantages

Builds an appreciation of the business
Shares the customer's perspective
Buildes product owner skills in others

Disadvantages

Will impact the proxy's time
Proxy may not have role power
Can lead to "tunnel-vision" backlogs
May have blind-spots
May not have power or authority necessary to affect certain decisions in the organization
True product owner needs to be conscious of not overriding the proxy's decisions too often in front of the team

My Product Owner Is Falling Behind

Appears engaged, but, is often unprepared for those meetings
Doesn't get back to team with answers in a timely fashion
Unable to answer questions from the team
Backlog isn't ready for planning sessions
Stories are incomplete

Siren Solution: Multiple Product Owners

Avoid trying to solve problems this way
No unified vision for the product
No clear authority for the team
If two product owners exist and they tend to give different answers to questions, team will tend to go to the product owner that will give them the answer they want and not necessarily the answer that is best for the product/customer

Solution: Share Product Owner's Responsibilities

Scrum Master (Agile Coach: Kanban) helps with backlog grooming
Developers help with story writing (work with product owner: standard weekly session)
Testers can help with defining acceptance criteria
Make a list of product owner responsibilities and decide who can help with each one

Advantages

Spreads product knowledge across the team
Builds Product Owner skills in others
Product Owner is no longer a single point of failure

Disadvantages

Difficult to coordinate
Beware of Product Owner becoming simply a reviewer
Will impact the workload of other team members

My Scrum Master Is My Product Owner

One person tries to serve both the Scrum Master and Product Owner Roles
May not have access to customer in order to get feedback which is necessary to iterate
Team may be engaging in low value work

Solution: Coach Up a New Scrum Master

allow current scrum master to focus on product ownership

Current scrum master must now think long term
Opportunity to coach up another scrum master from within the team

Resources

Agile Product Management with Scrum by Roman Pichler

Meeting Hard Deadlines While Staying Agile

Finding the Constraints of Your Project

Finding What Fits

Culling Stories to Fit the Release

All stories need to be estimated and prioritized in product backlog
Know points team completed per sprint (velocity)
Know how many sprints are left in release before ship date

Story Points

A way of estimating effort that taking into account time and complexity.

Example

Team is averaging 10 points per sprint (Has a Velocity of 10)
# Sprints remaining in release: 3
Remaining Capacity: ([Velocity] * [# Sprints remaining in release]) = 30

Slicing to Fit

Story slicing lets us slice stories as thin as possible so we can get more stories into a release (albeit with less functionality in each story)
Improves the odds that more high-value stories will be included in each release
Allows getting more work in front of customer at the time in order to get better feedback on the bredth of the entire product
Less re-work

Slicing Stories to Fit the Release

Begin with a prioritized backlog
Start with largest stories

...

Planning Multiple Releases

If we have a predictable release cadence (every six weeks), we can add the relase date to the backlog and stack them with the estimated stories based on how many points we expect to complete per week.
The amount of stories in each release is a function of the number of sprints in that relase and the team's average velocity
Revisit future release plans often
Be flexible with priorities (allow for change)
Understand that release plans are projections and not commitments (the further you go into the future, the more tenuous those projections become)
Planning is an iterative process
Re-estimate the remaining work periodically throughout the release
Keep the estimate high-level (save the detailed estimations for the release planning session)
Revise your release plan as you learn more

When Features Outweigh Deadlines

Features > Deadlines

60 points of work remaining in release
20 points per sprint average
03 sprints remaining

Adjust dates to fit features
If something changes (i.e. developer leaves after 2nd sprint), you have to adjust the plan

30 points of work remaining in release
15 points per sprint average
02 sprints remaining

Instead of 1 sprint remaining, we actually have 02
Projected completion date moves out

Working Without Deadlines

"It'll ship when it's ready"

Bloats the product and deletes the vision
Without deadlines, it's easy to ignore aggressive prioritization (deadlines force prioritization)
Misses the opportunity to make a few carefully selected set of killer features really great, instead, we ship a product with a grab-bag of underwealming features

Squashing Bugs While Keeping Up with New Development

Splitting Our Team Between New Features

Budgeting Our Points

New feature Development
Fixing Bugs
Tackling Techincal Debt

Squashing Bugs

Regularly re-prioritize bug list (at least once per sprint)
Order the bug list by most recently created
The older a bug is, the less relevant it tends to be (often, older bugs refer to features of the app that have been removed or have fallen out of use)
If a bug was reported over a year ago, but no new activity, it probably isn't critical
A bug that was reported just a week ago, it's probaly relevant
Take top 10 bugs, then, figure out how likely it is to occur and figure out impact when bug occurs

Severe & Likely

Mild & Likely

Severe yet Unlikely

Mild & Unlikely

Building a Sprint That Doesn't Leave Old Problems Behind

Building Your Budget

Averaging 50 points velocity per sprint

Spend the majority of points on new development. Use a bug/technical debt balance that makes sense to you. Be flexible.

30 points for new development
13 points for bugs
7 points on technical debt

Here Comes the Fire Department

The Bug Fire Lane

Showstopper bugs have to be fixed immediately

Showstopper Criteria

Lost or corrupted data
Blocks normal workflow
Prevents user access

Moving On

Balancing Bugs and Debt with New Development
Handling high priority bugs after a sprint begins

Scaling Agile Across Multiple Teams

Building the Right Team

Concrete techniques for scaling agile across multiple teams ... Scaling agile is not the same as adopting agile

Strategies for splitting teams
Keeping teams in sync
Sharing knowledges between teams
Build teams around features, not layers

Team Composition

Each team should have all the skills necessary to deliver a complete feating within a single sprint
The advantage of cross-functional teams far outweight the learning curve
Cross-functional teams produce value quicker since there is no hand-off stage between each tier and teams are not blocked waiting for other teams to complete work
More flexible since there is a richer mix of skills present on each team

Sitting Idle

Sitting idle is the best thing for teams to do when there is no high-value work to do: often teams are tasked with low-value work that hasn't been fully thought through; this produces work which in term creates applications for other teams that are already overloaded and creates features that have to be maintained long-term

Additional Roles for the Team

Testing
Operations
User Experience (UX)

Working With Shared Team Members

Working with Shared Team Members

Build relationships ...

Integrate the team member into every meeting
Determine amount of time team member can commit to team (calculate into capacity planning)
Ensure team member attends ALL standard meetings (i.e. standup, sprint planning, demo)

How Big do We want each Teams to be?

7, plus or minus 2

Less than 5 won't have enough skills - teams must deliver features end-to-end
More than 9 are too complex to coordinate - Communication pathways increase exponentially
Should only be used a rule of thumb, not gospel

Amazon Two Pizza Rule

No team should be so big, it can't be fed by two pizzas
More tangible
No lower bound

Few Large Teams or Many Small Teams?

Smallest amount of teams that can still be fed by two pizzas

Don't be afraid to experiment

Forming, Norming, ...

Teams take time to gel
Be patient
Wait 2 to 4 sprints

Planning Work With a Scrum of Scrums

Staying in Sync

Morning Scrums (Daily Scrum, Daily Standup)

No more than 15 minutes
What did I do yesterday, What am I don't today, What's in my way

Scrum of Scrums

Goal is to coordinate work across multiple teams

Keep them High level
On behalf of your team (high-level roll-up)
More "We" language
One Person per Team
Good for team lead to attend this meeting
Hold less frequently (T & TH or MWF) -> Can be daily in some cases if there is enough to go over
This can go 30 - 45 minutes depending on how long it takes to resolve issues
If it goes longer but it productive, that's ok

Learning From Other Teams With a Retrospective of Retrospectives

Retrospectives

What went well?
What didn't go so well?
What should we try next time?

Retrospective of Retrospectives

Focus on Interaction
What has worked well or not so well in each team
Works well in organiznations where all the scrummasters are new
Gain insight from experiences of others
One person from each team attends (best team member is Scrum Master); though, not uncommon for others to attend as well
Hold once per sprint

Growing Communities of Practice

Community of Practice

A group of people who share common interests and meet periodically to exchange ideas or tackle specific problems that may be plauging the organization.

General exchange of information
Members share a common interest
Ongoing or specific problem
Differing levels of participation

Examples

Testers
Interested in Dynamic Languages
How to improve automated test coverage
Automate the deployment process

Encouraging Communities of Practice

Watch for communities to form naturally (encourage group to form community of practice)
Do the same people tend to discuss the same issues at scrum of scrums or retrospective of retrospectives?
Encourage this group to form a community of practice: provide time in schedule, space, food, etc...
Nudge communities into a recurring cadence
Key: self organization
Allow communities to fade if it stops serving a purpose (once it's outlived it's usefulness, let it go)

Scripts I noticed that you, Sally & Jen, stick around after scrum of scrums on most days to talk about our deployment issues, Why don't you setup a standing meeting every two weeks so you can have some dedicated time set aside to give those issues the attending they deserve.

Moving On

Resources of Scaling Agile

Wrapping Up

Ideal team size and composition
Keeping teams in sync
Growing communities of practice

Keeping Teams in Sync

Syncronizing Sprints

Staggering Sprints

The product is never releasable
Sharing team members becomes more complex
Coordinating teams becomes more complex

Syncronizing Sprints

Gives a predictable time when all teams are paused
Sharing team members becomes simpler
Coordinating teams becomes simpler

Nesting Sprints

Possible to mix teams with different priorities
Gives a predictable time when all teams are paused
Differing sprint lengths can be complex

Two Places at Once

Staggering Planning

Some organizations have a single Scrum Master across all teams (use staggered meetings or stagger sprints slightly)
Easy to implement across a few teams
Creates "dead space" in the sprint for each team
Doesn't scale beyond 2-3 teams

Simultaneous Planning

Teams go to opposite sides of a large room and
All sprints kickoff and conclude together
Key people are available for multiple teams at once
Encourages cross-pollination
It's fun
Doesn't work for shared Scrum Masters who may be coaching multiple teams
New Teams aren't yet at the stage where they can facilitate themselves

One Backlog per Product

One Backlog per Product

Can use filters (must be using an electronic tracker tools, does not work for a physical board)
Disadvantage: Creates tunnel vision
Can color-code based on team most likely to pick up
Advantage: Works for physical boards, Helps teams easily spot relevant stories
Advantage to product owner: Let's the Product Owner see the "big picture" - All stories are weighted against all others
Advantage to product owner: Helps optimize the work of all teams - Keeps all teams focused on high priority work

One Product Owner Per Team

Faster answers to question
Builds in-depth knowledge
Creates relationships

Chief Product Owner

Owns the vision of the overall product
Prioritizes between features
Works with the customers

Team Product Owner

Advocates for their features
Executes on their features
Works with the teams

wilmoore/readme.md Secret