Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2014 Graduate Bootcamp: Agile

2014 Graduate Bootcamp: Agile

Doing it! Comes from developers, not managers.

Software is made by people, not processes.
Talking to each other and figuring out what needs doing is far more productive than trying to formalise everything.

Seems obvious, but the point of the exercise is to build software!
Some documentation is useful, but it’s not an end in itself.

Especially true for internal customers – we’re all working for the same company!
There shouldn’t be any need to waste effort nailing down a contract.

Things change. More important to work towards what’s needed now than what was originally planned.

Things on the right not _completely_ useless! Keep to the minimum amount required.

Too often ends up more like this.

Principles seem less well-known, but less easy to fudge.

In other words, start delivering value straight away, then keep adding to it.
Not all at once at the end of a project.

Not just tolerate – welcome.
Agile is all about responding to change, and learning from feedback.

That was in 2001. These days those timescales seem pretty long, with lots of companies delivering multiple times a day.

Collaboration again!

Again, it’s about people.

We don’t care about design documents, percentage complete, story points or anything else.
If it’s not deployed and delivering value, it doesn’t count.

No death marches! No burnt-out developers.
If you cut corners to deliver more quickly, it’ll slow you down in the long term.

Good design allows us to keep the software easy to change safely, meaning we can keep delivering. We’ll come back to this later today.

All about reducing waste – concentrate on the things that add most value, and ask yourself whether things are really necessary or are just being done out of habit.
The easiest code to maintain is the code you didn’t write.

All about trusting the people doing the work.
Don’t try and impose a single way of working from above (often hard for traditional companies).

Agile methodologies are meant to be adapted to projects/teams/environments.
Try a standard process first, then experiment.
Another reason why top-down imposition doesn’t work.

This is one release (maybe a month or two) – the cycle then repeats.
Iterations demoed to customer – may or may not deploy to live.

Individual stories, delivered as soon as they’re done.
Only works if you are confident about not causing regression faults.
Assumes no long manual testing phase.

Just an example – what works for us.
Based on many years of experience and tweaking.

As little as possible.

Talk to customer. Find out what problem needs solving.
Rough guess of amount of effort. Worth it for benefit? Prioritisation.
Some kind of financial stuff.

Small features (ideally a day or two’s work).
Simple – a few words on an index card.
No fixed format.

Used for tracking progress of stories.
Physical or online.

Left to right. Pull system. WIP limits. Gate criteria.
Faces on cards.

Progress of current stories. Any problems? Anything new?
About communication, not status reporting.

Like process, as little as possible. Mostly for team benefit, on wiki.
No formal documents.

The important bit :-)

All about developers.
No designers or architects.

Everything TDD.
Spikes if unsure.

A lot of emphasis on code quality, so code remains easy to change.
Still could be better!

Knowledge transfer.
Catching mistakes.
Two pairs of eyes.
Bus factor.

Anyone can work on anything.
Rotate pairs.

Commit frequently.
CI server runs all the tests, and deploys to test server.
Feature branches and pull requests.

Not up to what the best teams do.
Finish feature; demo on test server; deploy.
Automated deployment.

Regularly look at what’s gone well or could have been better.
Adjust how we work.

Handles by development team.
Informal for some projects; rota with pagers for important ones.
Incentive not to let things break!

Brown bags & designery.
Dojos.
Generally encourage learning, practice & sharing.

Kerry Buckley

October 27, 2014
Tweet

More Decks by Kerry Buckley

Other Decks in Programming

Transcript

  1. Manifesto for Agile Software Development 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.
  2. Manifesto for Agile Software Development 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.
  3. Manifesto for Agile Software Development 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.
  4. Manifesto for Agile Software Development 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.
  5. Manifesto for Agile Software Development 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.
  6. Manifesto for Agile Software Development 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.
  7. Manifesto for Agile Software Development 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.
  8. Manifesto for Half-Arsed Agile Software Development We have heard about

    new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value: Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact Working software over comprehensive documentation as long as that software is comprehensively documented Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.
  9. Our highest priority is to satisfy the customer through early

    and continuous delivery of valuable software.
  10. Deliver working software frequently, from a couple of weeks to

    a couple of months, with a preference to the shorter timescale.
  11. Build projects around motivated individuals. Give them the environment and

    support they need, and trust them to get the job done.
  12. The most efficient and effective method of conveying information to

    and within a development team is face-to-face conversation.
  13. Agile processes promote sustainable development. The sponsors, developers, and users

    should be able to maintain a constant pace indefinitely.
  14. At regular intervals, the team reflects on how to become

    more effective, then tunes and adjusts its behavior accordingly.