AGILE michael stowe

in the workplace

September 17, 2013

MIKESTOWE

•  Open Source Contributor

•  Author, Speaker, and Consultant

•  10+ years experience hacking PHP

•  Zend Certified PHP 5.3 Software Engineer

•  Developer Advocate with Constant Contact

.com @mikegstowe

IN THE BEGINNING

Imagine going to the store and buying a canoe, a

compass, a map, and a pack for food and water. You trek

out to the river and jump in, ready to begin your journey.

The only catch is once you start there’s no where to

stop… so I hope you bought the right map, or that your

compass works. And you better have enough food and

water… oh yeah, and experience for the

waterfall ahead!

IN THE BEGINNING

This is pretty much how products were being developed.

People would get together and put together requirements

and then base all of their decisions off of the

requirements.

The project then moved forward one branch at a time.

And like a waterfall, once you got so far into the project,

it’s a little late to turn around and go back.

TYPICAL WATERFALL

Image courtesy of http://www.varsys.com/knowledgecenter_WaterfallDownfall.html

No plan survives contact with the

enemy… Helmuth von Moltke

To improve is to change; to be

perfect is to change often. Winston Churchill

Want to be a web developer? Easy! First, imagine

you’re a carpenter. Second, imagine that the house

you’re building is made of live monkeys. David Lee, @tangentialism

WHAT IS AGILE

Agile simply means flexible. Rather than being strict and

unmovable in our processes like the Waterfall Method,

Agile encourages a “take it as it comes” approach.

Agile encourages the use of people over process, working

software over comprehensive documentation, customer/

business collaboration over contract negotiation, and

responding to change instead of following a set plan.

AGILE MANIFESTO We are uncovering better ways of developing software by doing it

and helping others do it. Through this work we have come to value:

Individuals and Interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the

items on the left more.

From Wikipedia, the free encyclopedia

AGILE PROCESS

Agile does this by first outlining the vision or general

requirements of the project. This vision is then divided

into smaller chunks known as “stories.” Think of the

vision as a deck of cards, and each story being a card in

that deck. Instead of focusing on the whole deck, we can

now prioritize which cards are the most important, and

start tackling them piece by piece.

AGILE PROCESS

We prioritize our cards by putting them in iterations, or

short 2-4 week development cycles. For example, we

may decide that the Joker, the King, and the Queen are

the most important cards, so we want them in the first

iteration.

We can then put other cards in future iterations, but we

will focus on these three cards first, and get them ready

to go before moving on (unless priorities change).

ITERATION AND BACKLOG

Image courtesy of http://www.executivebrief.com/agile/how-to-scrum/

Joker, King, and Queen Cards

All Other Cards, on the backlog for future iterations

Tasks to create these three cards

TASK BOARD With Agile, one of the easiest ways to manage tasks is by using a task board… or in this case, a piece of paper with Post-it® notes of different colors signifying different types of tasks. The key components include Stories, To Do, In Progress, Testing, and Accepted

From Wikipedia, the free encyclopedia

Kanban Board

AGILE PROCESS

Once we develop these cards, we can test them, have

them reviewed by the customer or business team, and

make sure that everything looks good before moving on.

The following figures are good examples of how Agile

Methodology works:

AGILE METHODOLOGY

Image courtesy of http://www.mountaingoatsoftware.com/scrum/overview

simplified

AGILE METHODOLOGY

Image courtesy of http://www.varsys.com/knowledgecenter_WaterfallDownfall.html

THE ADVANTAGE

With the Waterfall Method we would have designed the

entire deck and sent it off for printing. But it turns out

we can’t do rounded corners on our cards, or the colors

don’t look right, or for whatever the reason the cards just

don’t work.

With Waterfall we just wasted work on 52 cards, where-

as with Agile we would have caught this issue and been

able to fix it after only working on 3 cards!

THE DISADVANTAGE

Agile requires team members to work closely together

and requires the team to innovate and problem solve. It

provides greater flexibility allowing the project and

requirements to evolve. It places more value on the

software than it does documentation, and is driven by the

customer or business unit and their satisfaction.

THE ADVANTAGE

Agile requires team members to work closely together

and requires the team to innovate and problem solve. It

provides greater flexibility allowing the project and

requirements to evolve. It places more value on the

software than it does documentation, and is driven by the

customer or business unit and their satisfaction.

