Card-carrying Django developer, Cezar Jenkins, shows off the autographed deck he won at the Chicago Python users group meeting. His superior memory allowed him to edge out the other attendees and seize the prize!
Card-carrying Django Developer
Card-carrying Django developer, Cezar Jenkins, shows off the autographed deck he won at the Chicago Python users group meeting. His superior memory allowed him to edge out the other attendees and seize the prize!
Card-carrying Agile Author
Card-carrying agile author and programmer, Tim Ottinger, smugly shows his plastic-wrapped Agile In A Flash deck at home. Tim is the originator of the Agile In A Flash concept, and co-author of the deck with Jeff Langr (without whom this project would have died on the vine). Feeling smug? You betcha.
Card-carrying software journeyman
Card-carrying software journeyman, Corey Haines, shows off his deck and a broad smile at a Chicago Starbucks outlet.
Getting the Word Out
By now, many of our readers (perhaps all) have recieved copies of the Agile In A Flash. The feedback we have received has been very positive and we are very encouraged. I understand that a few decks even traveled to the Agile Manifesto event in Salt Lake City.
Our goal is to get this tool into the hands of coaches, trainers, managers, product owners, and development teams all over the world. Since the book has only been out for less than one month, we don't have a lot of information about our sales, but we know from twitter that we are selling on several continents and that people are finding value in the books.
Our goal is to get the cards in the hands of the people who are really doing the work: your project team and its neighbors in the business where you work. If you are interested in helping promote the Agile In A Flash project:
Our goal is to get this tool into the hands of coaches, trainers, managers, product owners, and development teams all over the world. Since the book has only been out for less than one month, we don't have a lot of information about our sales, but we know from twitter that we are selling on several continents and that people are finding value in the books.
Our goal is to get the cards in the hands of the people who are really doing the work: your project team and its neighbors in the business where you work. If you are interested in helping promote the Agile In A Flash project:
- Let your employers know that you are getting value from the deck, and maybe ask to outfit the whole team!
- If you are a member of a user group or software interest group of any kind, talk to us about promotional give-aways. We might hook you up with discount coupons or maybe even a deck or two.
- On Feb 22, Java Ranch is holding a promotional event for us. Join us!
- A review at your favorite on-line book retailer will encourage others to try Agile In A Flash.
- Keep us in your tweets and status updates.
- Send us a "Card Carrying" picture. We'll post them here. Maybe someone will be inspired!
- Send us your great promotional ideas. We're all ears.
- This blog could use a Digg or Reddit or HackerNews vote.
- Vote us up at CodeBix
Anniversary
Agile In A Flash is published in the 10th anniversary year of the Agile Manifesto. It hit the shelf only weeks before the reunion gathering in Salt Lake City. We thank the original authors and signatories for providing us with a good foundation for our practice, and we look forward to whatever lies ahead.
Join the celebration by popping over to the Tenth Anniversary site. Read the articles, check out the photos, and join the dialog.
Join the celebration by popping over to the Tenth Anniversary site. Read the articles, check out the photos, and join the dialog.
Two Agile Works that Work Great Together
Have you seen The Agile Samurai yet? We're currently reading it, and really enjoying it. You may see some new Samurai-inspired cards on this site in coming weeks. Jonathan Rasmusson has had kind things to say about Agile In A Flash as well.
Pragmatic programmers have recognized the value of these two works together, and offer a special deal on the physical works tucked away in their latest podcast announcement:
Pragmatic programmers have recognized the value of these two works together, and offer a special deal on the physical works tucked away in their latest podcast announcement:
Don’t forget our special discount on our latest agile-themed titles. Save 35% on the paperbacks if you purchase both Agile in a Flash and The Agile Samurai. Just put both paperback books in your cart, and the 35% discount will be automatically applied. While supplies last. Does not apply to prior purchases, or to ebooks; do not read while operating heavy machinery, pages may be slippery when wet.
The Big Four
There are many concerns for software design and architecture, including functionality, scaling, performance, extensibility, backward compatibility, platform compatibility, future-proofing, the list goes on and on. However, for a system to continue to be workable (maintainable, readable, extensible, correctable) there are primarily these four large concerns.
Software developers have pondered the question of "design rot" as long as there has been software, and have realized that the internal structure of a software system is vitally important to its continued success, just as external factors are critical to user acceptance.
Object-oriented design has provided tools for managing continued workability, but many developers today have not received a well-grounded education in software structure. They are instead pushed to make software that lacks internal structure, but works and is appealing in concept or user interface.
We are presenting a series of articles via the Pragmatic Bookshelf magazine, which we hope will fill in the gaps:
Promo Video Contest
Tim and I aren't videographers (although I do like his video, see the previous post in this blog). Nor are we in real, day-to-day teams right now (I'm doing on-customer-site consulting, tough to get permissions and such). So we're looking for someone to provide us with a cool video that shows your team's use of Agile in a Flash, and helps promote the book.
We're offering as a prize a ten-pack of cards ($110 at PragProg) for the video we choose as the best. In return, you'd grant us rights and permissions to use the video and whoevers' likenesses for promotional use.
Please email me (jeff at langrsoft.com) if you have any further questions about the contest.
Contest deadline: February 28, 2011
Legal stuff: This is all arbitrary, and Tim and I reserve all rights, including the right to not choose a video if none suits our promotional needs.
We're offering as a prize a ten-pack of cards ($110 at PragProg) for the video we choose as the best. In return, you'd grant us rights and permissions to use the video and whoevers' likenesses for promotional use.
Please email me (jeff at langrsoft.com) if you have any further questions about the contest.
Contest deadline: February 28, 2011
Legal stuff: This is all arbitrary, and Tim and I reserve all rights, including the right to not choose a video if none suits our promotional needs.
The Deal
Agile In A Flash is not a replacement for coaching, training, consulting, and those wonderful books that my colleagues have written. Agile in a Flash is a great way to get started, and a great tool for coaches, trainers, and consultants to use in teaching Agile software development to their clients and colleagues.
This is our first released video about the cards. Stay tuned.
Released.
It's here! After a few years of writing, a lot of editing, a bit of promotion, and a whole lot of work, Pragmatic Programmers has released Agile In A Flash.
To our knowledge there is not another product like this one anywhere in the world, on any topic. We've worked hard to make something useful and unique for our Agile community. We have spent a lot of time on format and form factor, phrasing, clarifying points when possible, and weeding out the cards that seemed less useful. As a result of our extreme culling and revisits, you will find powerful advice in a surprisingly small package.
Pragmatic Programmers helped us to make it affordable for teams and companies alike, and individual copies are not out of "impulse purchase" range. This was a departure from their normal publishing activities, but they believed in it and did a lot of legwork to make it possible. They've been supportive and amazing, and I hope you will reward them with your custom.
Thank you for your comments, reviews, tweets and retweets. Today the project is entirely "real" and we appreciate all our readers have done (and may continue to do) to make this crazy little idea work.
To our knowledge there is not another product like this one anywhere in the world, on any topic. We've worked hard to make something useful and unique for our Agile community. We have spent a lot of time on format and form factor, phrasing, clarifying points when possible, and weeding out the cards that seemed less useful. As a result of our extreme culling and revisits, you will find powerful advice in a surprisingly small package.
Pragmatic Programmers helped us to make it affordable for teams and companies alike, and individual copies are not out of "impulse purchase" range. This was a departure from their normal publishing activities, but they believed in it and did a lot of legwork to make it possible. They've been supportive and amazing, and I hope you will reward them with your custom.
Thank you for your comments, reviews, tweets and retweets. Today the project is entirely "real" and we appreciate all our readers have done (and may continue to do) to make this crazy little idea work.
New PragProg article: Code Coupling
Our latest in our series of "big ideas in software" is now available and appearing in the PragPub January 2011 issue. This is the second article out of four, each covering one of cohesion, coupling, abstraction, and volatility. In this article on coupling, we talk about the impacts of too many dependencies in your software, and what you can do to prevent it.
In addition to the HTML version, you also find PDF, epub, and mobi versions of the article here.
Agile in a Flash is slated for publication on January 20! You can advance-order now from Amazon; you'll also soon be able to order in bulk, at a discount, from PragProg directly (and this is the kind of thing for which you'll want a separate copy for everyone on your team).
Meanwhile, Tim and I are banging out the next article, on abstraction, in the series. If you have any advance thoughts on what you'd like to see covered, drop a comment here or send us a line.
Thanks for reading!
In addition to the HTML version, you also find PDF, epub, and mobi versions of the article here.
Agile in a Flash is slated for publication on January 20! You can advance-order now from Amazon; you'll also soon be able to order in bulk, at a discount, from PragProg directly (and this is the kind of thing for which you'll want a separate copy for everyone on your team).
Meanwhile, Tim and I are banging out the next article, on abstraction, in the series. If you have any advance thoughts on what you'd like to see covered, drop a comment here or send us a line.
Thanks for reading!
On its way!
The current theory is that the decks will be available (and quite affordable) in mid-to-late January, probably pushing toward the "late" bit. I'm incredibly excited about it, and hope you will be too!
Shu Ha Ri
The latest PragPub issue is out with our latest Agile in a Flash-related article, Sh Ha Ri: Learn, Detach, Transcend: Steps to Agile Mastery. Or go to the PragPub magazine page and choose a different format (PDF, epub, mobi, and HTML are available).
This article expands on some of the thoughts we presented in our original Agile in a Flash blog post on shu ha ri (complete with card facsimile). Shu ha ri is one of the cards we present in the soon-to-be-published PragProg deck.
This article expands on some of the thoughts we presented in our original Agile in a Flash blog post on shu ha ri (complete with card facsimile). Shu ha ri is one of the cards we present in the soon-to-be-published PragProg deck.
Under Test
Apologies to AIAF readers. The article sent in RSS was intended to appear at AgileOtter blog, not here.
This is the problem with having multiple Blogger accounts starting with A, and writing at night when you are less wary about checking site names when writing. Apologies to readers and to my coauthor for the slip-up.
This is the problem with having multiple Blogger accounts starting with A, and writing at night when you are less wary about checking site names when writing. Apologies to readers and to my coauthor for the slip-up.
Agile In A Flash - Whew!!
We are off to the copy editor, and that means your Agile In A Flash cards are coming soon.
See the official Pragmatic Bookshelf page!
See the O'Reilly catalog entry!
See the Amazon catalog entry!
See the ongoing series of articles in PragProg Magazine!
See the happy authors!
Thanks to everyone for the support and reviews and ideas and permissions. It's fun to see a dream come true!
Now it's time to go replace my exclamation mark key. ;-)
See the official Pragmatic Bookshelf page!
See the O'Reilly catalog entry!
See the Amazon catalog entry!
See the ongoing series of articles in PragProg Magazine!
See the happy authors!
Thanks to everyone for the support and reviews and ideas and permissions. It's fun to see a dream come true!
Now it's time to go replace my exclamation mark key. ;-)
New PragProg article--What Agile is Not
Latest update: The Agile in a Flash project is nearing final draft, close to being sent to production! Once that happens (perhaps end of next week), it's 6-8 weeks away from shipping to you.
Meanwhile, our latest PragPub article (available in multiple formats--see the PragPub magazine index--is out. It's called "What Agile is Not" and talks about some of our experiences with agile. Looking at the article, though, I wonder about the lead-off sentence for our conclusion paragraph:
"The advice from Kent Beck and Ron Jeffries for successful adoption of Agile Software Development has always been to start with the values. "
But is that true? I believe there have been some recent statements to the contrary on one of the mailing lists. My apologies to Ron/Kent--that's how I've always looked at things, so perhaps I'd projected my misinterpretation on their teachings. Feedback please?
Article at Prag Prog, More to Come!
This is a news update, not another card, but our latest article is up at Pragmatic Programmers.
We've gone a few weeks without a new card here, but it's because we've been working on the final versions of our cards to be published by Pragmatic Publishers "Real Soon Now." You will find a lot of familiar content, but even more polished and even more condensed. You'll get to enjoy physical cards, suitable for sticking and sharing with your whole team or company. Even better yet, they'll have been edited by actual professional editors.
We're not going to quit the blog, but we are going to be available in more forms than ever before. PragProg will release AgileInAFlash as physical cards and as ebooks. Imagine how cool "Courage" or "ABCs of Pair Programming" will look on your hot little iPad or Android phone! You'll have virtual Tim & Jeff everywhere you want to take us. This blog continues to be a place to write your comments, or to see cards never before released into the wild.
When you get your deck(s), take a picture of yourself using the cards and send it to us. We'll be thrilled and honored to see how you use your AgileInAFlash in your daily work!
Blessings.
Tim
We've gone a few weeks without a new card here, but it's because we've been working on the final versions of our cards to be published by Pragmatic Publishers "Real Soon Now." You will find a lot of familiar content, but even more polished and even more condensed. You'll get to enjoy physical cards, suitable for sticking and sharing with your whole team or company. Even better yet, they'll have been edited by actual professional editors.
We're not going to quit the blog, but we are going to be available in more forms than ever before. PragProg will release AgileInAFlash as physical cards and as ebooks. Imagine how cool "Courage" or "ABCs of Pair Programming" will look on your hot little iPad or Android phone! You'll have virtual Tim & Jeff everywhere you want to take us. This blog continues to be a place to write your comments, or to see cards never before released into the wild.
When you get your deck(s), take a picture of yourself using the cards and send it to us. We'll be thrilled and honored to see how you use your AgileInAFlash in your daily work!
Blessings.
Tim
Basic Agile Flow
Tim Ottinger and Jeff Langr
There are many ways to conduct an agile project. Some work with huge backlogs, some with spur-of-the moment requirements, some have continual release, some have non-time-boxed continual flow. We recommend starting with the structure shown on this Agile in a Flash card.
Following this plan, the customer team puts together a prioritized list (feature backlog) of desired features for the upcoming product release. The release is broken into iterations, and the team and customer agree on what will be delivered at the start of each iteration (no sooner). The iteration is of fixed length, something that allows the team to begin gathering consistent data, which in turn they feed back into their estimates and subsequently a larger plan. Upon incrementing and iterating the software a few times, the software reaches a state that it may be released to the customer. Does the system implement the agreed-upon features (did it pass all of its acceptance tests)? Yes: Release to production!
The flow outlined above is a reasonable starting point for a team transitioning to agile. It represents a kind of "Shu" in the Shu-Ha-Ri cycle, where one follows a certain technique or style for a while to build up their ability to perform it. In fact, both of us started with this basic pattern and found that it worked just fine.
As you move to more "Ha" stage, you might experiment with reducing the size of stories so that more of them are done and "in the can" before the end of the iteration. You might work on making the software releasable at every iteration boundary. You might shorten your iteration period so you can gather data more often, provide smaller increments to certification, and get feedback from users more quickly. You might pick fewer stories per iteration. You may experiment with self-organizing to get work done. It is a waste to spend a lot of time detailing features which may be done in the remote future or not at all, so you may reduce the entire feature backlog to perhaps a handful of stories. You may learn (as Deming recommends) to use more effective quality practices and eliminate a "certification" stage, as indeed many software shops are doing (research topic: continual release).
Once you are into the Ha and the Ri stages, using agile principles and values should lead you to more informal yet more effective approaches. Here's an "agile flow" card for the more seasoned agile team:
In a bit more detail:
- The customer describes a small subset of needs orally, to the team.
- Through negotiation with the customer, the team commits to completing code that satisfies some, most, or all those needs in a given period.
- The team agrees on a working set of rules that define how they will deliver quality code, under good, sustainable working conditions, in the specified period. (Hint: The team might use retrospectives to help derive and tweak the rules.)
- Repeat. This magic word allows the introduction of things like projects containing releases, and releases containing iterations. Or not.
Acceptance Test Design Principles
Jeff Langr and Tim Ottinger
Acceptance tests (ATs) are as enduring and important an artifact as your code. The proper design of each will minimize maintenance efforts. You'll recognize some familiar concepts--Kent Beck's rules for simple design and some classic OO principles apply well to the design of acceptance tests.
Abstract. A test is readable as a document describing system behavior. Uncle Bob's definition for abstraction applies equally well to tests: Amplify your test's essential elements, and bury its irrelevant details and clutter. Anyone, including non-DBA and non-programming staff, should be able to follow the steps taken in the test, and understand why it passes. Extracting duplicate behavior to a common place--the AT analog of programming's extract method--is the main workhorse that allows you to increase abstraction at the same time you remove duplication.
Bona fide. To ensure continual customer trust, a test must always truly exercise a system as close to production as possible. Passing acceptance tests tell the customer that what they asked for is complete and working. But once the customer has doubt as to what your tests exercise, you have severely damaged your ability to continue using them as contracts for completion.
Cohesive. A test expresses one goal accomplished by interacting with the system. Don't prematurely optimize by combining multiple scenarios into a single test. Keep single-goal tests simple by splitting common content into separate fixtures. Yes, this will mean your acceptance test suite runs more slowly, but it's far more important to avoid compromising clean test design. (It's also why your unit test suites should be as fast as possible.)
Decoupled. Each test stands on its own, not depending upon or being impacted by results of other tests. A failure caused by problems in another test can be difficult to decipher.
Expressive. A test is highly readable as documentation, not requiring research to understand. Name it according to the goal it achieves. As with unit tests, refactor each test to improve the ability of a third party to understand its intent. You should always eliminate magic numbers, replacing them with constants as appropriate. Improve visual accessibility by formatting your test using Arrange-Act-Assert (AAA). You should also make it clear what context is being set up in the test; one way is to incorporate additional assertions that act as preconditions.
Free of duplication. Eliminate duplication across tests (and even within the same test) before it eliminates you! Duplication increases risk and cost, particularly when changes to frequently-copied behavior ripple through dozens or more tests. Duplication also reduces the use of abstraction, making tests more dense and difficult to follow.
Green. Once a story is complete, its associated ATs must always pass. A failing AT should trigger a stop-the-line mentality. Don't allow your test suite to fall into disarray by allowing failures to be ignored!
Acceptance tests (ATs) are as enduring and important an artifact as your code. The proper design of each will minimize maintenance efforts. You'll recognize some familiar concepts--Kent Beck's rules for simple design and some classic OO principles apply well to the design of acceptance tests.
Abstract. A test is readable as a document describing system behavior. Uncle Bob's definition for abstraction applies equally well to tests: Amplify your test's essential elements, and bury its irrelevant details and clutter. Anyone, including non-DBA and non-programming staff, should be able to follow the steps taken in the test, and understand why it passes. Extracting duplicate behavior to a common place--the AT analog of programming's extract method--is the main workhorse that allows you to increase abstraction at the same time you remove duplication.
Bona fide. To ensure continual customer trust, a test must always truly exercise a system as close to production as possible. Passing acceptance tests tell the customer that what they asked for is complete and working. But once the customer has doubt as to what your tests exercise, you have severely damaged your ability to continue using them as contracts for completion.
Cohesive. A test expresses one goal accomplished by interacting with the system. Don't prematurely optimize by combining multiple scenarios into a single test. Keep single-goal tests simple by splitting common content into separate fixtures. Yes, this will mean your acceptance test suite runs more slowly, but it's far more important to avoid compromising clean test design. (It's also why your unit test suites should be as fast as possible.)
Decoupled. Each test stands on its own, not depending upon or being impacted by results of other tests. A failure caused by problems in another test can be difficult to decipher.
Expressive. A test is highly readable as documentation, not requiring research to understand. Name it according to the goal it achieves. As with unit tests, refactor each test to improve the ability of a third party to understand its intent. You should always eliminate magic numbers, replacing them with constants as appropriate. Improve visual accessibility by formatting your test using Arrange-Act-Assert (AAA). You should also make it clear what context is being set up in the test; one way is to incorporate additional assertions that act as preconditions.
Free of duplication. Eliminate duplication across tests (and even within the same test) before it eliminates you! Duplication increases risk and cost, particularly when changes to frequently-copied behavior ripple through dozens or more tests. Duplication also reduces the use of abstraction, making tests more dense and difficult to follow.
Green. Once a story is complete, its associated ATs must always pass. A failing AT should trigger a stop-the-line mentality. Don't allow your test suite to fall into disarray by allowing failures to be ignored!
Agile Success Factors
Jeff Langr and Tim Ottinger
Font: Brown Bag Lunch
Pop quiz, hotshot.
Q. "You're not agile if you don't ... "
A. Select one more of the following:
| a. | Have daily stand-up meetings | |
| b. | Pair program | |
| c. | Do TDD | |
| d. | Employ a metaphor | |
| e. | Have a ScrumMaster | |
| f. | Run iteration planning meetings | |
| g. | Use index cards |
The answer is H, none of the above. Practices are just that--specific techniques a team might or might not employ to aid them in being agile--whatever agile means. Here's our definition: Agility means you are able to frequently and continually deliver high-quality software that meets the customer's needs.
The agile manifesto lays out four core values ("working software over comprehensive documentation," e.g.) and a dozen or so principles. But what factors truly make an agile team successful?
Freedom to change. Incremental change, one of the other success factors, can only occur if your teamis able to change how they work without outside interference. Meddling and micromanaging, never mind the intentions, usually divert the team from what should be everyone's goal of shipping quality software. Get the right people in place in your organization to support the team's rightful decisions, and to not try to change them. We'll be blunt: Conversely, this may mean removing the wrong people from the chain of influence.
Energized team. The successful agile team just gets it. They want to work this way. We can walk into a room and generally see whether or not a team will succeed. A good team is highly transparent and visibly enjoying what they're doing. They've built a true team spirit, and no one talks about "my code" or "my stories." They collaborate without being told; they hold their own stand-ups without a project manager having to crack the whip. They always act to protect the product and its integrity--they don't discard quality controls even when under intense pressure to deliver. They also look for ways to make life better for everyone--"How can I rework this test so that the next developer will understand my intent?" They'll step in and help anyone as needed to deliver quality product, even if it's "not their job."
While we like to think a good, energized team is all it should take, lack of freedom to change will demoralize even the best teams, to the point where your guys who "get it" choose to move on to something less oppressive.
Commo (line of communication) to customer. A product is an intricately detailed ship that must be well understood and constantly steered. The best teams we've seen have been steered by a strong, enthusiastic single-person, dedicated customer who truly understands what needs to be built. This customer has the time to ensure that everyone else can learn from them what needs to be built. While the strong customer can have a supporting cast, a large, committee-style product management team simply doesn't work. (It's always unfathomable to us that most companies are willing to staff development teams with no end of apathetic dregs, but are unwilling to pay well for strong people who know what product to build.)
Attention to quality. The code is your product, and, unlike most other products, one you will continually build on and shape to meet continual new customer demand. If you fail to pay attention to quality, you will eventually slow down in your ability to meet demand, sometimes to the point of stagnation. The team must ensure that the code is clean enough to accommodate new incremental customer needs. Attention to quality is never a separate task on a plan; it must be embodied in everything you do to build your product, including coding, design, documentation, testing, automation, tracking, communication, and so on. Quality must be incrementally and continually addressed.
Incrementalism Most of the practices you employ in agile have something to do with ever-smaller steps. Instead of a massive requirements document, you allow the customer to provide features just in time, in small chunks described on little index cards. Instead of a comprehensive up-front design document, you learn how to design on a task-by-task and test-by-test basis. And so on. You must learn to think incrementally.
You must also look to correct course continually and incrementally. For every few lines of code added or changed, take time to ensure the design is as good as you can get it. (Which you can only do if you have enough controls in place to allow frequent code improvement. Best way we know how to get there: TDD.) Not only do you need to correct course in the product, you need to always correct course in your team. You should always be introspecting about your team, probing for ways it's not performing optimally, and working to correct these problems. Retrospectives are a good start.
A successful agile project is not a bunch of hare-like sprints to the finish line. It is a cool-headed, tortoise-like, slow 'n' steady approach of small, well-reasoned steps. Each step is an opportunity to look up and see where it got you--closer to the finish line or further away? It's easy to correct a single misstep. In contrast, a single mad sprint in the wrong direction can take you pretty far off course from the finish line.
Automation. There are numerous ways to waste people's time on a software development effort--running automatable regression tests manually, for example, or suffering a build process that unnecessarily requires multiple manual steps or manual verification. Agile cannot work unless you automate as many menial, tedious, and error-prone tasks as possible. There's simply not enough time across a two-week period to get any real work done if you have to slow down for numerous manual gating processes.
Subscribe to:
Posts (Atom)