PIMP MY AGILE

A quick review

Gulf Agency Company

April 5, 2017
Authored by: Johannes Bichel
 Pimp My Agile
A quick review

Contents
THE GOALS........................................................................................................................................3
EMPOWERED EMPLOYEES..................................................................................................................3
ABILITY TO EVOLVE AND ADAPT..........................................................................................................3
THE MANIFESTO.................................................................................................................................3
12 PRINCIPLES OF AGILE METHODOLOGY................................................................................................3
SCRUM – A FUNDAMENTAL SHIFT..........................................................................................................4
KANBAN – INCREMENTAL IMPROVEMENTS...............................................................................................4
KANBAN VS SCRUM.............................................................................................................................5
LARGE-SCALE SCRUM (LESS).................................................................................................................5
TWO AGILE SCALING FRAMEWORKS....................................................................................................6
WHAT DOES IT MEAN TO BE THE SAME AS ONE-TEAM SCRUM?...............................................................6
WHAT’S DIFFERENT IN LESS?............................................................................................................6
SCALED AGILE (SAFE)..........................................................................................................................7
KEY STONES IN AGILE SOFTWARE DEVELOPMENT..................................................................................7
CREATE YOUR MINIMAL VIABLE PROCESS.............................................................................................7
IMPROVE AGILE TEAM VELOCITY............................................................................................................8
LEVERAGE RETROSPECTIVES...............................................................................................................8
INCREASE PLANNING........................................................................................................................8
ANALYZE CAUSES OF REWORK...........................................................................................................8
LEARN THE CUSTOMER.....................................................................................................................8
IMPLEMENT SMARTER SOLUTIONS......................................................................................................8
AGILE USER STORIES AND GROOMED PRODUCT BACKLOG..........................................................................8
WHAT IS A USER STORY?..................................................................................................................8
HOW TO WRITE A USER STORY?........................................................................................................9
USER.............................................................................................................................................9
BENEFIT.........................................................................................................................................9
WHAT ARE EXAMPLES OF USER STORIES?............................................................................................9
WHAT IS THE TERM INVEST?.........................................................................................................10
WHAT INFORMATION USER STORY MAY CONTAIN?..............................................................................10
Pimp My Agile | 05-Apr-17

WHAT IS A PRODUCT BACKLOG?......................................................................................................10

WHAT IS A GROOMED PRODUCT BACKLOG?.......................................................................................11
WHAT IS AN EPIC?........................................................................................................................11

1
 The Goals
Empowered employees
 Happy engaged employees
 Better solutions and better quality
 United teams

Ability to evolve and adapt

 MVPs and frequent deliveries engages the client and creates transparency
 Feedback to the team(s) creates understanding and purpose
 Ability to change with an ever changing world

The 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

12 Principles of Agile Methodology

The Agile Manifesto lists 12 principles to guide teams on how to execute with agility. These are the
principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
Pimp My Agile | 05-Apr-17

be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity -- the art of maximizing the amount of work not done -- is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly. 

2
Scrum – A Fundamental Shift
Scrum is a well-defined process framework for structuring your work. Introducing Scrum is quite a
change for a team not used to agile software development: They have to start working in iterations,
build cross-functional teams, appoint a product owner and a Scrum master, as well as introducing
regular meetings for iteration planning, daily status updates and sprint reviews. The benefits of the
Scrum methodology are well understood: Less superfluous specifications and fewer handovers due to
cross-functional teams and more flexibility in roadmap planning due to short sprints. Switching your
organization to use Scrum is a fundamental shift which will shake up old habits and transform them into
more effective ones.

Kanban – Incremental Improvements

The Kanban methodology is way less structured than Scrum. It’s no process framework at all, but a
model for introducing change through incremental improvements. You can apply Kanban principles to
any process you are already running (even to Scrum). In Kanban, you organize your work on a Kanban
board. The board has states as columns, which every work item passes through – from left to right. You
pull your work items along through the in progress, testing, ready for release, and released columns.
And you may have various swim lanes – horizontal “pipelines” for different types of work. The only
management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. By managing WIP
you can optimize flow of work items. Besides visualizing work on a Kanban board and monitoring WIP,
Pimp My Agile | 05-Apr-17

nothing else needs to be changed to get started with Kanban.

3
 Kanban vs Scrum
Looking at both agile software development methodologies it should be more clear what to introduce
when: If your organization is really stuck and needs a fundamental shift towards a more efficient
process, Scrum seems to be more appropriate. If you already have working processes, which you want
to improve over time without shaking up the whole system, Kanban should be your tool of choice.

Large-Scale Scrum (LeSS)

Pimp My Agile | 05-Apr-17

Scaling Scrum starts with understanding standard one-team Scrum. From that point, your organization
must be able to understand and adopt LeSS, which requires examining the purpose of one-team Scrum

