Font (once again): MechanicalPencil
The canonical source for these principles is the agile manifesto website.
These are the basic agile principles, abbreviated to fit onto a 3x5 card without requiring the reader to hold a magnifying glass. They are "sound bites" and not the whole story. Each of these principles can (or has) launched myriad blogs/articles, and indeed many of the other Agile in a Flash cards touch on these principles. We could easily build a distinct card for each, though that would inflate the size of our eventual card deck quite a lot.
It has long been Tim's perspective that Agile is about having a short reach so we are allowing that point of view to color our summary of agile principles.
- Satisfy the customer through early and continuous delivery--We shorten the distance between requirements gathering and customer feedback. The period is shorter because we plan less change at a time, and in return we get more opportunities to steer the software in a direction the customer appreciates. Notice that the principle actually says "continuous delivery", not just "quarterly" or "bimonthly." Early and continuous delivery is not about working faster, only about working sooner.
- Welcome changing requirements, even late in development--We shorten the distance between conceiving and implementing an important change. We don't have to wait for a redesign of the whole system, or for the next system to be built. This is not to say that no features will be delayed; feature requests are frequently reordered or even dropped. The agile difference is that such changes take effect sooner.
- Deliver working software frequently--We shorten the distance between the system-as-designed and the system-as-built. Both will evolve as we learn more about the system as it should be built. We also shorten the distance between planning and delivery, giving more opportunity to improve the efficiency and effectiveness of our work.
- Business people and developers work together daily--We shorten the physical distance between a question and its answer. Moving the customer to a different building, area, room, or even to a cubicle just around the corner dramatically reduces the number of questions we ask the customer. With collocation, the business and technology sides learn to better understand each other and to make more mutually-beneficial decisions.
- Build projects around motivated individuals--We shorten the distance between intent and action. The goal is to build an agile team of skilled professionals who care about all the business concerns including schedule and content, and who will work in a highly-engaged and result-oriented way. Such individuals need no babysitting and very little direction. Such a team will refused to be blocked, and will produce their best work at all times. Management does not have to spend time on motivational issues or "cat herding" so common to less-motivated teams.
- Convey information via face-to-face conversation--We shorten the time between a question and its answer. Agile teams work in bullpens because it makes it much easier to ask questions and offer suggestions. Things that should be communicated get communicated, not forgotten, diluted, or otherwise insufficiently communicated. While there are many attempts to go agile without co-locating team members, we are not aware of any which have the kind of success which is typical in co-located teams.
- Working software is the primary measure of progress--We shorten the distance between thinking we're done and knowing we're done. The team should be judged by the product it produces, not by the rate of typing or number of degrees, or hours worked per month, or how quickly the members walk from the parking lot, or how quietly they work from their individual cubicles. A good team frequently produces quality software the customer wants. All other measures are subordinate or irrelevant.
- Maintain a constant pace indefinitely--We shorten the distance between productive bursts. This doesn't mean that management sets a large minimum hour limit for developers to endure months or years at a time. Excessive overtime cannot continue indefinitely without severely impacting quality. Instead, we choose a pace that allows us to go home tired and satisfied in the evening, and then return fresh and ready to rock in the morning. For normal people with families and bodily needs, that pace will not be 90 hours a week, and it probably won't even be 50 hours a week. We are never impossibly far from our life-sustaining relationships and activities.
- Give continuous attention to technical excellence--We shorten the distance between implementation and ideal. An agile developer is never more than a few minutes away from the last time all the tests passed. Collaborating classes are not at the opposite ends of long chains of contains/references/inherits relationships (e.g. "train wrecks"). Developers need not wait to clean up redundant or confusing code. If working code is the measure of agility, then excellent code must be defined as code that accepts changes gracefully. An agile team takes steps to ensure that code gets better with each iteration.
- Simplify: maximize the amount of work not done--We shorten the distance between comprehension and completion. We eschew things that don't matter. If we're less encumbered by unhelpful tasks and unwanted features, we've shortened the reach to useful work. We also attempt to simplify code (reducing the amount of reverse-engineering other programmers must do). Agile programmers tend to follow the rules of simple design.
- Teams self-organize--We shorten the distance between need and action. We don't wait around to be told who does what. We do what needs to be done, not waiting for direction or supervision. We attack problems with fervor, mitigating risks and clearing obstacles.
- Teams retrospect and tune their behaviors--We shorten the distance between introspection and adaptation. Improvement is never far away. Each iteration, we explicitly find ways to improve process simplicity, code quality, technical excellence, and predictability of results. We analyze problems and obstacles, and look for root causes and their solutions. We actively plan to use better techniques, tools, and process flows. We act on the plan in the subsequent iteration, without delay.
These principles are fairly simple in concept, but are profoundly deep in practice. If you are transitioning to an Agile work style or are looking for ways to improve your current Agile practice, we suggest you begin again with the principles espoused here.
Just rereading the principles reminded me that you can only achieve these kinds of results by delivering small successes frequently. Big things can only be done as series of smaller things.
ReplyDeleteI've been reading Womack and Deming and others, trying to understand the "why" of agile. I'm having some angst about the last two principles. Not that we shouldn't do them, we should. Not that they aren't awesome, they are. But that they are not the optimum. They are compensation mechanisms for management problems.
ReplyDeleteIt's ridiculous but imagine: a retrospective meeting including a 5 minute presentation by a director of the latest research in development methods that might be relevant to the team's current problems. Then imagine they were right 70% of the time.
DarrinT: I'm not following.
ReplyDelete1) Last two seem to be about producing to me.
2) A *retrospective* or a *training session*?
Maybe the words mean different things to the two of us...?
Essentially the last two points say "we know what we're doing and we do it so heck with job descriptions" and "we will always try to get better at what we do", which don't sound like compensation for management problems to me. In fact, a lot of things we consider "management" sound a lot like mechanisms for coping with teams that don't engage or improve on their own accord.
Of course, we come here through different doors, you and I. Please elaborate your viewpoint, so I can set my word-bias aside and hear you.
No I really mean retrospective. I do think we are looking at them though different lenses, so some of the words are meaning different things.
ReplyDeleteThe noteworthy thing is we said team twice. Why did we need to even say that?
When we say self-organize we mean as opposed to something else. We're rejecting something that came before and didn't work. What's really unfortunate here is the bosses above a certain level have to be held out of the organizing process. The reason it's unfortunate is that, usually due to complete incompetence and demonstrated track record of abject failure, we can't involve their broader perspective.
Self organizing a software team is better than Taylorist engineering, but it's not as good as a superb management team working with us to optimize our output to support the _whole_ organization.
By holding them out we can't help but sub-optimize.
(Taylorism is my new word. Can you tell?)
The last principle doesn't say we retrospect and tune our behavior, but the _team_ does it. First of all, the last thing I said applies here. We're optimizing for our own throughput with limited perspective.
It's unfortunate that the idea of a director or a vp or the CEO attending a retrospective is scary. Some of those folks can't be trusted. What if they could? What if they were truly masters of the business system? What if they could point out the little improvements we could make to our output that we can't possibly see?
They _only_ reason we get away with this is because the story points we use are relative. They defeat the ability of incompetent management to use them as a ranking system.
That could change though. Taylorism says that management can "scientifically" determine the maximum possible "one true way" team velocity and provide financial carrots and sticks to enforce it.
That day will come unless we can somehow fix our bosses.
Need a little more, getting closer I think.
ReplyDeleteOkay. When you said "retrospective meeting including a 5 minute presentation by a director of the latest research" I did not think you meant that this director were a member of the team. An outsider (ie. consultant/academic not involved in the sw spec & dev) would not belong at a retro, but could participate in a training session. This sounded strange to my ears.
Anyone who participates in an agile team (Customer, etc) is retrospective-worthy. There *should* be Customer/Product/Support/QA/etc at the retrospective. The isolation problem you are talking about sounds like the team only consists of programmers, maybe? Again, sounded strange to my ears.
Finally, I'm not sure I get the point about story points. Not that I disagree, I just am not sure what you're saying about story points as ranking. Ranking of stories or people?
So here's my questions.
ReplyDelete1. Why would a CEO or Director be an outsider? Do we normally need them to be outsiders?
Here's the ranking as I understand it:
It's people, like soylent green. You have to understand, says Fredrick Tayor, that people respond to external motivation, first financial, then peeks, then esteem, etc.
You need to determine what is the maximum possible velocity that a team could achieve, using scientific models and analysis. Then you have to motivate your team to achieve it.
When you fall short of your maximum velocity, responsible managers need to apply motivation techniques, carrots and sticks to various workers as needed.
Not saying any of that is right of course, just that's the cold dead climate we live in.
So I guess what I'm seeing is Agile teams are putting up little walls, and within those walls we can do things right and live civilized and have our warm little campfires. But you can't win against climate.
The climate can and does change every few decades. There was even a time when US industry converted to Deming's principles. There's important history there.
If we don't change the climate again, we will eventually get merged with the prevailing management philosophy. Isn't that what we are seeing happening already? People wanting to do things right are "purists", etc.?
We're getting merged with Taylorism and it is hurting everyone. The more I study statistical process control, the more I'm seeing that it is an ancient advanced form of agile.
And there's more. The history of Craft, then Taylor, then Deming, then WWII, then neo-Taylorism, informs agile a lot.
There's so much and I just don't know where to start.
Anyway, principles 11 and 12 made me twitch. Maybe I don't entirely know why.
I just looked at what I typed and apparently, according to me on a Monday morning, 1 is plural and "peeks," not perks, are a fundamental human motivation. Call me Garfield...
ReplyDeleteMonday: Internet 2, Darrin 0.