Agile and Scrum

Agile

The agile approach was popularized by the Manifesto for Agile Software Development, which outlines values and principles. These underpins a broad range of software development framework, including Scrum and Kanban.

Historically, in 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss these lightweight development methods: Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Robert C. Martin, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, and Steve Mellor. Together they published the Manifesto for Agile Software Development.

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.

Jim Highsmith, History: The Agile Manifesto

Agile Software Development Values

• Individuals and interactions over processes and tools: Tools and process are important, but it is more important to have competent people working together effectively.
• Working software over comprehensive documentation: Good documentation is useful, but the main point of development is to create software, not documentation.
• Customer collaboration over contract negotiation: A contract is important but not a substitute for working closely with customers to discover what they need.
• Responding to change over following a plan: A project plan is important, but it must not be too rigid to accomodate changes in technology or the environment, stakeholders' priorities, and people's understanding of the problem and its solution.

Agile Software Development Principles

Twelve principles:

1. Customer satisfaction by early and continuously delivery of valuable software.
2. Welcome changing requirements, even in late development
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continous attention to technical excellence and good design
10. Simplicity - the art of maximizing the amount of work not done - is essential
11. Best architecture, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Scrum

Definition

A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built in. One of the mantras of scrum is "inspect and adapt," and scrum teams are characterized by an intense focus on continuous improvement - of their process, but also of the product

Johnson Sims, Scrum: A breathtakingly brief and agile introduction

Core principles of Scrum:

1. Ship and share: get your product into other people's hands on a regular basis, whether that's end users, Beta testers, or even just a few discerning friends. Otherwise, you could be wasting time on a feature or product no one wants.
2. Prioritize productivity, and quantify it: The most important short-term metric is productivity, meaning how much valuable work you are getting done each week.
3. Self-reflection and meaningful iteration: a big part of improving your productivity, income, and happiness involves taking a close look at yourself, your process, and your plans on a regular basis.

How-to

The Sprint

A sprint is a set period of time devoted to a very defined goal, such as adding a new feature to your app or debugging. Everything done in the sprint should be deeply focused towards making that goal a reality.

A sprint is usually between one and four weeks.

Example ¹

Daily Scrum (5 minutes)

When you plan to complete a tsak one day but it doesn't happen, you use that opportunity to figure out what went wrong and then improve your process. Daily scrum helps make that happen.

Content:

• Yesterday's progress
• Today's plans
• Anything that is blocking the productivity

A technique for running daily scrum for one person¹: Record a short (45s) video every morning in place of the stand-up meeting:

1. Review: Start by watching yesterday's video, paying attention to what you said you were going to accomplish
2. Reflect: Didn't reach yesterday's goal? Think about why it didn't happen and what you could have done better.
3. Rehearse: For a less than a minute or two, rehearse today's video. Answer with a couple of sentences for each question regarding what did you do yesterday, what are you going to do today, and what's been blocking you. Example: "Yesterday I created screenshots for hearEQ V2.2.0 and updated all the App Store meta information. Today I’ll update my press list, write a press release, and then meet with a music teacher to discuss Waay. For blocking, it took way too long to make the screenshots, and so I didn’t get to the press list as I’d planned to. Next time, I should look into speeding things up with fastlane!"
4. Record the video on your phone

Story Time (30-45 minutes)

Story Time is when you put on your CEO hat and start thinking big-picture.

During Story Time, I’ll review feedback from users, brainstorm app features I’d like to add, and consider how I might want to pivot the apps (or even the company). This is also the time that I’ll think about new apps or abandoning old ones. Then I’ll come up with some concrete ideas and add them to a special list called the Product Backlog.

Product Backlog

The Product Backlog is an ordered list of big-picture tasks. This will be the first place you’ll look when deciding on your goal for the next sprint. But just as important as it is to add new tasks to your backlog, Story Time is about revising and rearranging what’s already there.

Last Day of the Sprint

Making sure you’re on the right path is what the last day of your sprint is all about. It’s a single day (or half-day, if the pressure’s really on) every two weeks where you pull your head up, look around, and make any necessary course corrections.

Three main tasks of the day:

• Retrospective (~2 hours): turn to a fresh page in your notebook and start writing down your thoughts about the past two weeks' productivity. Here's the opportunity to discover what's stopping you from becoming more productive and happy.
  • Some sample questions:
    • What did you accomplish?
    • Did you meet your sprint goal?
    • What worked really well in this sprint? What could have worked better?
    • Are there any productivity blocks that kept croppping up? Review all your daily scrum videos for this information
    • Is there anything that needlessly stressed you out, or that you really enjoyed?
  • Pick two simple things to improve on in your next sprint:
    • One thing to make you more productive
    • One thing to make you happier
• Sprint Plan (~ 2 hours): the goal of this step is to find out what to work on for the next sprint, based on the well-maintained backlog. This also involves estimating and assigning task points to the tasks.
  • Task points are abstract measures used to estimate the size of the task. For instance, one-point task should take about half as long as two-point task on average. In general, task points shoud be on Fibonacci sequence to combat human's tendency to underestimate tasks.
  • Throw hope out of the window and take a cold and calculating look at each task to make a reasonable prediction of how long it will take you to complete.
  • When you are done, add up all the Task Points and compare the sum to what you achieved over your last few sprints.

The Task Board

The board is used to display day-to-day tasks. It can be a physical board, or a virtual one.

The task board can have three columns:

• Todo
• Doing
• Done

Burndown chart

Burndown chart can be used to visualize the progress of the work being done in terms of story point / task point, comparing to the estimation.