Let's talk about agility...

We’re losing the relay race

The Agile Manifesto

A statement of values

• Individuals and interactions
       over Process and tools
• Working software
       over Comprehensive documentation
• Customer collaboration
       over Contract negotiation
• Responding to change
       over Following a plan

Predictive planning vs. Adaptive planning

Plan your work and work your plan

Our measure of success is following the plan.

This depends on requirements stability.

The agile shift means breaking that dependency through an approach that is tolerant to change...

"A late change in requirements is a competitive advantage"
- Mary Poppendieck.

In the agile world, we switch to an approach that involves adaptive planning.

Process-first
vs.
People-first

Scientific management states that a separate group of people decide what process people should follow, and the people then conform to that process.

This depends on predictable behaviour.

But... people often work in non-linear, variable ways.

The agile notion is to reverse the approach.

People come first and they then choose the process that is most effective for them to follow.

Scrum

A type of Agile

Scrum in 100 words or less

• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
• Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

First, a disclaimer...

Agile processes, at their essence, are pretty strict; what follows may seem pretty rigid, but the general ideas are what should be of interest and of use.

Characteristics of Scrum

• Self-organizing teams
• Product progresses in a series of “sprints”, which are typically 2-4 weeks long
• Requirements are captured as items in a list called the “product backlog”
• No specific engineering practices prescribed
• One of the “agile processes”

Putting it all together

Sprints

• Scrum projects make progress in a series of “sprints”
• Typical duration is 2–4 weeks or a calendar month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the sprint

Sequential vs Overlapping

No changes during a sprint

• Plan sprint durations around how long you can commit to keeping change out of the sprint

This is a good take-away point as it puts good emphasis on better upfront requirements capturing, planning and design

Roles...

Product owner

• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritise features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results

The Scrum Master

• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close co-operation across all roles and functions
• Shield the team from external interferences

The team

• Typically 5-9 people
• Cross-functional (e.g. Programmers, testers, user experience designers, etc)
• Members should be full-time
• Teams are self-organizing
• Ideally no titles or hierarchy within the team (can be exceptions e.g. sign-off / approval etc)
• Membership should change only between sprints

Ceremonies (Events)...

Sprint Planning

• Product owner keeps a backlog, that they prioritise, of user stories
• These are high level, are user-centric (though note different types of "users"), and are non-prescriptive as to implementation (that's up to the team)
• Team selects items from the product backlog they can commit to completing to create a sprint backlog
• The team then turns the user stories into tasks, which is a colloborative effort allowing peer input

Sprint Planning Continued...

• Tasks should be no longer that 16 hours; if they are then they can be further broken down
• This process allows tasks to be well defined and help to pre-empt gotchas and identify dependencies ahead of time
• Estimate tasks based upon any member of the team doing the work (not just the most skilled)

Example

• User story:
  As a vacation planner, I want to see photos of the hotels.
• Tasks:
  Code the middle tier (8 hours)
  Code the user interface (4)
  Write test fixtures (4)
  Code the foo class (6)
  Update performance tests (4)
  

Daily Standup

Everyone answers 3 questions

• What did you do yesterday?
• What will you do today?
• Is anything in your way?

This is also a good time to update the task board (though that should be kept up-to-date as things go), with blocked tasks being put to the side

These are not status for the ScrumMaster. They are commitments in front of peers

The sprint review

• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world

This concept of a demo is a good takeaway point, as it provides a good opportunity to show others what is being built as well as providing a starting point to show how to use something etc.

Sprint retrospective

• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates

Artifacts...

Product backlog

• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or customers of the product
• Prioritised by the product owner
• Reprioritised at the start of each sprint

Managing the sprint backlog

• Individuals sign up for work of their own choosing - work is never assigned
• Estimated work remaining is updated daily

Sprint burndown

Teams use the sprint Burndown chart to track the product development effort remaining in a sprint. Generally the Burndown chart should consist of: X axis to display working days. Y axis to display remaining effort. Ideal effort as a guideline.

Now you know more about Agile!