agile solutions agile basics€¦ · agile solutions agile basics table of contents 2 who we are 3...

AGILE SOLUTIONS

[email protected] one80services.com

Agile Basics

AGILE SOLUTIONS

Agile Basics Table of Contents

2 Who We Are

3 What Is Agile?

4 Agile Values

5 Agile Principles

6 Agile Development

7 Iterative Development

8 Agile vs Waterfall

12 Documentation

13 Process

15 Methodologies

16 Extreme Programming (XP)

17 Scrum

20 Lean

21 Kanban

23 Summary

We are Agile trainers and coaches who are so passionate about Agile that we’d probably do it for free if we could. Our clients often comment that easy to get us to dig into solutions even before we’ve been hired - we kind-of geek out with this stuff.

One80 is owned by three people. Combined, we have more than 20 years of Agile training & coaching experience. We have navigated situations from both sides of the IT/business fence.

Who

We

Are

Who We Are

[email protected] Copyright © 2016 One80 Services, LLC 2

I am passionate about building high-performing teams that are structured with the proper dynamics to create and drive innovation. Building teams is more than just putting skills and resources into an Agile process and doing sprint planning. It is about finding the balance of personality, desire, motivation, and knowledge to structure groups of individuals who can work towards a common goal and who are focused on the organization’s value stream.

Teaching teams how to reach their goals while actually enjoying what they do for a living is my passion. Watching the transformation on the human level – not just what changes happen on a product or business level – that’s where I find my motivation.

I am passionate about helping organizations and their teams transform themselves to high performance using Agile and Lean principles. When I started, I thought that Scrum was the ultimate solution to every company’s problems. Over the years, I experienced how wrong I was. I have learned how important it is to take into account each company’s unique culture, team dynamics, technology, customer expectations and compliance needs. Then, given all of those variables, the journey towards excellence can begin.

Andre Simones

Nick Kramer

Stacy Simones

[email protected]

[email protected]

[email protected]

3

Wha

t is

Agi

le?

Agile is an adjective, not a verb. Therefore, you will never “do Agile”. You can, however, “be Agile”.

Consider the word “nice” - you can be nice, but you don’t really do nice.

If I hold a door open for you, I may be nice. If I’m glaring at you while holding it open for you - I’m not being nice. Nice is something you are - it manifests in pleasant ways, but nice itself is not an action.

Like the angry person holding a door, a company can implement an Agile methodology such as Scrum without actually being Agile. Agile is not an action.

A company can also be Agile without implementing any existing process framework at all.

What is Agile?

[email protected] Copyright © 2016 One80 Services, LLC

The Agile Manifesto

Customer collaboration over contract negotiation.

Individuals and interactions over processes and tools.

Responding to change over following a plan.

Working software over full documentation.

We value…


Agi

le V

alue

s

over is not the same as instead of

4

source: agilemanifesto.org

12 Agile 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 a 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. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

7. Working software is the primary measure of progress.

8. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

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.

Agi

le P

rinci

ples

[email protected] Copyright © 2016 One80 Services, LLC 5source: agilemanifesto.org

Agile methodologies are an alternative to traditional project management.

Agile software development helps teams respond to unpredictability through incremental, iterative work cadences, often known as sprints.

Agile software development promotes:

• adaptive planning • evolutionary development • early delivery • continuous improvement • rapid and flexible response to change

Agi

le D

evel

opm

ent


Iterative Development

Iterative development is a way of breaking down software development of a large application into smaller working sections.

In iterative development, feature code is designed, developed and tested in repeated cycles.

Itera

tive

Dev

elop

men

t


Agile vs Waterfall

Waterfall Waterfall is a sequential process. Once a step has been completed, developers can’t go back to a previous step without scrapping the project and starting from the beginning, or invoking a heavy change management process. There’s no room for change or error, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

Agile Agile follows an incremental approach.

