PPT from a presentation I give periodically around how to select agile practices within enterprise software delivery teams. Was developed with tons of help from my friend Peter Schuh
1. Agile Practices and Benefits
For Northern Developer Network
By Rich Stone and Peter Schuh
1
2. Agile
• ag·ile (aj-uhl, -ahyl)adj.
– 1. Characterized by quickness, lightness, and ease
of movement; nimble.
– 2. Mentally quick or alert: an agile mind.
2
3. Agile Manifesto
• Individuals and interactions over processes
and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan
3
4. Agile Software Development
• An iterative and incremental (evolutionary) approach
to software development
• which is performed in a highly collaborative manner
• by self-organizing teams within an effective
governance framework
• with "just enough" ceremony
• that produces high quality solutions
• in a cost effective and timely manner
• which meets the changing needs of its stakeholders.
4
5. Agile Methodology?
5
XP, SCRUM, FDD, DSDM, Crystal Clear – are all agile “process frameworks” – that
recommend a group of related practices.
All come from a consulting mind-set, and all have fairly prescriptive approaches
– rather than value selected approaches – so they look like a consultant with a
methodology. Not that they don’t add value, but is it the value you need? Only
you can decide that.
6. Why Agile?
More Value, Higher Quality,
Less Risk, More Predictable,
and yes, More Productive
6
7. Simply Agile
• Recognize that value is a more important driver for
software asset creation than schedule or cost.
• Admit that we don’t/can’t know everything needed to get
done before you start so details can emerge.
• Decentralize decision making to empower the product
team as much as possible, flattening team structures,
replacing command and control with intense collaboration.
• Exercise all your skill areas concurrently to increase
information flow (for the software development system) by
shortening all feedback loops.
• Build, Borrow, Buy automation tooling to make things
easier, faster, more reliable.
7
9. Agile Practices
• We have a list of practices and a bingo card.
• We are going to walk through a list of
practices that are common and valuable.
• If you are on a team that is doing the practice
now, put a chip on your card.
• If you are not sure if you are doing it, ask.
• Questions are valuable – ask away.
9
10. Iteration Zero
Spend a time box to put delivery infrastructure
and product backlog in place (dev
environment, test environment, test and build
automation, user stories, mockups, etc)
Think of it as build a road before we drive the
car.
Improves Predictability
10
11. Continuous Integration
Integrating small bits of completed functionality
into the team codebase many times a day, and
using manual or automated process to ensure
that the codebase is clean after each check-in.
Continuous integration aims to improve the quality,
and to reduce time to deliver, by replacing the
practice of applying quality control to larger
deliverables.
Increases Quality, Reduces Risk
11
12. Walking Skeleton
A Walking Skeleton is a tiny implementation of the
system that performs a small end-to-end
function.
It need not use the final architecture, but it should
link together the main architectural components.
The architecture and the functionality can then
evolve in parallel.
Improves Productivity, Reduces Risk
12
13. Test Driven Development
Test-driven development (TDD) is a software
development process that relies on the repetition
of a very short development cycle:
first the developer writes a failing automated test
case that defines a desired improvement or new
function,
then produces code to pass that test and finally
refactors the new code to acceptable standards.
Improves Quality, Reduces Risk
13
14. Automated Unit Testing
A systemic suite of tests, coded by individual
developers to test at the method level, based
on restorable data, run after each successful
build, to provide immediate feedback on any
new code added to the system.
Improves Productivity, Quality
Reduces Risk
14
15. Simple Design
This is an extension of YAGNI and satisficing (good
enough) design concepts.
Don't design for the ultimate scenario, or anticipate
future needs, design only what is needed for the
current story/requirement.
Works best when used with other practices
including continuous integration, automated
build, refactoring, etc.
Improves Productivity, Value Delivery
15
16. Acceptance Testing
Write tests for each story (requirement) before
development (for that story) is complete.
Acceptance tests are defined by the customer as
the acceptance criteria for the story.
Performed as each story is completed, rather
than at the end of a time box or immediately
prior to release.
Improves Quality, Reduces Risk
16
17. Co-located Team
Seating the entire team in an open-space
environment where conversation can be
overheard, design and analysis sessions
organically emerge, questions can be
answered without anyone leaving their chair.
Improves Productivity, Quality
17
18. Incremental Releases
Release product to production as soon as you
have something of value, rather than waiting
for the entire scope of value to be complete.
Moves the flow of information about value back
to product team and product owner as early
as possible.
Improve Value Delivery, Reduce Risk
18
19. Product Backlog
Sequenced list of features or stories that have
value and effort estimates associated with
them.
Used in all planning exercises
Increases Value Delivery
19
20. Emergent Requirements
Any requirements method that acknowledges
that we don't know everything “up front”.
Starting with what we know, and expecting to
learn more through design, development and
feedback from customers.
Yield requirements that are independent and
can be sequenced.
Improves Value, Productivity
20
21. Emergent Planning
A form of planning, where one works top down,
identifying large chunks of work and estimates
in gross to form a baseline schedule, then
takes a shorter window of time to “elaborate”
the plan in more detail (focusing on the near-
term deliverables), and continues over time.
Improves Predictability, Reduces Risk
21
22. Time Boxing
The time box (iteration, sprint) is the feedback or
measurement cycle of your project.
By choosing short time boxes, you increase the
information flowing into your development
process, so that genuine process improvement
can result.
Requires planning through sequencing and team
commitment of deliverables.
Improve Productivity, Predictability,
Reduces Risk
22
23. Planning Game
Making sequencing (a form of prioritization) of
stories or features into a game.
Designed to reduce emotions in planning.
Goal: put the greatest possible value into
production over the life of the game.
Improves Value Delivery
23
24. Retrospective
In agile development retrospectives play a very
important role in iterative and incremental
development. At the end of every time box a
retrospective is held to look for ways to
improve the process for the next time box.
Improve Productivity, Reduce Risk
24
25. Burn-up/down Chart
A bar chart, or line graph, showing the passage
of time on the X axis, and the remaining work
estimate on the vertical axis.
Useful for determining if the team is burning
work, according to a pre-determined schedule
or commitment (like within a time box)
Improves Predictability
25
26. Other Practices
• The following practices were weeded out,
solely on the basis of our need to restrict the
size of the BINGO card.
• Just sayin’
26
27. Blitz Planning
A single planning activity, attended by members
across the project, that can produce a draft
product backlog, release plan, and
sequencing.
Improves Predictability
27
28. Refactoring
Refactoring is the process of changing a software
system in such a way that it does not alter the
external behavior of the code yet improves its
internal structure.
When developers encounter unnecessary
complexity in the area of code they are working
on, they can simplify and clean the code, thereby
paying down technical debt.
Improves Quality, Reduces Risk
28
29. Automated Deployment
Automated deployment of a build to a user-
configured environment (for example: DEV,
QA, STAGE, PROD) enables early testing of the
system in production-like environments and
drastically reduces the possibility for
migration-based errors.
Reduces Risk
29
30. Solution Sheets
A simplified analysis document that articulates
the essential requirements, business logic
and/or design of a user story prior to its
development.
Improves Predictability
30
31. Kanban Board
A visual, work queue-based approach to
planning and tracking that:
(1) puts the team's value stream at the center of
the development process and
(2) easily communicates prioritization and
ongoing activity across the team and its
stakeholders.
Improves Productivity, Value Delivery
31
32. Effort Estimates
Estimating effort instead of duration:
- not when will I have this done, but how much
of my time will I spend on this specific work.
- allows work to be split across team members,
and estimates to calculate mathematically.
- allows the development of a cost estimate and
a schedule
Improves Predictability, Reduces Risk
32
33. On Site Customer
A practice that engenders a highly-collaborative
environment with speedy turn-around times,
constant adjustment to user-driven feedback
and low documentation. It costs the
dedication of a "super user" and the co-
location of that individual with the delivery
team.
Improves Productivity, Value Delivery
33
34. User Stories
A lightweight, INVEST-based approach to project
features/requirements, making them
Independent, Negotiable, Valuable,
Estimatable, Small, Testable.
Improves Value, Productivity
34
35. Daily Stand
A brief daily whole team meeting (15 min or
less) focused on a simplified status of work in
progress or recently completed.
Helps to identify issues and obstacles, before
any commitments are impacted.
Improves Productivity, Reduces Risk
35
36. Thank You
Thanks for playing along.
We hope that you were able to glean some
valuable nuggets of information.
We hope that you will consider
adopting/adapting some of the practices
presented here for your team’s benefit.
The spreadsheet attached to the invite also has
links to external (to Northern) information
resources regarding Agile Practices
36
Notas del editor
Agile has been around since 2001. Most of us have read some of the literature, or at least laughed at the caricatures.
In 2001 a bunch of consultants got together at some resort and created this manifesto.Many of them had already formed the bases of methodologies that we have heard of that accomplished basically the same thing, but differently.I think these values are interesting, but they don’t tell me what or how, - they don’t even tell me what problem we are solving.
I stole this from Scott Ambler (who now works for IBM Rational) as their “evangelist”…I think it is a concise definition of the “What” of agile – but it is devoid of the why.
If you have ever been a part of a new agile adoption on a team, you will probably recollect that there is something of a backlashOne aspect of all agile processes is that they expose information that sometimes is not pleasant to see.Productivity issues, personal agendas, competence issues are all brought to light. The question is how do we respond to this information?
The major why’s behind agile practices are improvements in value, quality predictability and productivity – The how is because the increased information flow allows us to improve our process and focus on what is important.
Sometimes I feel like our whole project management and SDLC approach to software development completely forgets that we are creating capital assets, and that the value that is instantiated in the software capabilities that we deliver is made less important by our focus onProcess and Documentation.Managing against constraints (scope, schedule, cost).Fiscal Cycles and Budgets.IT delivery can get hung up wanting to use methodology to indemnify itself against blame for not delivering sufficient or needed business value. By the time developers get requirements, the understanding of how the required capabilities actually add value to the business practitioners is often reduced to almost nothing.
We are going to play a game – Just to see if you are paying attention.Cheeseburger (or other form of lunch) will go to the winner.
This really applies to a new product or new team. Here we may start a new project but against existing products. However, sometimes products transition from one team to another (reorg?) – and we need to get established again. Iteration Zero is a way of time boxing start-up cost.
Now that our standard Java and .Net architectures support this, we should take advantage.Usually the way this works, is that within a short time of each check-in, say 15 minutes – the CI server starts a build. Team is notified of build failure. This means that check-in of code that breaks the build can be backed out, or remediated quickly so that it doesn’t impede the rest of the team, or so that some time later, we can’t figure out where things got broke.Last team I was on the rule was fix the build before you go home or bring in donuts….-- many teams attach Unit Test execution to CI build execution, so that if the build passes, it also runs all the unit tests too.
Of course this applies to new systems, but can also be used anytime we are leveraging components that are new, or connecting through new integration points. This is a way to reduce risk of unfamiliarity.This can also be done in lieu of a POC, so that you get a working “something” quickly, that is not completely throw away.
TDD or Test First have been around since the late nineties – If you write the tests before you write the code, and your tests are sufficient to determine working, then when the tests pass you are done – right – well depending on how elegant you want your code to be. If you have the tests, you can refactor to make the code design better without worrying as much about breaking the logic.
If you are doing TDD, this is really essential – a framework like jUnit or nUnit is necessary to automate the testing necessary to make you really productive.
YAGNI – You ain’tgonna need it. - don’t design for cases that are not in scope for the current (release, timebox, story) depending on your delivery vector.Satisficing – (yes this is a word) meaning just good enough and no more. Combines satisfy with suffice - Term was coined by Herbert Simon. He pointed out that human beings lack the cognitive resources to maximize: Key here is that we should not be anticipating future state in our design, other than our capacity to extend towards anticipated requirements. This assumes a low cost and risk associated with extending towards future requirements (as supported by other practices like CI, refactoring, Automated unit testing, etc).
The key take away here is that in agile, we test during each time box, as soon as a story (testable software capability) is complete. Thus we are exercising the testing skill and the development skill concurrently. The information that comes back from testing regarding the quality and usability of our software capability allows us to improve both without extending time.
Having the developers, testers and analysts (and optimally the customer) sitting in the same space, where free collaboration can occur spontaneously is a huge benefit.
We all instinctively know that the feedback that we get from actual users is way more valuable than the feedback we get from product management or testing. Business practitioners are our “real” customer. So the faster we get software capabilities in their hands, the more information we have about the value we have delivered. If they touch nothing until we get all the capabilities built, then no information comes back, and we are stuck defending whatever we did, ‘cuz there are no options left.
If I have a list of all the software capabilities that I have been asked to deliver, in a basic delivery sequence, then as we incrementally deliver these to production, the information that flows back can influence the delivery sequence for future time boxes, and releases.Requests for enhancements that are more valuable than new software capabilities (because we have new information about the business process that we have enabled) can be sequenced ahead of less valuable capabilities.This prevents the delivery of seldom or never used capabilities, while simultaneously our customer clamoring for other things.
Requirements start with a business value to be deliveredOnce we propose a software capability that delivers that business value, we need to understand how that fits in or impacts various processes, and what its usage pattern will be.The faster we deliver design and working code, the more feedback validates and elaborates our requirements.
Depending on the length of our time boxes, and the size of our team we need to plan just enough work to keep the team moving forward.If my feedback loop is short, and we can re-sequence work, then why would I plan activities that I might never complete, in great detail. This does not mean that we do not care about risk associated with some software capabilities, our concern for risk should drive the sequencing – that is we compromise between maximizing value and retiring risk in the early increments of delivery.
If my time boxes are consistent, then the metrics (how much work got completed) helps me tune my commitment along the way. If my time boxes are short (2 weeks) I have lots of time to react even on short projects (3 months or less).
The purpose of the planning game is to have business (customer) and developers interact about what is important. Planning games contemplates not only the deliver of software capabilities, but also release commitments.Cost, Risk, and Value are drivers for planning moves.
Retrospectives are valuable, but sometimes hard to manage. It is usually necessary to select one or two things to focus on, that add the most value or solve the most urgent problems identified. - like every other practice – the more frequently you do it, the faster you get good at it.Process improvement for a working team is somewhat like fixing a motorcycle while your customer is driving down blind alleys at high speed. Have any of you ever worked for Rich Houle??? Uh Huh….
Useful for measuring velocity (rate of estimated work per unit of duration) (e.g. effort days per two week sprint)Also useful because you can see velocity trending up or down over time.-- burn-ups, have the benefit (over burn-down) of being able to expose where sequencing or planning decisions have impacted scope, or where estimate revisions have materially affected the plan.