SOLO:

An Agile

Case Study
JOE CRESPO
@atendesign aten.io
Aten helps tell the
world’s most important
stories.
Joe

Crespo
DIRECTOR OF ACCOUNTS
What are we here to talk about?
Digital projects
are risky
The reality…
1. 39% of all projects succeed

Delivered on time, on budget, and with required features and functions.
2. 43% are challenged

Late, over budget, and/or with fewer than the required features and functions.
3. 18% fail

Either cancelled prior to completion or delivered and never used.
Source: https://www.wrike.com/blog/complete-collection-project-management-statistics-2015/#failure
What are we here to talk about?
1. Take ownership of your digital project.
2. Manage your stakeholders.
3. Get the most out of your team.
What is
Agile?
What is
Agile?
Agile is the common tongue of digital teams
1. 16% of tech teams are pure agile
2. 51% lean towards agile
3. 24% hybrid of agile and waterfall
4. 7% lean towards waterfall
5. 2% are pure waterfall
Survey conducted in 2015.

Source: http://techbeacon.com/survey-agile-new-norm
A common vocabulary and…
Understanding agile principles requires no in-depth technical
knowledge and can help you better understand your product.
“You can have a room full of the best experts but if they
cannot communicate, you will not get anything done.
Thanks to an agile approach we [the SOLO team] have
succeeded in developing our own language and culture
that everyone on the team can understand.
– Pauline L, Product Owner
Agile
Values
The Four Values
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Source: http://agilemanifesto.org/
Not
everything is
a nail
Choose a solution that works
Agile is the New Waterfall

by Amir Yasin
http://bit.ly/new-waterfall
Counterpoint:
Recipes
TODAY’S SPECIAL: SCRUM
Chefs: The Team*
• Product Owner

Sets the direction for the project.
• Scrum Master

Team facilitator, clears blockers for the project, and runs defense
against distractions.
• Team Member

These are the role players on the project: the designer, the
architect, the developer… etc.
* Again, we are focusing on Scrum.
A Few Ingredients
• Epic
• User Story
• The Product Backlog
Ingredient: Epic
High level features of a digital product.
Epic Pitfalls
• Epics are a high-level view of the work. Keep the number of
epics to a human scale. No more than 7-10. If you have
more than that, it will be difficult to get your arms around the
project.
Ingredient: User Story
A discrete feature written from a user’s
perspective with a defined end point or
acceptance criteria.
“As an applicant
I need to share my email address
so that I receive notifications
relevant to me.
“As a [type of user]
I need to [take an action]
so that [I achieve a goal]
“As a [who]
I need to [what]
so that [why]
Story and Acceptance Criteria
As an applicant
I need to share my email address
so that I can receive notifications relevant to me.
1. Create a form that collects email addresses.
2. Create a block that displays that form within a region of the page.
3. Style the block so that it matches the project’s style guide.
Acceptance Criteria
• Keep to the “As a [who] I need to [what] so that [why]” format. You will
be tempted to drop the “as a” and “so that” parts.
• The user should be well-defined. “As a person…” is not specific enough.
• Avoid conjunctions like ANDs and ORs.

Example: “As an applicant, I want to share my email AND read the
privacy policy so that I receive notifications OR opt out of doing so.”
• No more than 5 items in the Acceptance Criteria.
• Sometimes project tasks are just tasks.
User Story Pitfalls
Ingredient: The Product Backlog
This is simply a collection of User Stories, organized by priority.
• Expect the Product Backlog to evolve.
• You will have some low priority stories in your backlog that you will
never actually invest time implementing.
• Do not conflate project launch with completing the Product Backlog.
Product Backlog Pitfalls
Ingredients Recap
• Epic
• User Story
• The Product Backlog
1 2
Directions: Sprints and Ceremonies
Development cycles are
organized around sprints.
Top priorities in the
product backlog are
loaded into the sprint.
Sprints are time-boxed.
1. Sprint Planning
2. Daily Standup
3. Review
4. Retrospective
Sprints The Four Ceremonies
• The team must agree to User Stories that get loaded into the sprint, not
simply assigned work.
• You will be tempted to not honor the time-box.
Sprint Pitfalls
• Stick to them!!
• Keep them short.
• Be agile about agile.
Ceremony Pitfalls
Let’s Get to
Cooking
“This SOLO Team is the Dream Team: it's
small, flexible, each person is the perfect
representative of their role on the boat
yet always reaching out to the other
crew members to see how they can help.
– Pauline L, Product Owner
What is our client

