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.