RISK MANAGEMENT

To help make Agile successful in the business it is

recommended to have small, dedicated teams that can

work together. The general rule is to build a team with

the Product Owner, a Scrum Master, and 5-9 (or 7 +/- 2)

team members.

This allows the team to collaborate quickly without

becoming siloed - a major risk with larger teams.

Image courtesy of http://www.executivebrief.com/agile/how-to-scrum/

RISK MANAGEMENT

Because Agile requires the development team to work

closely together, and with different personalities, it is

recommended to have an outside “Agile Coach” who is

not directly part of the team but is available to serve as a

mentor. This allows the mentor to help resolve issues

without members feeling that the Product Owner or

Scrum Master is taking sides and/ or playing favorites.

RISK MANAGEMENT

It is vital for your development team to grow together

and work as a team in order to overcome any issues that

may arise within the development cycles/ iterations.

Early on one of the biggest challenges is a lack of

communication or understanding of Agile, and power

struggles between users. However, once the team learns

to work together, they will be able to utilize all of their

strengths to build an even better product.

AN AGILE ENVIRONMENT

Unlike Waterfall Methodology which is driven by meeting

after meeting, Agile relies on team members working

together as needed. Because of this, it is important to

provide an environment that allows team members to

collaborate, such as providing team members with

laptops instead of desktop computers for mobility and

having a dedicated space and time for the team to work.

STOP WASTING TIME

By providing the team with the time and resources

necessary to collaborate, you can avoid lengthy meetings.

In general, the team usually gets together for a quick

“stand up” meeting that should last no more than 15-30

minutes in which team members discuss their progress,

challenges, and goals for the day.

THE DAILY STANDUP

- What did I accomplish yesterday?

- Team members are quickly briefed on the progress

being made on the project.

- What will I do today?

- Team members are briefed on what the development

goals for the day

- What obstacles/ challenges are holding me up?

- Team members are alerted early on to potential

issues and appropriate resources can be utilized.

STOP WASTING TIME

By knowing the needs and goals of each of their

teammates, agile team members are able to help out and

assist as needed, again pulling together to use their

strengths. Part of the challenge of a manager is to “let

them go at it” and take charge.

Because Agile is intended to be flexible, tasks can be

dealt with as they come, and you can avoid scheduling

long and lengthy planning meetings.

DO MORE PLANNING

One misconception with Agile is that you do not have to

do any planning… in fact it is just the opposite. Agile

requires a general vision which is broken into stories.

Basic requirements are then given to stories, and they are

put into iterations for development.

But the planning doesn’t stop there, once we get to the

iteration the stories are more carefully reviewed and

requirements are again discussed.

DO MORE PLANNING

And as stories are developed, new challenges may be

discovered, which may require more collaboration and

planning among the team members in order to find a

solution or adjusting requirements.

Certain tasks may even be moved into future iterations,

allowing continuous development that will have improved

functionality in the future.

POWER TO THE PEOPLE

This is one of the most powerful aspects of Agile, the

emphasis of the team over processes, and working

software over extensive documentation.

After all, what good do processes do you if they don’t

help solve the problems you are trying to address? And

what good is telling people what the software will do, if

the software is stagnant with problems because the

requirements were so rigid?

POWER TO THE DEVELOPERS

Because Agile reduces wasteful meetings, increases

collaboration among team members, reduces

documentation, and allows for immediate testing and

feedback- it allows software engineers to do what they do

best, Code. In fact, it let’s your entire team do what they

do best… their job.

POWER TO THE DEVELOPERS

However, it is important to make sure that your team

members are being left alone and not harassed by

business owners or stake holders.

Remember the scrum team, the Product Owner and

Scrum Master are responsible for running interference to

make sure work is not being added directly to the

development teams plate, and that there are no outside

distractions that impede their work.

SCOPE CREEP

One of the most dangerous forms of distractions from the

task at hand is Scope Creep, or work that “creeps” it’s

way into the scope of the project.

All bugs, tickets, features should be assessed by the

Product Owner and assigned to the proper iteration or

cycle. Developers like-wise need to be careful not to start

injecting new tasks or features into their work that are

not directly related to the current iteration.

TAKE TIME TO REVIEW

After each iteration it’s a good idea to take time to review

what went well, and what didn’t in that iteration. This

allows the team to identify how their strengths came

together, and focus on how to overcome the challenges