4
elements and figuring out how to reach the same purpose while staying within the constraints of the
standard Scrum rules.

Agile development with Scrum requires a deep organizational change to become agile. Therefore,
neither Scrum nor LeSS should be considered as merely a practice. Rather, they form an organizational
design framework.

Two Agile Scaling Frameworks

LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are
focused on directing the attention of all of the teams onto the whole product instead of “my part.”
Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. The two
frameworks – which are basically single-team Scrum scaled up – are:

 LeSS: Up to eight teams (of eight people each).

 LeSS Huge: Up to a few thousand people on one product.

What does it mean to be the same as One-Team Scrum?

LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-
team Scrum. In LeSS, you will find:

 a single Product Backlog (because it’s for a product, not a team),

 one Definition of Done for all teams,
 one Potentially Shippable Product Increment at the end of each Sprint,
 one Product Owner,
 many complete, cross-functional teams (with no single-specialist teams),
 one Sprint.

In LeSS all Teams are in a common Sprint to deliver a common shippable product, every Sprint.

What’s Diff erent in LeSS?

 Sprint Planning Part 1: In addition to the one Product Owner, it includes people from all teams.
Let team members self-manage to decide their division of Product Backlog Items. Team
members also discuss opportunities to find shared work and cooperate, especially for related
items.
 Sprint Planning Part 2: This is held independently (and usually in parallel) by each Team, though
sometimes for simple coordination and learning two or more Teams may hold it in the same
room (in different areas).
Pimp My Agile | 05-Apr-17

 Daily Scrum: This is also held independently by each Team, though a member of Team A may
observes Team B’s Daily Scrum, to increase information sharing.
 Coordination: Just Talk, Communicate in Code, Travelers, Open Space, and Communities.
 Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR)
meeting that includes the one Product Owner and people from all teams. The key purpose is to
decide which teams are likely to implement which items and therefore select those items for

5
 later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner
and all teams.
 Product Backlog Refinement: The only requirement in LeSS is single-team PBR, the same as in
one-team Scrum. But a common and useful variation is multi-team PBR, where two or more
Teams are in the same room together, to increase learning and coordination.
 Sprint Review: In addition to the one Product Owner, it includes people from all teams, and
relevant customers/users and other stakeholders. For the phase of inspecting the product
increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple
areas, each staffed by team members, where the items developed by teams are shown and
discussed.
 Overall Retrospective: This is a new meeting not found in one-team Scrum, and its purpose is to
explore improving the overall system, rather than focusing on one Team. The maximum
duration is 45 minutes per week of Sprint. It includes the Product Owner, Scrum Masters, and
rotating representatives from each Team.

Reference: A detailed explanation of LeSS framework can be seen in the following URL:
http://less.works/less

Scaled Agile (SAFe)

The Scaled Agile Framework® (SAFe) is a freely revealed knowledge base of proven, integrated patterns
for enterprise-scale Lean-Agile development. It is scalable and modular, allowing each organization to
apply it in a way that provides better business outcomes and happier, more engaged employees. SAFe
synchronizes alignment, collaboration, and delivery for large numbers of Agile teams. It supports both
software and systems development, from the modest scale of well under 100 practitioners to the largest
software solutions and complex cyber-physical systems, systems that require thousands of people to
create and maintain. SAFe was developed in the field, based on helping customers solve their most
challenging scaling problems. It leverages three primary bodies of knowledge: Agile development, Lean
product development, and systems thinking

Key Stones in Agile Soft ware Development

 Deliver running software
 Learn fast
 Interaction and collaboration
 Welcome changes
Pimp My Agile | 05-Apr-17

Create your Minimal Viable Process

 Focus on delivering value
 Make learning and experimenting part of your daily routines
 Facilitate team communication
 Use the feedback!

Improve Agile Team Velocity

6
Leverage Retrospecti ves
Retrospectives are part of most agile practices and give teams time to reflect on what worked well and
what can be improved in the development practices or processes. I'd recommend management ask the
team to consider a higher velocity as a discussion point during the retrospective. I'd also make it clear
that the team should recommend steps that is under their control so that the exercise doesn't dissolve
to a list of out-of-team improvements.

Increase Planning
I tell teams that they should target to have a backlog of two sprints of full defined stories, and an
additional four sprints of story stubs estimated. If the product owner feels strong about the
prioritization and definition of the backlog, it may help teams to dedicate blocks of time to get ahead of
planning and target as much as four sprints of defined stories and an additional eight estimated. The
added visibility gives teams the "big picture", helps them see dependencies, and gives them more time
to find easier solutions.

Analyze Causes of Rework

