Considering the time of year, I'm seizing the opportunity to take a lighthearted look at Santa Claus in order to evaluate him and his organization for their level of agility. Can St. Nick do better? Read on and see.
Santa Claus is agile in the following ways:
- He follows Agile Modeling (AM)'s practice of Use the Simplest Tools: He always makes his list using a paper and pen.
- Santa takes a test-first design because he always checks his list twice.
- Santa promotes teamwork: Unfortunately, he seemed to work very closely with my parents while I was growing up. Sigh.
- Santa delivers on time in regular increments--yes, the iterations are long, but it can't be Christmas every day.
- Santa values the delivery of working toys over comprehensive documentation: His only documentation is the list that he maintains throughout the year.
- Santa travels light: He doesn't keep copies of the lists from previous years, but instead discards his list once the deliveries are complete on Christmas day.
- Santa values individuals and interactions over processes and tools: He treats the elves and reindeer well, and he hasn't tried to needlessly automate toy production or replace his sled with another mode of transport.
- Santa values customer collaboration over contract negotiations: He answers the letters from all kids, yet every written offer that I ever made to negotiate my way out of trouble never got me anywhere.
- Santa values responding to change over following a plan: He accepts toy requests right up to the last minute, and I've never heard about him checking his Gantt chart twice.
- Santa empowers: The elves can build toys in the manner that they see fit, and he works with them as a team to get the job done.
- Santa supports active stakeholder participation: He asks kids to write letters defining their toy requirements. The kids, his project stakeholders, actively help the delivery team by leaving out milk, cookies and carrots.
- Santa takes an emergent approach: Don't forget the time he looked past his own biases and let the unconventional Rudolph lead the way with his glowing nose.
- Santa focuses on simplicity: He has the leanest production system that I've ever seen.
- Santa promotes the value of humility: Do you know anyone more humble than Santa?
- Santa provides concrete feedback: You know whether you've been naughty or nice by the gifts you receive.
- Santa clearly has courage: Although many people have attack dogs and dangerous security systems he still delivers gifts to them.
- Santa encourages face-to-face communication: He appears at a large number of shopping malls, street corners and Christmas parties around the world to discover his clients' gift requirements.
- Santa embraces change: Different toys are delivered year after year. He and his elves always learn how to build the latest and greatest.
- Santa promotes simplicity: His stakeholders can write to him at the "Santa, North Pole" address. People living in Canada and the UK can optionally add the postal code "H0H 0H0" to speed delivery.
- Santa travels light: Only the gifts that he must carry are taken--no more and no less. Furthermore, everything he and his elves produce is a finished product--there are no unnecessary or interim deliverables.
- Santa uses short-term planning horizons: He looks ahead one iteration into the future, at the same time supporting the long-term strategic goal of satisfying his many stakeholders.
- Santa is physically agile: Despite his size, he squeezes down every chimney imaginable.
Despite his many agile aspects, Santa and his organization could still improve.
- Santa needs to shorten the delivery cycle. A regular, annual delivery is nice, but why couldn't he make smaller releases once a quarter, once a month or even once a week? I need new toys all year round, not just every December!
- Santa is the perfect metaphor for the hype in the computer industry. He uses technology that's too good to be true; everybody talks about him, but nobody has seen him; and everybody knows he doesn't exist, but no one dares say so.
- Santa needs to work with his stakeholders more: Instead, he disappears to the North Pole for most of the year where few children can easily reach him.
- Santa is clearly in control, not his stakeholders. As his customer, you're never sure where you stand with him. You never really know what you're going to get until delivery time, and worse yet, the final decision about what you get is completely up to him.
- Santa takes all of the credit, but the elves and reindeer do most of the work.
- Santa could do with some personal refactoring; for example, a good diet.
- Santa doesn't analyze his customers' needs all of the time. How many times have you received socks or slippers when what you really needed was a memory upgrade for your PDA?
- Santa follows a paper-intensive process, taking most requests by mail.
What's the lesson to take away from this discussion? There's always room for improvement, even among the best and brightest. You should always strive to continually improve the way that you work. Everyone here at Software Development wishes you a happy holiday!
I'd like to thank the following people on the Agile Modeling mailing list for their thoughts on this subject: Kenneth W. Boyer Jr., Chris Britton, Larry Brunelle, Paul Clements, Mats Helander, Michael Higgins, Ron Jeffries, Jonathan Kern, Walter J Kirsch, David D. Lucas, Les Munday, David Putman and Jason Smith.
Recently on the Agile Modeling Mailing List:
Throughout November and early December, several discussion threads focused on agile approaches to enterprise issues such as enterprise architecture, data administration and portfolio management. The general consensus was that people need to find ways to work together and that documentation-heavy approaches and/or command-and-control approaches aren't effective. IT groups wishing to support agile software development projects need to recognize that agile project teams have different support needs than traditional project teams. Agile project teams need to understand that they're not working in a vacuum, and that their efforts must reflect the overall vision of the enterprise.
Use Cases and Data Elements
How to write effective use cases is a popular topic on many mailing lists, including this one, and a common problem faced by people new to the Unified Modeling Language (UML) and the Rational Unified Process (RUP)--when all you have is a use-case hammer, everything looks like a use-case nail. Instead of embedding information such as data element definitions, user interface specifications, business rules and other types of data in your use cases, you're much better off modeling that information using other artifacts and then including the appropriate references in your use cases. Use cases are only one of several modeling artifacts.
User Interface Flow
The flow of your user interface--the way your users navigate between screens/pages and reports--is an important aspect of your system's usability. One conversation on the list discussed the idea that the UML needed some sort of user-interface flow diagram so that developers can have a standard way to analyze and design the user interfaces of the systems that they build.
"The Agile Edge." Scott Ambler's monthly Software Development
columns exploring leading-edge issues in agile software
Agile Enterprise Architecture. This page describes how to take an
agile approach to enterprise architecture.
Agile Modeling Mailing List. Visit this URL to find out how to
get involved with the AM mailing list. Everyone is welcome.
Agile Software Development (Addison-Wesley, 2002) by Alistair
Cockburn. This book is an excellent overview of the principles
and concepts of agile development.
Artifacts for Agile Modeling: The UML and Beyond. This page
provides a brief summary of potential models that you may choose
to apply when developing business application software.
Enterprise Unified Process. An extension to the RUP that includes
enterprise management as well as operation and support
"Realistic UML." This essay discusses several problems currently
faced by the UML, including the concept that it's not yet
complete because it doesn't include models for exploring user
interface issues or for modeling databases.
UML Use Case Diagram Modeling Guidelines. This page presents a
collection of techniques for creating effective UML use case