Developers start with a simplistic project design, and then begin to work on small modules. The work on these modules is done in iterations, and at the end of each iteration, project priorities are evaluated and tests are run. Each iteration allows for bugs to be discovered, and customer feedback to be incorporated into the design before the next iteration is started. A

gile

vs

Wat

erfa

ll


Agile • Flexible

• Many small projects

• Highly collaborative

• Best for those who want continuous improvements

• Involves customers

• A process in which requirements are expected to evolve and change

Waterfall • Structured

• One big project

• A sequential process

• Suited for situations where change is uncommon

• Internal

• A process that requires clearly defined requirements upfront

Agi

le v

s W

ater

fall


Agile vs Waterfall

9

10

Agi

le v

s W

ater

fall


When to Use Agile

The Stacey Matrix

The Stacey Matrix is commonly used in Agile/Scrum training to explain where Agile is most appropriate. Ken schwaber modified the Stacey Matrix, and that’s what you see here.

When people agree on the “what” and the “how” of a project, it reduces complexity.

Traditional project management methods work best on projects low in complexity. When you have more uncertainty and a project increases in complexity, Agile is the better choice.

You can just as easily apply Agile to a simple project, but you’re not likely to see a huge benefit because that project was likely to succeed anyway. It’s the complex projects where the benefits of Agile will be more obvious.

(what you are building)

(how you will build it)

11

Agi

le v

s W

ater

fall


When to Use Waterfall

• Tasks are repeatable and predictable

• End state is well-known – no ambiguity

• Requirements are clear and won’t change or require business input or feedback

• Technology is completely understood and there is very little or no risk

Documentation

Agile core values ask us to think about how much and which kinds of documents are needed and when they need to be written.

Doc

umen

tatio

n


Just Enough vs Just in Case

What’s “enough” when it comes to documentation? Consider your customer. Does the documentation you’re creating benefit that customer directly in some way? If so, then it’s “just enough”.

When I walk up to a coffee stand in an office and pour myself a cup, I need a sign saying “Decaf” on the decaf pot. Sometimes I just need that tell-tale orange lid as an indicator.

I do not, however, need a document explaining to me the difference between decaf coffee and regular coffee, or an in-depth story about how those coffees were made.

Will there be a person who wants that information? Who knows. Maybe. But that’s a “just in case” situation, and we don’t cater to “just in case” situations with Agile documentation.

13

Proc

ess


Agile Team Process

This is an example of an iterative Agile team process.

An iteration is a set period of time an Agile team has to complete a piece (or pieces) of functionality.

(Iterations are referred to as “Sprints” in Scrum, because they’re short bursts of fast progress. Just like runners on a track.)

The team judges what they can complete during one iteration, pulling work from the top of the prioritized backlog.

Take a look at the next page in this guide to see a more detailed description of some of the activities (referred to also as events or ceremonies) that happen around the Agile process.

When the process ends, the team goes back to the beginning to pull another group of work from the top of the backlog and the process begins again.

1 or 2 week Iteration

Mod

ified

Agi

le F

ram

ewor

k

Proc

ess


Met

hodo

logi

es

Methodologies

There are an almost endless list of successful ways to implement Agile. You can come up with your own grass-roots method, you can combine current methods to come up with a custom hybrid, or you can choose one of many existing Agile methodologies.

According to every survey we’ve seen, the top three Agile methodologies used today are Scrum, Scrum with XP, and XP. Kanban seems to be mixed in to some degree, and everyone seems to agree that Lean practices are important.

Because of that, we’ll be covering those methodologies and practices here.

For the purposes of this basic guide, we won’t be going into great detail, but instead try to leave you with a basic understanding.

15

Extreme Programming (XP)

• Communication • Simplicity • Feedback

• Courage • Respect

Values

Practices• The Planning Game • Small Releases • System Metaphor • Simple Design • Refactoring • Testing

• Pair Programming • Collective Ownership • Continuous Integration • 40-hour week • On-site Customer • Coding Standards

Extr

eme