getting right?
Product Owner Mentality
1. Knows her site is a user-centered software product.
2. Regularly reaches out to her audience, not just stakeholders.
3. She is aware that the design/build is the first step and she needs to
maintain the site, as well as refine and extend the site after launch.
Understands Her Users
1. She drew up initial personas prior to our engagement.
2. She keeps her personas on the wall in her office as a constant
reminder.
Manages Stakeholders
1. Takes prototypes to stakeholders to get them involved early.
2. She weighs the importance of all stakeholder requests against the
rest of her Product Backlog.
High Availability
1. She keeps a shared Slack channel open.
2. She is quick to get on a call.
3. Aten uses JIRA as a ticketing management system, and Pauline
works in JIRA alongside the Aten team.
1. Wrote all the initial User Stories prior to our engagement.
2. Sets a business value against each Story.
3. Refines the User Stories with the Aten team and is open to
rewriting, discarding and splitting Stories.
Owns the Product Backlog
“The more the Product Owner understands
the work implied, the better because the
Product Owner is empowered to re-frame,
contribute ideas, make better decisions
for the users, and prioritize the work.
– Pauline L, Product Owner
1. She confirms with the developers that all Stories are development-
ready before investing development time.
2. She insists that the current Sprint’s time-box is honored.
3. She insists that the current Sprint have Planning, Reviews and
Retros.
4. Decisions are delayed so detailed planning is best informed.
Short Term Strict,

Long Term Flexible
She will not agree to any User Story going into a Sprint that does not:
1. have clear Acceptance Criteria associated with it.
2. have story points determining the story’s level of complexity.
Owns Development Sprints
“Everyone knows exactly what they have to do in
order to complete a story and everyone shares
the same vision of what the result will look like.
Transparency, no confusion, no disappointment.
– Pauline L, Product Owner
1. Sprint Planning
2. Daily Standup
3. Sprint Review
4. Retrospective
Joins the Ceremonies
“Our culture has rituals, ceremonies.
They help us know what's coming,
what's expected, they make things
a bit more predictable.
– Pauline L, Product Owner
Ceremony 1
Honestly, this took some trial and error
Planning
1. The entire team meets.
2. We read User Stories from the Product Backlog.

Note: priority and development readiness on User Stories are
determined before Sprint Planning.
3. Thumb voting on each User Story.

Anyone on the team can stop a Story from being loaded into the
Sprint.
Sprint Planning: Our Approach
Ceremony 2
We went async for this
Standup
1. Our Standups are conducted via a shared Slack channel.
2. A daily reminder asks the three questions:
1. What did you do yesterday?
2. What are you doing today?
3. What, if anything, is blocking your progress?
3. Everyone on the team — this includes Pauline — answers these
questions at the start of the workday.
Daily Standup: Our Approach
Ceremony 3
Async, then meet
Review
1. Pauline reviews each User Story on her own in JIRA, either clearing
or reassigning them.
2. The team meets:
1. We high five each other over new functionality
2. We discuss any issues that did not clear Pauline’s review.
3. We count up the story points cleared and move unfinished
Stories to the next Sprint.
Sprint Review: Our Approach
Ceremony 4
Getting honest with one another
Retro
1. The retro asks everyone on the team:
1. What went well?
2. What do not go so well / could be improved?
3. What, if anything, should be added to/removed from our process
in the next sprint?
2. Everyone on the team gets the floor for 90 seconds, followed by an
open discussion that focuses on identifying 2 to 3 improvements.
Retrospective: Our Approach
“This is all about making work visible, I know
exactly where we are in the project and what
remains to get done. Which is essential for
budget planning, stakeholder relations, in
short, the survival of the project.
– Pauline L, Product Owner
Conclusion
SOLO:

An Agile

Case Study
JOE CRESPO

