4. Concept: Sprint
• Fast. (not paced)
• Time. (not distance)
• Loop. (repeat until done)
Synonyms: Time Box, Iteration (iterations are loops, not always time boxed) (time boxes constrain the schedule but are
not always iterative)
Traditional Projects are like a relay race, with a passing of the baton between phases to different runners (activities) who cover the same distance (scope).
What if I wanted to collapse the relay into a single “lap”, with all four runners running at the same time, and their “collective” times added end to end to be
their overall score. Well the race would get done much faster, but the competition would be different, as the overall “lead” would be harder for individual
runners to discern. The strategy would change.
We all know that in projects, the hand-offs or phases represent real “dependencies” that cannot simply be “swept away” because it would be desirable to
execute in parallel rather than in dependency order.
To have activities that are normally dependent on each other executed concurrently, requires a different strategy rather than a hand-off – it requires
collaboration.
NTAC:3NS-20
5. Concept: Collaboration
• Together. (not individually)
• Accomplishment. (not busy-ness)
Strategies:
• Pairing – two working together is always better than one, as they can keep each other on
task, and review each other’s output. Two sets of eyes, two sets of ideas.
• Swarming – Dividing the work into the smallest of increments and applying the entire team
in parallel as much as is possible.
In our world of individualization, individual incentivization and individual rights and freedoms, being forced to work together with one or
more others often feels like a constraint. Remember those group projects from school? Remember the guy who did nothing and got an A off
the sweat and diligence of others? Like that.
This shouldn’t be like that, at least not for long. Pairs of people working together learn from each other, encourage each other. The team of
mountain climbers is only as strong as the weakest climber – so overall they are constrained to go at his pace. When we build this premise,
the team gets stronger… one way or another. There is no hiding in this world, nor are there superstars. Only the team.
The need for working together, creates a dependence on accountability.
NTAC:3NS-20
6. Concept: Accountability
• Commit. (not estimates)
• Measure. (distance over time)
• Reflect. (attribution and adaptation)
Accountability to self (team) for accomplishment.
Agile teams don’t wait for the boss to yell before changing how they work. They own the work and the process so they evolve and adapt until
they are predictable (measurements match commitments). Then they continue to evolve to accomplish more with less risk.
At each sprint, agile teams commit to a certain amount of accomplishment. They measure their accomplishment every day throughout the
sprint. They reflect on factors that increased or decreased accomplishment, deciding to make some small incremental change to their process
to reproduce the increase or prevent the decrease.
The accountability strategy is enforced by shortening the cadence of feedback loops.
NTAC:3NS-20
7. Concept: Cadence
• Prepare. (planning is preparation)
• Steer. (daily status is for steering)
• Demonstrate. (evidence of accomplishment)
• Adapt. (decide to improve)
Agile teams grow confidence (internal) and trust (external) by producing evidence of accomplishment.
Preparation and steering are just a means to that end. Every sprint has its “showcase” where stakeholders can observe evidence of accomplishment.
Project status is not a document – it is a demo.
If it isn’t done enough to demo, it isn’t done. There is no partial credit. Agile is Pass/Fail. Either it shows or it blows. There is no hiding in this model.
Every sprint has a start where we prepare. Preparation feels like planning, we know what to do, how to do it, and who is going to do it. We understand the
dependencies.
Every day we meet to talk about progress, what is done, what is next. As a team, we contemplate obstacles that emerge and how we will overcome them.
When the time is up we show anyone who is interested how much progress we have (or haven’t) made in complete transparency. No spin, no opining, no
excuses.
When we are done showing off, we come back to reflect and decide one thing that should change.
In order to satisfy the cadence of frequent planning and steering, priority and dependency must be reduced to a simple sequence.
NTAC:3NS-20
8. Concept: Sequencing
• Rank. (not prioritize)
• Divide. (deliverable into smaller chunks)
• Assign. (pair or person per chunk)
• Control. (work in progress)
Agile teams work on the LEAST number of deliverables that can fully occupy the team.
The only way to ensure that the team finishes the sprint with something to show is to control how many things the team can start.
Working on the most important one deliverable first before starting the second most important deliverable ensures that if we don’t finish everything, we
WILL finish the most important things. There is only one sin worse than finishing a sprint with nothing complete and that is finishing a sprint with more than
one thing started and not complete.
Everything is a high priority, but not everything is #1. There can be only #1. Even if the decision is completely arbitrary, it is a decision, and it brings the
ability to focus on something, and removes the ability of other things to distract.
The way this all works together reduces the time-span of decisions made within the team to two sprints at the maximum. Longer time-span decisions are
made outside the team at the program level.
NTAC:3NS-20
10. Application: Product Ownership
Product Ownership is the ability to define and
sequence the deliverables for the team.
• Agile deliverables are traditionally formed as “user stories”, “features” – but what is important is to define a body of work,
and formalize the definition of done for that body of work. (sounds a lot like business requirements).
• Evolving a standard practice for describing a body of work, and what it means for that work to be done is the responsibility
of the team, lead by the product owner.
• The product owner is accountable to the stakeholders for the value that the team delivers.
• The stake holders invest their decision rights for “steering” in the product owner.
• The product owner executes this responsibility by dividing the work in to smaller “atomic” bodies of work and by
rationalizing a sequence for the work.
• The list of atomic bodies of work and the sequence is traditionally called a “backlog”.
NTAC:3NS-20
11. Application: Estimation
Estimation is often necessary for teams to
Commit work in a sprint.
• If the team is comfortable committing without estimation, do it.
• Every team must come up with their own estimation framework. No two teams work the same way.
• Estimation needs to produce a predictable response to one question: What are we going to demo next Wednesday?
• Estimation at the atomic deliverable level can be different than at the “task” level.
• Estimation can use effort based units or mythical units.
• Teams that are fearful of transparency may opt to start with mythical units because it feels safe.
• Nothing is ever safe, because its still all about next Wednesday.
• Estimation is tied to work breakdown and to activities that the team executes.
• No two teams conceive work breakdown or activity assignments the same way.
• Estimates are probabilistic guesses. Some number of units within some range of probability.
• Estimates can use reference frameworks (looking at a reference unit, and reflecting how much bigger or smaller).
• Estimates should not give a false sense of fidelity – (i.e. is 3.75 hours +- 3.75 hours is ridiculous)
• Many teams use a Fibonacci sequence to ensure that fidelity is relative to the size of the estimate.
(1,2,3,5,8,13,21,34,55,89)
• Agile teams specify a size limit beyond which a deliverable or task must be divided.
NTAC:3NS-20
12. Application: Velocity
Velocity is accomplishment per unit time.
• Time units align with sprints. Whatever length the team decides they want to sprint, becomes the denominator of velocity.
• Accomplishment units are estimation units or deliverables if no estimates are given.
• Commitment is a projection, velocity is a measurement – they are not the same.
• Some teams like to use prior velocity to project commitment.
• Velocity does not care about effort, billing, overtime, or activities that are not related to delivery.
• Velocity does not care about individual performance.
• Velocity only considers completed deliverables and elapsed time.
• Velocity is mean.
NTAC:3NS-20
13. Application: Physical Percent Complete
Physical Percent Complete is the sum of
completed tasks within a deliverable.
• When considering how much work is left in a deliverable at the end of a sprint (for preparation purposes) only completed
tasks are counted.
• Agile teams have small atomic tasks, that are either done or not done.
• When a small task in progress remains undone for two consecutive daily checkpoints the team should investigate.
• This helps the team stay accountable.
• This supports summarization of remaining and completed work within a deliverable or committed deliverables for a sprint.
• We care about physical percent complete because…
• Not everything that takes time is a task.
• Not everything that team members do is part of a deliverable.
• Not everything that team members do correlates with this project.
• Measuring how much time past is not a predictor of how long something will take to finish.
• Measuring how much effort remains undone is not a predictor of how long something will take to finish.
NTAC:3NS-20
14. Application: Leadership
Agile teams are self organizing, Leadership
facilitates decisions.
• Minimizing leadership “touches” maximizes shared accountability.
• Leadership ensures that decisions are made.
• Leadership ensures that principles are honored.
• Leadership proposes ways to remove obstacles.
• Leadership asks questions that illuminate the way forward.
• Management is about constraining and assigning. Agile teams do these things
collaboratively.
NTAC:3NS-20
15. Application: Reflection
Agile teams encourage members to think about
what they can change to improve.
• By frequently considering ideas for improvement, the team creates its own optimism.
• By listening to each others ideas, the team builds mutual respect and trust.
• By finding common ground, discussion of change does not create anxiety.
• By shortening the feedback loop for ALL activities the team does, opportunities emerge.
NTAC:3NS-20
16. Application: Adaptation
Agile teams change in small ways.
• Its hard to know if any specific change makes a difference when you are changing
EVERYTHING!
• If we agree only to make the most important or impactful changes, we won’t waste time
changing things that don’t matter.
• Team members already know what isn’t working well.
• Giving the team permission to walk stepwise together from the status quo is lower risk than
any change imposed from the outside.
• Keeping track of adaptations can improve the team’s confidence.
NTAC:3NS-20