All agile practices have a certain amount of rework in the form of changed requirements, poorly defined
requirements, technical debt, defects, performance considerations and other sources. Teams should
consider labeling stories (or tasks) based on the source of the rework, then consider measures that
might reduce this work.

Learn the Customer

The Product Owner has got the tough job of aggregating many inputs from different user segments,
sales teams, customer care feedback, research, and usage data. Development teams can play a role by
insuring Product Owners have better data and more technical insight to make smarter decisions on what
capabilities (stories) are required and what priority to fulfill the customer need. It can also lead to better
technical design. So for example, if a feature is required by top customers but is not heavily used,
perhaps the performance criteria can be relaxed and lead to an easier to implement design.

Implement Smarter Soluti ons

Are teams leveraging existing code? Should a capability be developed as a service because it will have
short term reuse, or should other capabilities take on deliberate technical debt? Are features too big,
and will breaking them down, labeling them, and discussing with the Product Owner lead to lowering
the priority on some of them? Are estimates challenged to help find better, more efficient solutions? In
my experience, these disciplines can be overlooked by teams yet they can lead to better more efficient
Pimp My Agile | 05-Apr-17

solutions.

Agile User Stories and Groomed Product Backlog

7
 What is a User Story?
Agile is a value based development methodology, where all those features of the product which can add
value to the customer are recognized, prioritized and developed based on customer needs.  These
valuable features are best described in user’s own words. Hence finding out who are the users is an
important task. Once all the users are recognized, requirements which add value to the user are written
down considering the needs of those specific users. Since those requirements are coming keeping users
in mind, they are called User Stories.

How to Write a User Story?

User Stories are best written in following format.

As a <User>, I want to <Have> so that <Benefit>

Here user story describes how a user (a manager, a clerk, a developer, a librarian, an owner etc.) will
want to interact with the system and get a certain benefit out of that interaction.

User
A user is the user of the system.

 A manager
 A clerk
 A developer
 A librarian
 An owner etc.

Benefi t
Benefit is the value a user will get of the system.

 A manager can see the audit report in one click, which will save his time.
 A clerk could search a report, which will save his time.
 A librarian could search a book by category, thorough which he/she will improve customer
service.
 An owner can order an equipment, which will save him from hassle.

By writing user story in this way, it’s easier for the reader to know who is getting what, to know that
information helps at the time of prioritization, estimation and development. Also it opens the door of
discussion between different stakeholders.
Pimp My Agile | 05-Apr-17

What are examples of User Stories?

Following are some sample user stories.

1. As an administrator I want to be able to create a new user to the team when needed.
2. As a lawyer I want to see all my active cases on the main screen.
3. As a student I want to see all of my old transcripts on the board.
4. As a driver I want my GPS voice activated.

8
 5. As a researcher I want to see last few searches I made.
6. As a user I want the ability to restore my password.
7. As a cashier I want to see total amount in cash register displayed.
8. As a pilot I want to know the best flight height to fly in current conditions.
9. As a police officer I want to see the previous tickets given to a driver.
10. As a post man I want to know estimated time to deliver today’s mails.

What is the term INVEST?

User stories are supposed to have certain characteristic described by Bill wake as INVEST.

 I – Independent: stories should be as far as possible independent so each of them could be

developed and delivered separately.
 N – Negotiable: User Stories should discussable further and there should be space of
negotiation
 V – Valuable: User Stories should result in adding value to the customer
 E – Estimable: User Stories should be understandable enough so could be divided into task and
could get estimated
 S – Small: User Stories should not be too big, usually should be done in 40 hours of work
 T – Testable: User Stories, usually have acceptance criteria to test if they fulfill customer’s needs

What informati on User Story may contain?

Pimp My Agile | 05-Apr-17

What is a Product backlog?

Once created user stories are stored in product backlogs. Product backlog is an important artifact of
Agile; it’s a place where all the user stories are stored, usually by product owner. Product backlog
contains user stories which are not estimated.

9
 What is a Groomed Product backlog?
User stories placed in backlog are not prioritized and estimated yet. They might need more detail and
explanation. Agile team may need to discuss more to fully comprehend not only the requirement but
the value attached to the backlog. For that Agile teams take part in a grooming session, where user
stories are discussed with the team and all the ambiguities are removed. Development team ask
detailed question pertaining user stories and product owner prioritize them. Also development team
and product owner estimate the user stories. After completion of grooming and planning session team
comes out with a groomed backlog.

What is an Epic?
Epics are large user stories at relatively high level with

LOWER PRIORITY: They are too big to implement in a single iteration and therefore they need to be dis-
aggregated into smaller user stories.

References
SAFe: http://www.scaledagileframework.com/

http://www.agileweboperations.com/scrum-vs-kanban
Pimp My Agile | 05-Apr-17

https://www.agilealliance.org/glossary/backlog-grooming/

10