this iteration presented in future iterations.

This meeting doesn’t have to be super long. A general

rule is no more than 45 minutes for every week the

iteration lasted (so 2 weeks = 1.5 hour meeting)

TAKE TIME TO REVIEW

Questions to ask during the Retrospective meeting

include:

-  What went well during the iteration?

-  What would we like to change?

-  How can we implement that change?

You can also discuss the results, people involved

(resources), relationships, processes, tools, and overall

productivity.

TAKE TIME TO REVIEW

The Retrospective meeting is not intended to be a blame

session, but rather a chance for the team to come

together and problem solve as a unit. Avoid letting the

meeting become personal or directed at one person.

Likewise, watch out for excuse statements such as

“Because…” or “Nothing we could do…” as it signifies a

move from problem solving to rationalizing why things

didn’t go according to plan.

REAL WORLD

AGILE

LET’S MAKE A SEARCH ENGINE

Your company has come up with a great idea for a search

engine! So the Product Owner meets with the Stake

Holders and Business Owners and comes up with a vision

for your search engine.

Together they decide the search engine should be able

to: spider sites, store data to a NoSQL database, work

with a third party API, allow members to bookmark

favorites and/or purchase PPC advertising.

LET’S MAKE A SEARCH ENGINE

Based on this broad requirements, stories are created for

each of the tasks:

-  Spidering Sites

-  Store to Database

-  Third Party API Integration

-  Member System with Login

-  Favorite Bookmarking

-  PPC System – Manage Ads

-  Show PPC Ads in Results

LET’S MAKE A SEARCH ENGINE

For the first iteration, which will be 2 weeks, the team

decides on doing the Spidering Sites and Store to

Database stories.

The team then starts planning the requirements for these

features, and decides upon using MSSQL to save the

data. Your developers start getting to work…

LET’S MAKE A SEARCH ENGINE

But unfortunately your LAMP stack doesn’t support

MSSQL. Your developers quickly alert the team that this

requirement will not work.

The team gets back together and agrees to change the

requirement to be MySQL. BLAM! Problem averted.

LET’S MAKE A SEARCH ENGINE

One week into the project your developers realize that

two weeks may have been a really generous estimate,

and that it is probably going to take longer.

Once again the team takes a look at the iteration and

requirements, and decides either to move some

requirements into a future iteration as followers, or to

simply push the entire “release” to the next iteration.

LET’S MAKE A SEARCH ENGINE

However, because of your daily “stand-ups,” both the

Scrum Master and Product Owner were made aware of

this, and were able to relay it to the Business Owners and

Stake Holders, preventing a reign of fire from coming

down on the entire team. BLAM! Unhappy people…

Averted.

LET’S MAKE A SEARCH ENGINE

Great news, we just finished the first iteration. Bad news

is that the Business Owners decided they want the PPC to

be the next most important thing, and they have some

new requirements for it.

Thankfully, being agile we can simply move things

around, put PPC into the next iteration, and oh yeah, we

haven’t started evaluating the unique requirements for

this system. BLAM! Problem averted.

LET’S MAKE A SEARCH ENGINE

However, the Business Owners really don’t like the

interface of the PPC system. So, you create new stories

to make the UI look awesome and put them in the next

iteration.

BLAM! Yeah, you get the idea…

LET’S MAKE A SEARCH ENGINE

Oh man! QA found a bug in the code… and it’s a doozy!

Anything that depends on this code would be totally

doomed to fail…

But because we tested the iteration right after

development, nothing is dependent on it yet. We haven’t

coded all the other stuff yet, so there’s no lost work!!!

BLAM! Oh yeah…

LET’S MAKE A WEB APP

Ok, so that may seem a little too convenient. But that’s a

fake scenario based on a real life one. Working with Agile

saved our team HOURS and the business $$$.

We were able to problem solve as we went, be flexible

with requirements, and in the end turn out a product that

completely blew away customer expectations. Needless

to say, they were like… “Oh yeah…”

THERE’S A LOT MORE

However, I hope you now have a basic understanding of

what Agile is, and how it benefits EVERYONE from the

customer to the business owner(s). Remember the key

principles of Agile:

Individuals and Interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

THANK YOU.

@mikegstowe

visit mikestowe.com/slides for more on PHP and Web Development

@ctct_api

A big thank you to Constant Contact for making this presentation possible