Disclaimer: I currently work for a company. That company does Agile. From my limited experience, I think it does it well. I am not talking about that company in any way, shape, or form in this post.
I don’t recall when I first heard about Agile software development. I probably heard about it from Slashdot, when I was still reading it during grad. school.
First up, the Manifesto itself:
From: http://agilemanifesto.org/
”
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.
”
Overall, it feels like a very human approach to software development. I’ve always enjoyed speculating about the situations which may have led to rules being formed*.
It also feels like it was written by a group of people who were actually interested in solving problems, perhaps by cutting through Gordian Knots of rigid process and planning.
Their conclusion was that problems will occur, things will change, and you want your process to accommodate that as much as possible, to enable and encourage people to talk about these earlier and more effectively. More of a ‘getting to yes’, rather than rear-covering or posturing.
Now, they further broke down the above four statements into 12 principles:
http://agilemanifesto.org/principles.html
1) “Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.”
This one seems pretty self-evident, but there are a surprising number of people who have job descriptions at odds or orthogonal to this, especially as organizations get larger.
2) “Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.”
This might be the toughest (it was for me, and I consider myself good at this), as humans are naturally lazy and resistant to change.
Evolutionary Psychology : Laziness
I wonder if this can only be overcome through experience, by knowing how much more pain will happen if a particular shortcut is taken or some important stakeholder is ignored. (Even knowing that someone should be listened to instead of letting your lazy brain edit them out can be difficult.) Either way, a good argument for having at least one person (that you listen to!) with experience on the team.
But if you’re having requirements changing too often, your stories are likely not ready before you start, or they are too large, leading you to:
3) “Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.”
‘Fail early, fail often’ goes the quote. Coupled with 2), it becomes much more difficult to be working on the wrong thing when you’re allowing for updated requirements every time you start a new short story**.
4) “Business people and developers must work
together daily throughout the project.”
I feel like the people who put this list together had experienced a lot of communication problems where they worked. This one is really helpful. There are few things more annoying than being ready to work on something but not being able to reach the person who needs to make the decision.
5) “Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”
From the people I’ve talked to, this is every programmer’s dream. All the best working environments I’ve been in have been like this.
6) “The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.”
Yes. And it drops off considerably, even to ‘face-to-face’ Skype/
7) “Working software is the primary measure of progress.”
Many people have different measures of progress, leading to organizational misalignment.
8) “Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”
As much fun as ‘feast and famine’ is, you’re probably not doing your best work souped up on adrenaline and coffee. (Or maybe you are. If so, you should take some time off between binges.)
9) “Continuous attention to technical excellence
and good design enhances agility.”
‘We put brakes on the car so that it can go faster.’ ‘Legacy code is defined as any code with inadequate test coverage.’ All the time you spend hesitating*** because you’re worried about breaking old crappy code is time you’re not building features or refactoring old crappy code.
10) “Simplicity–the art of maximizing the amount
of work not done–is essential.”
Think Apple. Think Oblivion when they decided to voice all of the dialog, and all the streamlining that inspired/required. Think about that super-expert programmer you know who can tell you why every single line of code they wrote is there, and also why everything not there is not there.
11) “The best architectures, requirements, and designs
emerge from self-organizing teams.”
Ask the people who know the most about something to make the decisions****.
12) “At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. ”
Continuous improvement. Read ‘The Goal*****’. Really. It will improve your life. Also retrospectives.
*Similar to reading Wikipedia and trying to figure out the actual events behind the dry descriptions…
**I still remember the day when I felt I had ‘graduated to short stories’, as they tend to pack more large ideas per page. Longer novels tend to be more meditative/escapatory?
***And working around crappy code…
****I’m currently most comfortable with some mix of Scrum and Kanban. They have a specific separation of powers between the team (handles estimation) and the product owner (handles prioritization). To me, this seems totally reasonable, but re-reading the manifesto above, there are many levels of Agile actualization above that. (Think Valve.) (Also, the product owner is part of the team, just with a specific role to play in addition to the general team tasks.)
*****https://en.wikipedia.org/wiki/The_Goal_%28novel%29 My favourite business book. Told in a novel format. Some of the story has dated references (before most of feminism), but is still very useful.