Prog

ram

min

g (X

P)


Typically, when a team begins XP, they start with the simpler practices illustrated in the dark blue outer ring in this diagram and work their way into the more complex practices illustrated in the yellow ring:


Scrum

An Agile framework for completing complex projects.

Scru

m

17

Values • Commitment • Focus • Openness • Respect • Courage

Events • Sprint Planning • Sprint Retrospective • Daily Scrum • Sprint Review

Roles • Product Owner • Scrum Master • Development Team

Artifacts • Product Backlog • Sprint Backlog • Working Software

Scrum The Scrum framework:

• A product owner creates a prioritized wish list called a product backlog. (Refer to the illustration on page 11.)

• During sprint planning, the team pulls a small chunk from the top of the product backlog, creating a smaller sprint backlog, and decides how to implement those pieces.

• The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).

• Along the way, the Scrum Master keeps the team focused on its goal and removes impediments to the team’s progress.

• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.

• The sprint ends with a sprint review and retrospective. Areas for improvement are identified and implemented in the next sprint.

• As the next sprint begins, the team chooses another chunk of the product backlog, creates a new sprint backlog, and begins working again.

source: scrumalliance.org

Scru

m



Scrum

Scru

m

Pillars of Scrum

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture.

Inspection in Scrum is done by using a common Scrum board and/or other communication tools, and from gathering feedback from the customer and other stakeholders.

Adaptation happens as the Scrum Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing.

All of these things are possible with a foundation of Scrum values from the team as well as from leadership.

source: scrumstudy.com

Scrum Values

Lean Process

7 Lean Software Principles 1. Eliminate waste.

• Create nothing but value. 2. Build quality in.

• Automate as much as possible.

3. Create knowledge.

• Work with business people. 4. Defer Commitment

• Decide as late as possible. 5. Deliver fast.

6. Respect people. 7. Optimize the whole.

• Optimize the whole value stream, from the time a customer’s need is spoken until software is deployed and the need is addressed. Lean


Kanban

“Kanban” means “card”.

Wikipedia’s more complex definition: “Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see. Team members pull work from a prioritized queue. Software development using Kanban is mean a visual process-management system that informs the team about what to develop, when to develop it, and how much to produce - inspired by the Toyota Production System and by Lean manufacturing.”

Simple Kanban is basically a list with moving parts. Tasks begin at the left and move slowly to the right as they are completed. A very basic Kanban approach would look something like this:

On the next page, we show two more examples of Kanban in use.

Why Use Kanban?

Kan

ban


To Do In Progress Done

Task

Task

TaskTask

Task

Task

Task

• visualize workflow • limit WIP (work in progress) • measure flow

Examples: Kanban Kick-Start

Simple Kanban

More Advanced Kanban

Kan

ban


source: Henrik Kniberg

23

Sum

mar

y


Summary

When you begin this journey, it’s easy to get lost in the multitude of existing terms and processes.

The important thing to remember: Agile is a mindset.

Agile is nothing more than a set of values and principles that encourage you to apply common sense to what you do and build what matters. There are a bunch of processes to help you do that, but the process isn’t what matters. What you build is what matters.

Agile is meant to simplify - it’s not meant to complicate.

It’s absolutely possible to apply Agile and implement a process without an Agile coach - we’ve seen grass roots Agile work many times. But if you’d like a bit of a boost from an Agile coach, please give us a call. We’d be happy to walk you through the basics to get you started, or stick around to see you all the way to the finish line.

One80 Services Mission Statement

We started One80 Services because we have seen too many companies build the wrong level of process at the wrong time.

They either build crushing amounts of process that drags time-to-market, or not enough structure to control the chaos.

Our mission is to help teams to build a practical approach to managing and prioritizing work that leads to innovation

and quality deliverables.

[email protected] one80services.com 1-844-80-Agile

agile solutions agile basics€¦ · agile solutions agile basics table of contents 2 who we are 3...

Documents