Agile Zone is brought to you in partnership with:

Principal Architect, Pearson Digital Learning Ryan is a DZone MVB and is not an employee of DZone and has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Bumper-Sticker Agile

10.14.2013
| 5559 views |
  • submit to reddit
Years ago I was impressed with an article Josh Bloch published entitled Bumper-Sticker API design, full of "pithy maxims" for creating an API.  I was thinking about this unique approach as I reflected on my years of attempts at following agile methodologies in many of its various and sometimes grotesque forms.
There have been a lot of words spoken both in print and on the Internet about how to be more agile, and it can be hard to filter.  In the spirit of Bloch's post, I distilled my experiences down into my own hopefully-pithy maxims.  The ideas are not original to me, but this list captures what I think is important and maybe it will help you deliver just a little more value, faster.
Call it Bumper-Sticker Agile.

Excel at shipping software first
.  Shipping software early and often is the first competency.  Master this before you focus on anything else.  Continuously deliver.

Don't start with the elimination of waste
.  Don't require a homogeneous tech stack across all teams.  Don't worry about whether teams might be producing overlapping features.  Address efficiency after you have learned how to ship to your customers.

Work tiny
.  Favor smaller iterations over longer ones.  Solicit early feedback and immediately apply it to the next cycle of development.

Treat iterations as experiments
.  Don't be afraid of failure.  If your iterations are small, little will have been lost.  Learn from the result and improve.

If a customer can't see it, it provides the same value as if you didn't build it.  
Iteration without delivery is just one step removed from big up-front design.  You'll get the information you need at the last possible moment rather than the earliest.

Respect the principle of the Last Responsible Moment
.  Delay unnecessary decisions to avoid building unnecessary features.  Remember YAGNI.


Accept your ignorance
.  Stop assuming you know what the best technology is, or what the market wants, or what your customer actually needs.  Instead deliver working code and validate assumptions with a real customer experience.

Optimize around the team
.  Your tools and processes should be in place to support those who do the work, i.e., those typically on the leaf nodes of the org chart.  Optimizing around any form of centralized management, including project or product management, takes power away from the team.

Empower teams with cross-functionality
.  An organization silo'ed by function (dev, test, ops, dbas, product, pmo, etc) will defeat collective code ownership.  Factions will be concerned with only their particular function.  Instead, group roles together on a single team and give it sole authority.

Be transparent
.  Every member of the team should be able to know what everyone else is working on.  The team should have nothing to hide from stakeholders or each other.

Radiate the right information
.  Make it easy to see what the team values, whether it's the status of tasks, tests results, velocity, or whatever they choose.  Physical radiators are often more effective than electronic radiators.

Turn POCs into MVPs
.  Proofs of Concept don't deliver value and often unintentionally end up in production.  Use real deliverables to test out new technology.

Make testing and refactoring first-class citizens
.  One implies the other.  Do both in tandem to combat software entropy.

Agree on a definition of done
.  All stakeholders should understand what done means.  Don't change the definition mid-iteration.  Automate it if possible.

Pair program rather than holding KT sessions
.  "Knowledge transfer" done by Big Group Meeting has terrible retention and results in little sense of ownership.  Work with someone side-by-side if you want them to understand what you're teaching them.

Don't "hope" for good outcomes
.  Make rational decisions based on real data.  Measure that which you do not understand, or about which you have insufficient data to reason.  Prefer taking action to lengthy deliberation.

Stand-ups are for the team
.  Don't allow the meetings to become status updates to a single person.  The team should be talking to each other about a shared commitment.

Keep stand-ups short
.  Stand up.  Don't allow one task or story to monopolize the discussion.  Don't bring laptops.  Don't go longer than 15 minutes.


Accept that being agile is hard
.  Pair programming is hard.  TDD is hard.  Continuous improvement is hard.  As you transform into an agile organization, expect pain and be ready to stay committed despite failure.
Published at DZone with permission of Ryan Nelson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)