Reach
Consensus on Story Priority – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #16)
> Simple Triage Rule
> Covey’s quadrants
> Value first
> Risk first
> Greatest good to greatest number
> Fixed-length queue
> Bargain
> Alphabetical
--
Compose a simple triage rule, such as bugs before features
or system integrity before functionality.
In First Things First, Covey et al. suggest mapping
significance vs. urgency in quadrants. Do significant urgent work
first, followed by significant nonurgent work.
Maximize return by doing items of highest value first or minimize
risk by doing tasks with greatest risk first. Alternatively, prefer
tasks that offer the greatest good to the greatest number.
Work in a small fixed-length queue of tasks (based on velocity).
If only three things can be done, which are the best three to do?
What if it is only one?
Create consensus with a bargaining system. Give stakeholders each
three votes per iteration. Allow multiple votes per story, vote
trading, and deal making.
Implement stories alphabetically. It is arbitrary, even silly, but
is still better than being blocked by indecision.
Remind all stakeholders that this is an agile work system, so
prioritization is never final. It can be revisited and revised before
each iteration.
Civilization World Wonder quote: "The temple is like no other
building in the world. It has towers and decoration and all the
refinements which the human genius can conceive of."
–Antonio da Magdalena
Thursday, October 17, 2013
Agile in a Flash 15
Embrace
Change – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #15)
> Abandon
> Switch direction
> Defer before investing
> Grow
--
An agile project is not an all-or-nothing proposition and is not heavily vested in a planned future. It is planned incrementally as the product is being built and released. In Extreme Programming Explained, Kent Beck described four options this style provides:
Abandon. Skip further development or even abandon the product itself. Working software is provided in every iteration, and users gain early experience using it. It is easier to stop when it is “done enough” or if it doesn’t seem profitable to continue.
Switch direction. Change direction if the original plan doesn’t match current needs. An agile project may accommodate change even late in the development process.
Defer before investing. Do this so that the features with more immediate payback may be built first. Incremental design allows the organization to choose where, when, and whether to spend their software development money.
Grow. Do this to take advantage of a market that is taking off. This includes building scalability, extending popular features, or driving the product into new problem domains. The business can continue development as long as new features will provide value to them.
Civilization World Wonder quote: "For it soars to a height to match the sky, and as if surging up from amongst the other buildings it stands on high and looks down upon the remainder of the city, adorning it, because it is a part of it, but glorying in its own beauty."
–Procopius, De Aedificis
Agile in a Flash by Jeff Langr and Tim Ottinger (card #15)
> Abandon
> Switch direction
> Defer before investing
> Grow
--
An agile project is not an all-or-nothing proposition and is not heavily vested in a planned future. It is planned incrementally as the product is being built and released. In Extreme Programming Explained, Kent Beck described four options this style provides:
Abandon. Skip further development or even abandon the product itself. Working software is provided in every iteration, and users gain early experience using it. It is easier to stop when it is “done enough” or if it doesn’t seem profitable to continue.
Switch direction. Change direction if the original plan doesn’t match current needs. An agile project may accommodate change even late in the development process.
Defer before investing. Do this so that the features with more immediate payback may be built first. Incremental design allows the organization to choose where, when, and whether to spend their software development money.
Grow. Do this to take advantage of a market that is taking off. This includes building scalability, extending popular features, or driving the product into new problem domains. The business can continue development as long as new features will provide value to them.
Civilization World Wonder quote: "For it soars to a height to match the sky, and as if surging up from amongst the other buildings it stands on high and looks down upon the remainder of the city, adorning it, because it is a part of it, but glorying in its own beauty."
–Procopius, De Aedificis
Agile in a Flash 14
Incremental
Everything – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #14)
> Build/groom a prioritized feature backlog
> Select stories for iteration
> Develop in a timebox (one week to one month)
> Certify release candidate
> Release to production
> Retrospect
> Repeat
--
For an agile team, incremental development applies both to product and to workflow. Most teams begin with a project plan that follows the outline presented here.
The customer first puts together a prioritized list, or backlog, of desired features for upcoming product releases. The list is neither final nor comprehensive. Acceptance tests are written for the most immediately needed features.
Each iteration is a fixed-length period of development. At the outset of each iteration—no sooner—the team and customer agree on what will be delivered. During the iteration, the customer clarifies decisions and answers questions. At the end of each iteration, the team certifies the release candidate by demonstrating it passes all acceptance tests so far. The (partial) product may then be released to production. Also at iteration’s end, a team holds a retrospective to determine how to improve the work system or the product so that future iterations will have higher quality and functionality.
The next iteration then repeats the whole process but includes the retrospective-inspired changes. These changes will evolve the software development practice even as the product grows. Agile teams are always trying to build a better future, both for the customer and for themselves.
Civilization World Wonder quote: "Most of us can, as we choose, make of this world either a palace or a prison."
–John Lubbock
Agile in a Flash by Jeff Langr and Tim Ottinger (card #14)
> Build/groom a prioritized feature backlog
> Select stories for iteration
> Develop in a timebox (one week to one month)
> Certify release candidate
> Release to production
> Retrospect
> Repeat
--
For an agile team, incremental development applies both to product and to workflow. Most teams begin with a project plan that follows the outline presented here.
The customer first puts together a prioritized list, or backlog, of desired features for upcoming product releases. The list is neither final nor comprehensive. Acceptance tests are written for the most immediately needed features.
Each iteration is a fixed-length period of development. At the outset of each iteration—no sooner—the team and customer agree on what will be delivered. During the iteration, the customer clarifies decisions and answers questions. At the end of each iteration, the team certifies the release candidate by demonstrating it passes all acceptance tests so far. The (partial) product may then be released to production. Also at iteration’s end, a team holds a retrospective to determine how to improve the work system or the product so that future iterations will have higher quality and functionality.
The next iteration then repeats the whole process but includes the retrospective-inspired changes. These changes will evolve the software development practice even as the product grows. Agile teams are always trying to build a better future, both for the customer and for themselves.
Civilization World Wonder quote: "Most of us can, as we choose, make of this world either a palace or a prison."
–John Lubbock
Agile in a Flash 13
Don't
Get Too Deep in Technical Debt – The Idea
Agile in a Flash by Jeff Langr and Tim Ottinger (card #13)
Technical debt is technical work deferred as a business decision,
but it quickly becomes a serious business problem.
> Development slows down
> Interest-only payments don’t help much
> Paying early and often is wise
> Bankruptcy is a dire option
> Have a workable plan to pay it off
> Those deep in debt can’t imagine life without it
--
Development slows down. Soon even simple changes take too long and are accompanied by defects that slow the release of new features.
Interest-only payments won’t help. Checking in new code with high quality isn’t enough. Developers must test and clean up the existing code they touch to avoid entrenching bad code.
Paying early and often is wise. The best way to combat it is via TDD-supported refactoring (more on this subject in a later card). Unit tests build confidence for continual, incremental code cleanup.
Bankruptcy is a dire option. Debt can get so bad that the only option seems to be to rewrite the entire system. Rewrites tend to be unexpectedly slow and expensive. They seldom reach functional parity with the original.
Have a workable plan to pay it off. Rework will require time and effort from developers, which has an opportunity cost. Plan payment timing and get buy-in from stakeholders before accruing technical debt.
Those deep in debt can’t imagine life without it. If you think software is always full of hacks and unneeded features, you may be an addict. Beat the mind-set, and eliminate your debt through collaborative refactoring. More on that in a later card.
Civilization World Wonder quote: "...who drinks the water I shall give him, says the Lord, will have a spring inside him welling up for eternal life. Let them bring me to your holy mountain in the place where you dwell. Across the desert and through the mountain to the Canyon of the Crescent Moon..."
–Indiana Jones
Agile in a Flash by Jeff Langr and Tim Ottinger (card #13)
Technical debt is technical work deferred as a business decision,
but it quickly becomes a serious business problem.
> Development slows down
> Interest-only payments don’t help much
> Paying early and often is wise
> Bankruptcy is a dire option
> Have a workable plan to pay it off
> Those deep in debt can’t imagine life without it
--
Development slows down. Soon even simple changes take too long and are accompanied by defects that slow the release of new features.
Interest-only payments won’t help. Checking in new code with high quality isn’t enough. Developers must test and clean up the existing code they touch to avoid entrenching bad code.
Paying early and often is wise. The best way to combat it is via TDD-supported refactoring (more on this subject in a later card). Unit tests build confidence for continual, incremental code cleanup.
Bankruptcy is a dire option. Debt can get so bad that the only option seems to be to rewrite the entire system. Rewrites tend to be unexpectedly slow and expensive. They seldom reach functional parity with the original.
Have a workable plan to pay it off. Rework will require time and effort from developers, which has an opportunity cost. Plan payment timing and get buy-in from stakeholders before accruing technical debt.
Those deep in debt can’t imagine life without it. If you think software is always full of hacks and unneeded features, you may be an addict. Beat the mind-set, and eliminate your debt through collaborative refactoring. More on that in a later card.
Civilization World Wonder quote: "...who drinks the water I shall give him, says the Lord, will have a spring inside him welling up for eternal life. Let them bring me to your holy mountain in the place where you dwell. Across the desert and through the mountain to the Canyon of the Crescent Moon..."
–Indiana Jones
Subscribe to:
Posts (Atom)