AGILE ESSENTIALS

A ONE-DAY BLITZ THROUGH AGILE FOR YOUR TEAM

IMAGE SOURCE: http://io9.com/5640510/a-chilean-satellite-fires-a-laser-into-space-to-create-a-virtual-star-in-the-heart-of-the-milky-

10:00 to 11:15

What Agile Is and Isnt (Agile History)

10:30 to 11:00 11:00 to 11:15

Agile History Lab Lab Discussion

O N E D AY

AGENDA

12:30 to 2:45

Common Agile Practices

1:30 to 2:15 2:15 to 2:45

Agile Practices Lab Lab Discussion

2:45 to 4:00

Agile In Action
2:45 to 3:45 3:45 to 4:00

Agile In Action Lab Discussion

WHAT AGILE

IS (AND ISNT)

2014 DC Strategic Consulting, LTD.

Incremental Development at IBMs Service Bureau Corporation

1957

NY Telephone Companys Systems Development Center

1974

Scrum methodology presented at OOPSLA in Austin, Texas.

1995

NOT NEW

AGILE IS

2001

The signing of the Agile Manifesto in Snowbird, Utah.

Rational Unified Process created by the Rational Software Corporation

Extreme Programming @ Chrysler C3 with Kent Beck

1996

1996

Process

Sequence of activities, people, and systems involved in carrying out some business or achieving some desired process.

Methodology

An organized, documented, set of procedures and guidelines for one or more phases of the software lifecycle.

NOT A PROCESS
Pattern
a standard way of moving, acting, etc a model worthy of imitation.

AGILE IS

We value individuals and interactions over processes and tools.

Individuals and Interactions Working software

We value working software over comprehensive documentation

A MANIFESTO
We value customer collaboration over contract negotiation.

AGILE IS

Customer Collaboration Responding to Change

We value responding to change over following a plan.

SOURCE: http://agilemanifesto.org/

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

A SET OF PRINCIPLES
8
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

AGILE IS

2
3 4 5

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress.

9
1 0 1 1

6
7

1 2

SOURCE: http://agilemanifesto.org/principles.html

Crystal Extreme Programming Lean Software Development Scrum-Lean

Kanban Adaptive Software Development

Agile Modeling Disciplined Agile Delivery Standard & Poors

Feature Driven Development

Scrum Scrum-ban Recipe for Success Test Driven Development Lean Thinking

EVOLVING

AGILE IS

AGILE IS A COMMITMENT
TO DO WHAT WORKS AND LEAVE BEHIND WHAT DOESNT

LAB

IMAGE SOURCE: http://pichost.me/1491615/

COMMON AGILE PRACTICES

2014 DC Strategic Consulting, LTD.

TYPICAL CEREMONIES
Chartering
Usually performed quarterly, this session determines the team work focus and values.

Backlog Grooming
The team reviews its list of work and modifies to reflect shifts in priority and work direction.

Story Mapping
Usually performed in tandem with chartering, the team maps work items to features, programs, and organizational objectives.

Iteration Planning
In Scrum variants, the team identifies which stories from the backlog will be worked in the next iteration.

Standup
A short (15 minute) daily meeting where team members discuss current work and blockers.

Retrospective
At the end of each iteration, the team discusses issues and successes, and plans for how to improve.

STANDARD ARTIFACTS
Story
A work-sized unit of business value with clear acceptance criteria, enabling a concrete definition of done.

Epic
An expression of business value that is too large; it must be broken down into stories before the team begins work.

Task
An explicit work item (generally taking a day or less) to deliver a story.

Defect
An issue found while testing a feature or function. A demonstration of behavior deviating from expectation.

Request
A request for work to be performed by the team from an external source.

Test
A manual and/or automated means of exercising a feature/product to identify differences between expected and actual behavior.

COMMON ROLES

Product Owner
Represents stakeholders to the team and vice versa. Responsible for primary creation/maintenance/prior itization of work list (backlog). Product Manager Business Analyst

Team Member
Responsible for extended analysis, code, design, test, modeling, and release activities.

Team Lead
Can be a rotating/shared role. Responsible for meeting facilitation, resourcing, and running interference on organizational issues. Project Manager Scrum Coach Architect
Icons from: http://iconka.com/cat-force/

Developer QA Analyst Architect

Business Analyst

Who needs this?

Why do they need it?

Most teams build out personas to describe common users of their features/functionality. Even if there isnt a persona, each story should include reference to who this feature will support. Stories are worked in priority order. In order to determine priority, the product owner and development team have to understand the need for each story. The delivery of each story adds incremental value to a product/feature. The story should express what the perceived value of the increment would be (again, to support accurate prioritization).

Whats the business value?

BUILDING A STORY
Context
Context may be added to the story to enable deeper/richer conversations with the team. Context may be added by team members as they engage with and ask questions about a story. Depending on the methodology the team adopts, there are a number of syntaxes that can help in story development. The Gherkin Syntax is often used by teams looking to ultimately embrace testor behavior driven development. Stories are conversational objects that, at the end of the day, become a form of passive documentation this is what our feature/product/system does. They can also be used to inform/drive development of minimum viable product.
Icons from: http://www.iconarchive.com/show/cat-shadows-icons-by-iconka.html

Syntax
Team Patterns

Estimates are not commitments. Dont be afraid.

SIZING A STORY
When How
Frequently used methods: Planning Poker T-shirt Sizing Comparative Measures (States, Countries, Happy Meal to SuperSized)

What
Estimate stories with agreed upon metrics. Examples of metrics:

Who
It depends. Selforganizing teams tend to include all members; other teams a subset. Choose whats right for your team.

Ratings of Complexity Relative Size Ideal Day(s) Velocity

It depends on your PMO, your project manager, and your contract. My guidance is to size artifacts before their corresponding events: Features > Market Spec Epics > Qtrly Release Planning Stories > Iteration Planning/WIP

IMPORTANT: Dont estimate everything all at once.

Icons from: http://iconka.com/cat-force/

IMPLEMENTING A STORY
Tasks
Tasks are commitments; when you create them and provide estimates you are saying, Ive got this!

Conversations
Every time you make a design decision, a kitten dies. It roughly means: if you have a question, ask it dont assume or make the decision on your own.

Smallest Unit
Everything comes back to the KISS method. Really, keep it simple.

Icons from: http://iconka.com/cat-force/

Automated
Automate as much as you can. Integrate your automation into your build process, and never leave a build broken.

Manual
Practice exploration. Be destructive. Try to break things, and fail in a safe place before releasing to production.

Acceptance
There is no such thing as a release if your work hasnt been accepted by your product owner.

TESTING A STORY
(aka WERE ALL IN THIS TOGETHER)

We all have a role in ensuring the quality of our teams work. All roles test.

Icons from: http://iconka.com/cat-force/

FAIL EARLY. FAIL OFTEN.

START. TRY. DO. FACING ISSUES WITHIN YOUR TEAM IS BETTER THAN FACING ISSUES WITH YOUR CLIENTS.

LAB

IMAGE SOURCE: http://visitcarlingford.com/wp-content/uploads/2013/07/2013-06-28-DancingTheSalsa.jpg

AGILE IN ACTION

( P U T T I N G I T A L L TO G E T H E R )

2014 DC Strategic Consulting, LTD.

LAB