November 20th, 2015 PHPWorld 2015 875 N St NW, Suite 205/ 202 350 4600/ hugeinc.com

What Goes Wrong With Agile

Huge

November 20th, 2015

And How We Can Fix It

1. Intro 2. Agile Dysfunction 3. The Problems

4. The Fixes 5. Improve Your Team

Agenda

Before We Dive In

Who are you:

Matt Toigo or just @toigo since too many guys born in the 80s

are named Matt

I’ve worked at agencies, startups, and large product companies.

You have opinions, like everybody else, but are they valid?

All the way from PHP4 ClassName() constructors to the current vibrant

ecosystem that Composer has enabled.

I’ve seen PHP and software development evolve for 15 years.

Agile + Scrum

Every consultant and their dog are now shouting about them.

More Buzzwords?

I’m sick of hearing about them.

Why Are They Popular?

The past was far worse.

We’ve all been on a waterfailure project and promised ourselves…

never again.

Alright, Let’s Give Agile a Shot

The rest of this presentation assumes a basic familiarity with Agile +

Scrum.

Because nobody wants to sit through another pretty presentation

that ignores the difficulties of our jobs while telling us how to do them.

Two Kinds of Agile Teams

Fresh Coat of Agile Paint

We have the ceremonies, use the terms, develop to 6 month old

specs, and have 20 people on our Scrum team!

What more do you want?

We’ll build that feature in our next 2 month sprint.

I’m not going to talk about fixing these issues.

Solid Agile Team

Teams are autonomous, technical investment in Agile, supportive organization, and focused on

constant improvement.

It’s all going to be rainbows and sunshine and everything will be

easy and perfect!

NOPE

What Goes Wrong

Ticket Quality

The root of most Agile dysfunction and the source of pain for

EVERYONE on a team.

If you listen to only one part of this presentation

Downstream effects:

1. Bad Estimates

2. Unstable Velocity

3. Slower Work

4. Missed Requirements

5. Terrible for Testers

6. Stakeholders Don’t See Value

Write With Specificity

Take the time to write great user stories that anyone can quickly

understand.

Also add the details that developers need.

Give everyone on your team the chance to punch holes in them.

Hidden Complexity

Now we think it’s more like a week…

We said this was going to take a day.

There is only one cause for this.

Work was started before a problem was fully understood.

Prepare with Spikes

Pause before you dive into coding to make sure you have every detail

you need.

Let’s just start the work!

Clarify:

1. Product / UX / Design

2. Technical Architecture

3. Sequencing

4. How Will We Test

5. Organizational Limitations

Write down every detail so someone can refer back to everything that

was learned.

Take as long as you need to get all the answers.

Never Removing Work

Then realized we were totally unprepared.

We committed to finishing this feature this sprint

It was in our sprint commitment though so we HAVE TO FINISH IT.

We’ll be making uneducated choices and possibly do shoddy

work.

Let’s just get it done!

Remove the Work

Don’t let it drag down everyone on the team for the remainder of the

sprint.

Acknowledge you made a mistake starting the work.

Remove the problem work so you can focus on work that is ready.

You probably aren’t being good enough about policing Definition of

Ready.

Discuss what went wrong in a retro.

Task Level Planning Only

The best way to have a productive heads down team.

Punch lists of clearly defined work

You can miss the big items though.

No where for someone to understand how a system works or

review it.

Details are spread out in different tickets.

Problems:

1. Features Don’t Fit Together

2. Inconsistent Coding Patterns

3. Architecture is Short Sighted

4. Team Output is Unknown

Plan at Higher Level

Sprint forecast to stakeholders.

Make sure your entire team understands the product vision a

few months out at all times.

Use a wiki to define technical architecture and relate it to

production functionality.

Work Not Being Truly Ready

Testing it is taking forever though.

Development on this story went great!

Developers did their part, why can’t we Ship It!

Ready Means Ready to Test

Don’t just ask if a story is ready for development.

Ask if we can quickly nail the testing or are we going to run into major

blockers.

Ask yourselves:

1. Is There a Test Plan

2. Do We Have to Modify Data to Test

3. Are Physical Devices Available

4. Do We Need Another Team to Help

The QA members of your team will love you for this.

Tickets Replacing

Communication

All hail the mighty sprint board and tickets are the source of truth!

I assigned that JIRA ticket to you, why would I need to talk to you

about it?

Remote teams can be especially bad about this.

Talking > Tickets

Take the time to explain complex issues to teammates.

ON THE PHONE OR VIDEO CHAT

Assigning a bug without an explanation can feel like blaming

someone

Ballooning Tickets

But let’s just add one more little thing…

The work in this user story looks great.

Scope creep leading to revolving door tickets.

Be Strict About Acceptance

Criteria

Let your team close out work to maintain momentum.

Tickets are cheap so make another one the right way.

Let’s talk to our Product Owner and address it in backlog grooming.

That’s a really good idea!

How Did You Figure These

Out?

A year’s worth of detailed project retro notes.

A fantastic team who was brutally honest in retrospective meetings

while still always being respectful.

Specific examples are easier to fix rather than general griping.

Take detailed notes during a sprint.

It’s easy to get the details wrong when you’re frustrated.

Everyone on your team MUST have the attitude that they still have a lot to

learn about how to build great software.

Constant Introspection

November 20th, 2015 PHP World 2015 875 N St NW, Suite 205 / 202 350 4600 / hugeinc.com