Case study for agile software development:

  • 1.
  • 2.
  • 3.
    Aten helps tellthe world’s most important stories.
  • 5.
  • 6.
    What are wehere to talk about?
  • 7.
  • 8.
    The reality… 1. 39%of all projects succeed
 Delivered on time, on budget, and with required features and functions. 2. 43% are challenged
 Late, over budget, and/or with fewer than the required features and functions. 3. 18% fail
 Either cancelled prior to completion or delivered and never used. Source: https://www.wrike.com/blog/complete-collection-project-management-statistics-2015/#failure
  • 9.
    What are wehere to talk about? 1. Take ownership of your digital project. 2. Manage your stakeholders. 3. Get the most out of your team.
  • 10.
  • 13.
  • 14.
    Agile is thecommon tongue of digital teams 1. 16% of tech teams are pure agile 2. 51% lean towards agile 3. 24% hybrid of agile and waterfall 4. 7% lean towards waterfall 5. 2% are pure waterfall Survey conducted in 2015.
 Source: http://techbeacon.com/survey-agile-new-norm
  • 15.
    A common vocabularyand… Understanding agile principles requires no in-depth technical knowledge and can help you better understand your product.
  • 16.
    “You can havea room full of the best experts but if they cannot communicate, you will not get anything done. Thanks to an agile approach we [the SOLO team] have succeeded in developing our own language and culture that everyone on the team can understand. – Pauline L, Product Owner
  • 17.
  • 18.
    The Four Values 1.Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan Source: http://agilemanifesto.org/
  • 19.
    Not everything is a nail Choosea solution that works Agile is the New Waterfall
 by Amir Yasin http://bit.ly/new-waterfall Counterpoint:
  • 20.
  • 21.
    Chefs: The Team* •Product Owner
 Sets the direction for the project. • Scrum Master
 Team facilitator, clears blockers for the project, and runs defense against distractions. • Team Member
 These are the role players on the project: the designer, the architect, the developer… etc. * Again, we are focusing on Scrum.
  • 22.
    A Few Ingredients •Epic • User Story • The Product Backlog
  • 23.
    Ingredient: Epic High levelfeatures of a digital product.
  • 24.
    Epic Pitfalls • Epicsare a high-level view of the work. Keep the number of epics to a human scale. No more than 7-10. If you have more than that, it will be difficult to get your arms around the project.
  • 25.
    Ingredient: User Story Adiscrete feature written from a user’s perspective with a defined end point or acceptance criteria.
  • 26.
    “As an applicant Ineed to share my email address so that I receive notifications relevant to me.
  • 27.
    “As a [typeof user] I need to [take an action] so that [I achieve a goal]
  • 28.
    “As a [who] Ineed to [what] so that [why]
  • 29.
    Story and AcceptanceCriteria As an applicant I need to share my email address so that I can receive notifications relevant to me. 1. Create a form that collects email addresses. 2. Create a block that displays that form within a region of the page. 3. Style the block so that it matches the project’s style guide. Acceptance Criteria
  • 30.
    • Keep tothe “As a [who] I need to [what] so that [why]” format. You will be tempted to drop the “as a” and “so that” parts. • The user should be well-defined. “As a person…” is not specific enough. • Avoid conjunctions like ANDs and ORs.
 Example: “As an applicant, I want to share my email AND read the privacy policy so that I receive notifications OR opt out of doing so.” • No more than 5 items in the Acceptance Criteria. • Sometimes project tasks are just tasks. User Story Pitfalls
  • 31.
    Ingredient: The ProductBacklog This is simply a collection of User Stories, organized by priority.
  • 32.
    • Expect theProduct Backlog to evolve. • You will have some low priority stories in your backlog that you will never actually invest time implementing. • Do not conflate project launch with completing the Product Backlog. Product Backlog Pitfalls
  • 33.
    Ingredients Recap • Epic •User Story • The Product Backlog
  • 34.
    1 2 Directions: Sprintsand Ceremonies Development cycles are organized around sprints. Top priorities in the product backlog are loaded into the sprint. Sprints are time-boxed. 1. Sprint Planning 2. Daily Standup 3. Review 4. Retrospective Sprints The Four Ceremonies
  • 35.
    • The teammust agree to User Stories that get loaded into the sprint, not simply assigned work. • You will be tempted to not honor the time-box. Sprint Pitfalls • Stick to them!! • Keep them short. • Be agile about agile. Ceremony Pitfalls
  • 36.
  • 37.
    “This SOLO Teamis the Dream Team: it's small, flexible, each person is the perfect representative of their role on the boat yet always reaching out to the other crew members to see how they can help. – Pauline L, Product Owner
  • 38.
    What is ourclient
 getting right?
  • 39.
    Product Owner Mentality 1.Knows her site is a user-centered software product. 2. Regularly reaches out to her audience, not just stakeholders. 3. She is aware that the design/build is the first step and she needs to maintain the site, as well as refine and extend the site after launch.
  • 40.
    Understands Her Users 1.She drew up initial personas prior to our engagement. 2. She keeps her personas on the wall in her office as a constant reminder.
  • 41.
    Manages Stakeholders 1. Takesprototypes to stakeholders to get them involved early. 2. She weighs the importance of all stakeholder requests against the rest of her Product Backlog.
  • 42.
    High Availability 1. Shekeeps a shared Slack channel open. 2. She is quick to get on a call. 3. Aten uses JIRA as a ticketing management system, and Pauline works in JIRA alongside the Aten team.
  • 43.
    1. Wrote allthe initial User Stories prior to our engagement. 2. Sets a business value against each Story. 3. Refines the User Stories with the Aten team and is open to rewriting, discarding and splitting Stories. Owns the Product Backlog
  • 44.
    “The more theProduct Owner understands the work implied, the better because the Product Owner is empowered to re-frame, contribute ideas, make better decisions for the users, and prioritize the work. – Pauline L, Product Owner
  • 45.
    1. She confirmswith the developers that all Stories are development- ready before investing development time. 2. She insists that the current Sprint’s time-box is honored. 3. She insists that the current Sprint have Planning, Reviews and Retros. 4. Decisions are delayed so detailed planning is best informed. Short Term Strict,
 Long Term Flexible
  • 46.
    She will notagree to any User Story going into a Sprint that does not: 1. have clear Acceptance Criteria associated with it. 2. have story points determining the story’s level of complexity. Owns Development Sprints
  • 47.
    “Everyone knows exactlywhat they have to do in order to complete a story and everyone shares the same vision of what the result will look like. Transparency, no confusion, no disappointment. – Pauline L, Product Owner
  • 48.
    1. Sprint Planning 2.Daily Standup 3. Sprint Review 4. Retrospective Joins the Ceremonies
  • 49.
    “Our culture hasrituals, ceremonies. They help us know what's coming, what's expected, they make things a bit more predictable. – Pauline L, Product Owner
  • 50.
    Ceremony 1 Honestly, thistook some trial and error Planning
  • 51.
    1. The entireteam meets. 2. We read User Stories from the Product Backlog.
 Note: priority and development readiness on User Stories are determined before Sprint Planning. 3. Thumb voting on each User Story.
 Anyone on the team can stop a Story from being loaded into the Sprint. Sprint Planning: Our Approach
  • 52.
    Ceremony 2 We wentasync for this Standup
  • 53.
    1. Our Standupsare conducted via a shared Slack channel. 2. A daily reminder asks the three questions: 1. What did you do yesterday? 2. What are you doing today? 3. What, if anything, is blocking your progress? 3. Everyone on the team — this includes Pauline — answers these questions at the start of the workday. Daily Standup: Our Approach
  • 54.
  • 55.
    1. Pauline reviewseach User Story on her own in JIRA, either clearing or reassigning them. 2. The team meets: 1. We high five each other over new functionality 2. We discuss any issues that did not clear Pauline’s review. 3. We count up the story points cleared and move unfinished Stories to the next Sprint. Sprint Review: Our Approach
  • 56.
    Ceremony 4 Getting honestwith one another Retro
  • 57.
    1. The retroasks everyone on the team: 1. What went well? 2. What do not go so well / could be improved? 3. What, if anything, should be added to/removed from our process in the next sprint? 2. Everyone on the team gets the floor for 90 seconds, followed by an open discussion that focuses on identifying 2 to 3 improvements. Retrospective: Our Approach
  • 58.
    “This is allabout making work visible, I know exactly where we are in the project and what remains to get done. Which is essential for budget planning, stakeholder relations, in short, the survival of the project. – Pauline L, Product Owner
  • 59.
  • 61.