Blog Posts tagged with: agile

Dec 24 2012


The Real Secret Behind Project Failure

To the owner of a failed software project, there is little consolation that roughly forty to seventy out of every hundred other projects have also failed to meet their goals.

This sad math reflects a simple truth - delivering software solutions to hard business problems is, well... hard. Teams lacking sufficient technical skills are obviously doomed from the start. But a respectable lineup of developers merely gets you in the game. Projects making this first cut now must endure an onslaught of other challenges, from ambiguous requirements and unclear priorities to unrealistic schedules, poor communication, insufficient planning, and unmanaged risks. In other words, as a product owner embarking on a new assignment, the biggest threats to your success are not technical problems at all. At Relevance, we understand that software development is mostly a people problem.

This is why aside from employing an amazing group of developers, designers, and architects, most Relevance projects receive the direct attention of a Relevance coach to minimize the non-technical risks to your project, and to help great people accomplish great things.

So what exactly does a coach at Relevance do? A partial answer can be found in an episode of the Relevance podcast, but the conversation is sporadically interrupted by loud monkey noises (oddly not present at the time of the original recording). In true agile fashion we shall adapt and repeat, and our answer will focus on outcomes rather than activities. When clients ask us "What is the role of a coach at Relevance," we've found what they're really asking is "How will my project benefit by having a Relevance coach on the team?"

Read More »

Sep 18 2012


The Secrets of Building Software

I was privileged to be asked to speak at the CED TechVentures 2012 Entrepreneurs Workshop this year, and I was part of a series of 8 speakers, each given 7 minutes to talk about aspects of the startup process. My topic was "Secrets of Building Software". Seven minutes is not a lot of time, but I wanted to capture my thoughts from my talk and add a point that didn't make it into my time on stage.

So, here are the 6 (now 7) secrets:

1: The first secret of tech startups: everyone must code

Your team of founders might bring a ton of knowledge, creativity, and experience to the table, but at least one of you must know something about writing code. Just like if you were starting the All American Pie Company, one of you must know how to bake. Or if you were starting 37HorseFarms, one of you must know something about horses. See, the thing is, programmers are a proud, vainglorious lot, and they have a finely tuned sixth sense: they can tell who knows what they are talking about and who doesn't. You need someone with a big enough clue to show up on their radar or, in the immortal words of a previous boss, they will "flip the bozo bit" on you. And trust me, once flipped, that bit don't flip back. Once a bozo, always a bozo, and you may as well try starting that horse farm.

Now, I'm not saying you have to run out and become DHH. But at least one of the founders must know the difference between a web application and an iOS app and be able to say "I'm not sure I follow, but do you mean X?" without "X" being some value of stupid.

2: Get to know your OFR

A lot of people like to talk about building your MVP (minimum viable product). I'm not a huge fan of the term. When somebody has a grand idea for a system, somewhere in his or her head is a Perfect Sparklepony, trying desperately to get out. When you say "MVP", you make them think you are going to turn their Sparklepony into a severed hoof. Minimum Viable Product is all about cutting things, eking things out, squeaking by. It isn't an optimistic phrase.

I prefer the term "Optimal First Release". Optimal means you aren't cutting scope; you are communicating your unique value so that people care that you exist. I hear from founders all the time that there is already a primary competitor in the space, and their "MVP" has to be feature-comparable with that competitor or nobody will buy it. Really? Who would buy a feature-for-feature knock-off of the thing they already have? Why bother? If you aren't thinking differently, then what is the point?

What you need to do is figure out what you are doing differently, and do that, just that. Oh and do it as excellently as you can. Here's the thing - you can definitively prove that you can eventually do that other stuff. How? Point at the competitor. THEY did it, and, as you already know, THOSE guys are LOSERS. If they could do that, so can you. And everyone will believe that. What sets you apart is that OFR - the thing that only you can do. You can catch up on the rest.

3: Features - Speed - Quality: Pick One

You've heard the "pick two" thing before, and if you haven't, well, there's a whole bunch of books you should read, starting with "The Mythical Man Month" and working forward from there. Fast-forward to now, and here's what I'm telling you: optimize quality over features and speed. Every time. The world is full of poorly thought out features that don't string together coherently. But there is an painful shortage of carefully crafted, easy to use software that makes people's lives better instead of worse. We are all drowning in software that we have to use, and systems that subtract years from our lives and deaden our souls. Spend time making software that's a joy to use. Nobody gets excited by checklists of features; but they thrill to quality.

Keep in mind that there are multiple definitions of "quality". There's how well the code is written, and there's how well the feature is received. High quality code is easily maintained, scales well, doesn't break under simple stresses, and is a joy to work with in the future. High quality features are written from the user's point of reference, cover the majority of cases with the smallest amount of user effort, and enable the user to spend more time on important stuff instead of clicking on random crap. The first stuff is important for you, and the second stuff is important for your customers. Make sure you plan for both.

4: Friends don't let friends code alone

Software should never be developed in isolation. Programmers the world over suffer from the same character trait: after 15 hours of staring into a monitor listening to the Tron soundtrack, they cross over into "I'm a genius" mode where their crazy, never-been-tried-before solution is clearly the best way to do whatever it is. And the simple convenience of a second set of eyes is usually all the inoculation we need to avoid this syndrome. Don't let anybody in your world fall down this rabbit hole. Even, and especially, yourself. Get a buddy. This does not necessarily mean you have to practice pair programming the way we do at Relevance. It does mean that you shouldn't be shipping features that have only had one person involved in their creation.

5: Software Development Plans that go More than Four Weeks are Comic Books (and they probably have pretty pictures, too!)

Grand plans may be sweeping, majestic and even convincing, but they are also fictional, and should be enjoyed as such. When somebody shows me a development timeline that shows specific features being delivered on specific dates months in the future, I assure them that the only thing I'm 100% certain of is that the plan, as written, won't happen. Weathermen can't predict the temperature three days from now, because the weather is a chaotic system. Software is a chaotic system too, made of people, and technology, and business goals, and money flows, and geopolitical problems, and, well, life. You can't predict that far in the future. You can SET GOALS. You can MAKE PLANS. But you should know that those plans are going to change. Operate on hardcore, short-term, iterative planning that helps you steer.

Look at it this way. It is 1492, and you are standing aboard the Santa María. Her prow is valiantly aimed to the west. You know you are embarking on a sea voyage. You have to know vaguely how long it is going to take, and how many men to man the ships so you can pack the right amount of food, supplies, etc. But what is the target? Is it "the Port of Tokyo in 194 days?" Or is it "Japan, hopefully before winter"? The key point is to be able to steer, and adjust, and maybe take advantage of the New World when you stumble on it along the way.

6: Software Development is Mostly a People Problem

Don't listen to people who tell you there is only one way to solve any particular problem. "Oh, you HAVE to use Oracle for that." "This is clearly a problem for Python." "Rails is the sendero luminoso." Forget that; tools serve the craftsman. Find people you can trust and can work with, and let them use the tools that make them most effective. 90% of the problems they'll be solving for you aren't algorithmic anyway, so help get the tools out of the way of the problem-solving by being flexible about them in the first place.

Clearly, there are limits to this rule; there are tools that AREN'T capable of solving certain problems. You can't turn SQLite into a cloud-scale graph database. You can't use iCal as a word processor. You'd never want to get COBOL running on an iPhone. But when multiple tools CAN solve the same problem, optimize for the people.

7: Don't Take the Easy Way Out

Focus on simple, for everyone involved in the system. You, your developers, your investors, the users, everybody. Build simplifying things, make them awesome, and don't scrimp trying to get there. There are no easy ways out; somebody always has to pay the price. When you take the easy way out when building software, it is usually at your users' expense.

Let me give you a story, told to me by one of the Relevance team. She has used the same exterminator for years. In every year before this one, the exterminator would show up, do whatever they do, then write a one-page note saying "I was here on this date, I did these things, and here's what you owe." Then the exterminator would tape it to the door and leave.

This year, the exterminator approached her after the job was done and asked if she could sign off on the work. Saying "yes,", the exterminator proceeded to haul a full-sized printer and a hand-held device into her kitchen, make her spend 15 minutes trying to sign on the crummy hand-held device, then spent another 15 minutes printing out three pages of paper with a bunch of details and boilerplate and a poor representation of her signature. Incredulously, she asked "what is the point of all this?" His response was telling: "they say it makes it easier on the back-office folks."

The "easy" in this case is that the system now makes it easy to process all those work streams and invoices and pieces of paper. But the exterminator AND HIS CUSTOMER spent an extra 30 minutes struggling through a difficult process to finish the job. And the kicker — the evil secret here — is that there aren't any "folks" in the back-office anyway; they've been replaced by Skynet, who is really loving having his fleshy robots out doing all the drudge work.

Great software is about removing difficult, boring, repetitive, failure-prone, tangled, messy, awful things from the world. Easy is about foisting your pain onto somebody else. And you almost always arrive at "easy" by starting at "cheap". Think carefully about the investment you are about to make into the system, and the change you want that investment to have in the world. And spend wisely on simple, high-quality, well-developed, easily-digested releases so you can succeed in a world desperate for real successes.

May 02 2012


Why Retrospectives Should Get Personal

What do you get when you cross a bunch of passionate, self-directed engineers with an agile, iterative approach to both software and personal development? Predictably, you get continuous delivery of customer value and solutions to really hard problems. Additionally, as a nifty bonus, you get a new kind of discussion forum that brings all the best qualities of agile software development to individual improvement: the Personal Retrospective.

Before your imagination goes too far, let me assure you this does not require hugging, silly hats, or revealing favorite brands of underwear. Nor is there screaming into a mirror or "Fight Club" activities of any sort. The Personal Retrospective is an undertaking at Relevance that forms a cornerstone of our company culture and a critical ingredient to our goal of continuous improvement at all levels.

Great Feedback in 60 minutes or Less

The key ingredients for a Personal Retrospective at Relevance are five or so team members who have first hand experience with the subject's recent performance and another Relevance employee who serves as a neutral facilitator for the discussion. During the meeting, the individual is provided with an hour of open and honest feedback which validates and appreciates areas where they are providing their best value to their team and clients, and calls out ways they may not be meeting the mark or have the greatest room to grow.

An agenda is set ahead of time by the subject (with the help of the facilitator) to focus the feedback on areas and goals most important to them. The experience can be extremely positive, giving deeper insight into the impact your actions have had on those around you, as well as deeply emotional as you hear the negative effects even your best intentioned actions have had on the team.

Sometimes there are surprises, though often the subject has at least some notion of where things are not going great, and a critical component of a successful Personal Retrospective is a list of clear action items and mechanisms to encourage and monitor improvement once the meeting concludes.

I Never Thought it Would Happen to Me...

Recently I had the opportunity to participate in my own Personal Retrospective to evaluate current performance as an Agile Project Manager and Coach. Although I had requested the meeting and chose the attendees, it was still quite intimidating to hear several people who I respect greatly talk about me both positively and critically (and often in the third person as guided by the facilitator to ensure the messages are clear and actionable). In the end though, it worked wonders to quiet the distracting internal voice of insecurity by hearing where my efforts are helping the team. Additionally, it helped me understand where I have been dropping the ball, along with recommendations on how to get on the right track.

The guesswork has been largely eliminated in the form of a group of trusted peers stating "This set of things you do, they are really good; keep doing them. This other set of things, you're doing okay, and here are some tweaks to make them better. And this set of things, these actions are having a negative effect on us and the project; here are examples of them and some clear ways to change these behaviors."

Bringing the Love Home

This isn't a review. No money, position, or responsibility changes are made as a direct result of what is said. It is a safe forum for enabling feedback to help folks at Relevance along in their journey. Such a personal and sometimes difficult meeting may not be for everyone nor for every organization, but it is an option you and your team should consider when looking for additional ways to get to the next level of individual and group performance. If you'd like more specifics on how the process works, give us a shout and we'll be happy to help. If it doesn't work, you can always go with the silly hats and underwear stories.

Feb 07 2012


Agile Reboot: Putting the Man back in Manifesto

“Individuals and interactions over process and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.” That's the entirety of the Agile Manifesto, by the way. Seems simple, doesn't it? Yet there are flotillas of books and courses with detailed instructions and steps for "doing" Agile, as if it were a thing with specific rules and regulations. Hogwashery! Hear me now, the road to hell is paved with book covers and exam notes, it's time to rise up and put the 'man' (and woman) back in 'manifesto'. Spoiler alert: getting the 'fest' back in as well will be the topic of a future post...

Great teams do not "do" Agile, great teams "are" Agile. Being agile is not about burn-down charts, or attendant posture during some meetings, or not having other meetings, or some other "official rule" you must follow to pass a certification test. Being agile is a state of mind, a frame of reference from which to make decisions. If you are in the business of delivering software solutions and your strategy for success is adopting formulaic "Agile Processes", you are costing everyone a lot of extra money. Stop it. Stop it now, and let the healing begin.

Here's a quick test to see if you are a member of an agile team. Does the team trust each other and communicate frequently and honestly? Give yourself a point. You're moving faster towards clear, shared goals with less hesitation and fewer missteps. Individuals and interactions - sound familiar? The Speed of Trust can be measured, don't waste your client's money on avoidable drag.

Are team members (regardless of employer) passionately focused on overcoming hurdles blocking the path to shipping as a cohesive unit? Collaboration! That's the spirit! Is the team focused on building effective solutions that make people smile, or on how closely the product matches the original specification? Hint - you should be making people smile.

Teams are not formed to create documentation (not agile development teams anyway), they are formed to do magic, to enable people to do things not previously possible. Never forget that. Real agile teams do not start projects without first mapping a path, but they do not hesitate to adapt when market forces and other realities shift during flight. Respond to change, don't just follow a plan. Seeing a pattern here?

If your team is struggling to ship products on time, or continually ships products that fail to move the ball forward, or is constantly duplicating work due to miscommunication and misunderstandings, simply changing toolsets or making new rules is not going to save you. If every one of your team members cannot clearly state what success means for a project, why the project has been undertaken, and what risks and challenges stand between them and a solution, you're not going to cross the finish line (at least not when and where you want to). Forget the charts. Forget the rules. Talk, trust, learn, adapt. The tools are just that, tools. Use the ones that work for you. On this project. With this team. Success does not hinge on whether you use Jira, or Mingle, or Pivotal Tracker, Google Docs, or Excel, or sticky notes, or hand signals and a series of grunts.

Successful agile teams are characterized by quickness, lightness, and ease of movement. They are mentally quick and alert. They have a resourceful and adaptable character. They are well-coordinated in movement and have the ability to think and draw conclusions quickly. That's the entirety of the dictionary definition of “agile” by the way. Seems simple, doesn't it?

Sep 20 2010


Rotation and the Customer

Rotation and the Customer

As a consulting development organization, we are faced with the reoccurring challenge of "selling" to our customers the value of one of our core techniques: team rotation. We find it an invaluable part of our process and our culture, but one that some customers can't understand immediately why we practice it. This is an attempt to lay out the case for team rotation as not only valuable, but invaluable, to the customer during any development process.

How do we work at Relevance?

Relevance is an agile software development shop. That is not to say that we are a Scrum shop, or an XP shop, or any other flavor. It is that we believe strongly in some core principles, and strive every day to mold how we work to achieve maximal results. All of our processes are built around the following three ideas:

  1. The development team needs daily feedback from our partners to ensure that we are not going down the wrong path.
  2. The team as a whole needs to have a shared understanding of the risks to the project, their possible impacts and the costs of mitigating them.
  3. We need to ship. All the time. Shipping is an excellent way to measure progress.

From these three principles, everything else we do can be logically derived. We have daily standups, and late-day checkins. We love checklists. We TATFT. We use CI. We work in two-week iterations, and organize stories into releasable features. We have risk assessment meetings and team retrospectives on a regular basis. We pair on damn near everything, including management tasks and client communication. And we rotate our team members, constantly.

How does rotation help your customer?

Team rotation is one of those areas we get asked about most. “How does that help? Isn’t is just a cost to the customer? What’s the point?” These are valid questions; most software development teams are established for the life of a project, in order to create “ownership” of the problems and their solutions, and continuity from day to day. Traditionally, ownership and continuity are seen as the best way to achieve lasting velocity. Don’t believe that. Not for an instant. Only one role in your project team should be immune from rotation: the conductor (more traditionally, the project manager). There is enormous value to having continuity of the primary communication channel, such that your partners always know who to call, and who to expect on calls and at meetings. But for the implementation roles (developer, designer, etc.) rotation is a key component of creating value.


It isn’t that we don’t believe that “ownership” helps with quality and velocity. We strongly believe that. We just don’t believe that singular, isolated ownership is valuable. Or more specifically, the value doesn't justify the costs. Software developers who “own” a project are single points of failure. The coupled power and responsibility virtually guarantee a certain amount of information hoarding, making them indispensable to the project. When that occurs, velocity is negatively impacted because there is no way a single person can focus on a single problem every day for the life of a project. Because they own all the information, whenever they are unavailable, the project suffers. Sometimes greatly.

Consistently rotating team members is the only way to create shared ownership of a codebase, and more importantly, of the emotional attachment to its success. As you rotate team members through projects, you increase the shared commitment to shipping it that is so vital to good software development. What’s more useful for a customer: knowing that three of your guys are dedicated to their project forever? Or knowing that all of your guys are sharing an interest in getting it shipped?

By rotating team members through this way, you raise your bus number dramatically, buffering against things like (expected or surprise) time off, the ravages of new-school-year plagues, RubyConf, the next iPhone release, Halo Reach, and whatever other major distractions occur in the normal work week. Because so many people will have context on each of your projects, you can roll with the punches and still get people who know the code, know the customer, and know the “project culture” to carry the flag. That’s a huge risk mitigation, and customers benefit from it every day.

Finally, because of the spread ownership, when emergencies arise, there is a much higher chance that the customer will be able to reach somebody knowledgable right away. This benefit is hard to overstate. When today's project team is just three people, but the support list has twelve names on it, you know that you are going to be able to get answers quickly.


Continuity sounds great on paper; the devs build up a great deal of domain knowledge and momentum, and can tackle new challenges based on their amassed experience. In practice, there is an upper bound to this benefit; domain knowledge is definitely critical, but you can amass enough of it in a short amount of time that there is a diminishing return beyond that. And once the learning tapers off, the natural corollary tends to creep in: boredom. A bored developer is likely to pay less attention to critical details in coding and testing. It’s just natural. Rotating your people allows them to be consistently re-engaged in your partners’ problems and avoid the stagnation that a six-month project (or longer) typically engenders in its team members.

Second, continuity of development staff has an implicit assumption that all tasks in a project are created equal. That the developers assigned to the project can tackle all tasks, rise to all challenges, ship all features equally well. But if you have a strong, large and diverse team, you will necessarily have an uneven distribution of skills. Some people will be great jQuery people; others will have a security background; others will kick ass at asynchronous code. By limiting yourself to a dedicated team, however continuous it is, you will miss out on the power you gain by having a diverse team. Rotating developers allows you to take advantage of your organization's diverse skills; that gives you leverage. Without rotation, your team will operate at a least-common-denominator level of quality and velocity; every project will feature tasks that its continuously assigned team are terrible at, thus draining the project of momentum. A steady diet of rotation will usually alleviate a lot of that by allowing you to adjust to the needs of the current tasks.

Finally, by establishing rotation as a core value, you can eliminate the traditional friction between UI/UX issues and code development. UI/UX is often defined as “fuzzy”, hard to quantify or estimate, and difficult to integrate with coding teams. But by rotating designers in as half of a development pair, you can achieve two goals at once: using an existing, natural part of the process to layer in design tasks, and creating a shared culture of design and code excellence among all team members. We aren’t nearly as good at this last point as we would like, but we are trying, and noticing that exposing designers and coders to each other in direct pairing sessions has enormous payoff for the project.

#How does rotation help you, the development team?

There is a benefit to your team, as well. The obvious one is direct one-on-one skill sharing. If you couple mandatory rotation with pairing, you get a massive opportunity to have people learn from each other, on the clock, in real world situations, all the time. Your team can level up across your areas of expertise by being conscientious about how and who you rotate, and where. Understand the pairings, and ask for input, and you can create awesome learning experiences every day.

On top of that, by giving everybody on the team the expectation that they will rotate to a new project within a given window, you minimize the likelihood that they will mentally checkout of the project. I don’t know about you, but if I look at a problem space and know, without doubt, that I’ll be still working on it six months from now, some part of my brainstem tries to throttle that other part of my brain that wants to kick ass. And it is an effort to fight back. But if I know I have a limited window to kick ass within, then I’m all in and working. Rotation guarantees the opportunity for change.

#Mitigating the potential pain of rotation

The biggest potential drawback to rotating team members is that velocity can suffer. Regardless of how much shared context there is, every rotation carries the on-ramp burden with it as the developer re-integrates with the project culture, the current codebase and the current priorities of the customer. The key is to rotate thoughtfully and understand that these costs are universal. As long as they don’t surprise you, you can pay them and easily move past. A key method of preventing on-ramp friction is to only rotate half a pair at any time. The pair who stays on the project can carry some of the burden during the on-ramp period, thus dampening the friction effect. Also, communicate clearly and proactively when a rotation is going to occur so everyone knows to expect the resultant effects. As long as the entire team buys into the benefits of the practice, the costs will be easily bourn. But surprise costs are always a problem, so make sure to announce ahead of time when the rotations are occurring. With luck, the team will establish a high enough trust level that the announcements can disappear over time; this is when rotation has proven its value and your customer is no longer trying to weigh the costs vs. the benefits. Until then, be clear about your intentions and schedule.


Really, rotation of team members is enormously beneficial whether you are a consulting development team or an internal shop. The major question is: how do you take advantage of it within your established practices? If your team has wanted to employ rotation for a while, but can’t find “the right time”, just mandate one. Pick a date: on Oct. 1, half the team will rotate to new projects. Constraints spur creativity. Now is the perfect time.

Aug 19 2009


The Longevity of "Enterprise" Tools

During the recent erubycon conference, there was a lot of twitter traffic from attendees about how great the conference was. One who did not attend wondered if a conference discussing "Ruby in the enterprise" was wishful thinking or reality?.

Sorry if this disappoints anyone, but there was almost no wishful thinking, and a lot of reality. But there's a third option: planning next moves. There was a lot of discussion about how to promote Ruby effectively in enterprises that aren't already using it---not because Ruby is the be-all, end-all of programming (it's not) but because we have all found it helpful across a wide variety of programming tasks, and we think it is a good antidote for the more common, "enterprisey" tools that often bring more bad than good to a project.

During a panel discussion right after my keynote (Why "Enterprise Tools" are Bad for the Enterprise), someone asked "What do we say to a manager who doesn't trust open-source tools to still be around in a few years?"

Something snapped in me---I'd heard that same question one too many times. Commercial tools are available solely based on their customers. If the tool gets enough customers, the tool continues. Otherwise, it will all disappear. And it must disappear, given the nature of the software business.

There are three scenarios (with variations) for new software development tools, and all are common:

  • get enough customers to be profitable, and continue for many years.
  • get enough customers to look viable, get purchased and see the tool squashed or sidelined by the new owners.
  • get just a few customers, and have your board shut you down.

When you choose a commercial tool, you're making a bet that enough other people will purchase it to make it viable, and that it won't be purchased and shut down by a competitor.

When you choose open-source tools, there is no monetary pressure on the toolmaker to continue; only community pressure. It's much easier (and cheaper) to bring community pressure. Additionally, even if the toolmaker chooses not to continue, the community can keep the tool alive. Many open-source development tools that have long since dropped from most people's radar (think Tcl, for example) still have thriving communities that actively support the tools and help each other with difficulties. With a proprietary tool, the legal structures surrounding it virtually guarantee that the tool will die if the vendor loses interest.

In every respect, open source tools have a better chance of surviving than their commercial cousins. Sure, some of those commercial tools will be viable for a long time, but most won't. Whereas most open source tools will be around for a long time. Open source tools actually diminish risk, not enhance it.

Anyway, getting back to the panel question at erubycon: I decided it was time for action, because this is such an easy point to refute with just a little preparation.

So I volunteered to play scribe during the party that evening, and I spent much of the party sitting in a chair with a pad and pen, while attendees helped me remember "enterprise tools" that have come and gone. We built a list of commercial, "enterprise" software development tools of one sort or another that were commercially viable no longer ago than 1995 (when Java first hit the scene) but which are now "dead". ("Dead", for purposes of this list, means either that there is no longer commercial support for the tool, or that there has been no significant new development on the tool in the past five years.)

It's a long list.

The point of this is not to prove that open-source tools are better than proprietary tools (obviously I think they are in most cases, but this list won't prove it either way). The point is to show clearly that there is no guarantee that a tool will still be around and supported after a few years, proprietary or not.

I'm sure there are other tools that we didn't think of. I'm equally sure that some of the tools currently on the list are actually alive; the fact that attendees at erubycon haven't heard of a tool for a while doesn't mean it isn't still being maintained and supported somewhere. (Here's a good example. I thought of a tool that seemed like an open-and-shut case for this: NetDynamics, the original Java application server. A little research shows that it was purchased by Sun, and some of its code formed the basis for the iPlanet application server, which was later called Sun ONE, and then the Sun Java Enterprise System, and is now called GlassFish. Nevertheless, I strongly doubt that old apps written for NetDynamics would run on GlassFish, and I'd be interested to know whether there was ever a clear migration path for NetDynamics customers.)

So I'm starting the task of double-checking that list. If you're interested in helping, send me email! I'll blog about the results here.

Aug 08 2009


Why "Enterprise Tools" Are Bad for the Enterprise

In the Ruby community, we have a tendency to sneer at things that are too "enterprisey." That tendency has been explained in some uncharitable ways, but mostly by claiming that we "just don't understand the enterprise." But I think there's a different explanation. At Relevance, we've been doing some work with a large, enterprisey customer (Verizon Business). We've worked together to try to understand what enterprises can learn from smaller, more agile companies like Relevance. That work has led us to understand some of the real disadvantages of the kinds of big, pricey tools you usually find in large enterprises,and we've learned why lightweight tools like Ruby are good fits not just for small, agile teams, but for large enterprises as well.

Jul 22 2009


Teaching retrospectives by example: NFJS Salt Lake City

Want to learn about agile retrospectives? Participate in one! At the No Fluff, Just Stuff software symposiums, I am doing a talk on retros where we begin by doing a retrospective on the conference itself.

At the Salt Lake City show this weekend, we had eight participants for the retrospective. NFJS talks are ninety minutes long, so we took the first sixty minutes to run a retro on the conference. Given that we only had a day of experience to retrospect on, and that we were not a cohesive team but were "thrown together" by people selecting the talk, I wondered if we would have enough to talk about. This turned out to be a non-issue, as everyone threw themselves in with gusto. We could have easily gone longer, and as facilitator I had to enforce the timebox on each phase.

Setting the stage

As an icebreaker, we did a variant of the Checkin exercise from the Agile Retrospectives book, using the question "If this conference was a movie, what movie would it be?" Answers included:

  • Driving Miss Daisy
  • Casino Royale
  • El Diablo
  • Lord of the Rings
  • Serenity

We had a few laughs, and the exercise broke the ice. However, nobody referred back to the movies in later exercises, so we will all just have to wonder if NFJS folk are orcs, reavers, outlaws, chauffeurs, or Quantum.

Gathering data

Next, we performed the Team Radar activity. After a few minutes of brainstorming, the team came up with eight possible topics to rate and discuss: prescriptiveness, (topic) diversity, relevance, scheduling, comfort, inspiration, food, timeframe. In order to hit the timebox for the retro, we agreed to use dot voting to select only four of these topics for further discussion.

Each attendee then ranked the four topics on a scale from 1 to 10, resulting in these averages:

  • 6.9 (topic) diversity:
  • 7.9 relevance
  • 5.9 scheduling
  • 7.4 inspiration

There were no major outliers on any of the scores. Overall, these scores are pretty high for a group who is taking seriously the challenge of finding things to improve.

Generating insights

Given the small group size, we elected to have a free form discussion to generate insights. Some of the ideas included:

  • Happy to see non-Java languages such as Clojure, Groovy, and Scala.
  • Would like to see even more non-Java, but ...
  • ... very happy that the Java topics were directly applicable to attendees jobs.
  • The agile talks were developer-focused, would like see more holistic talks.
  • For inspiration, the cornerstone is the first day keynote. Keynote was good, but could have been more novel.
  • Half of the participants had been to multiple NFJS conferences. The feeling of "it blew my mind" was still there, but not as strongly as in the past. Suggestion was made that this was the attendees changing over time more than the conference.

SMART goals are hard ...

The initial discussion of possible SMART goals attacked the lowest-scored item from the Team Radar: scheduling. How can the topics in a multi-track event such as NFJS be better organized so that participants are excited about every talk they attend? After a few minutes talking about track definitions, topic tags, website improvements, etc., we agreed it was a hard problem that was not going to yield a SMART goal in the time we had.

...Until you focus on the people

And then, by focusing on people instead of technology, we came up with two ideas that could significantly mitigate the scheduling problem:

  • Make it socially acceptable to walk out of a talk. Half of the participants said that, given a specific invitation to do so, they would have ducked out of at least one talk after they had seen the first few minutes and understood the agenda. So, at the next show, we request that all speakers choose a point 5-10 minutes into the talk to, well, invite people to leave. Keep count of the number of people who take the offer to decide whether this should become a standard practice.
  • Provide easy-to-find video on the NFJS website so that attendees can get to know each speaker before the show.

I brought the second idea to the conference organizer, Jay Zimmerman, immediately after the talk. He laughed because he is already doing it, building a collection of five-minute videos introducing the NFJS tour speakers. If only all SMART goals went so smoothly!


We voted up/down/neutral on whether the retro was worth the time, with all participants voting "up." The discussions helped each of us clarify our own perspective on the conference. Also, we were happy to have found easy-to-implement recommendations to improve the conference experience. After the retro, we had twenty minutes to discuss how to run a similar retrospective for an agile team, and some of the attendees are planning to try it with their own teams. As facilitator, I was pleased with the retro, and I am looking forward to taking this idea to other cities over the remainder of the year.


  • The Agile Retrospectives book includes dozens of retro exercises, and guidelines for when different exercises are appropriate. It is one of the books we recommend to team members on our projects.
  • Check out the agile talks at an NFJS event near you.

Jul 07 2009


Relevance Agile Bibliography

You can't learn agile development by reading a book. But reading a few books, in parallel with training and trying out the techniques, helps a lot. These references constitute Relevance's recommended reading list for doing Agile development.

Our customers and students frequently ask us how they can learn more about how we work. We believe that Agile is not a process or method, but rather an attitude of constant reflection and improvement. Our favorite books and papers are about how to see, understand, and react to what's happening on our projects.

Three Essentials

Almost all technical books are about particulars: particular processes, platforms, techniques, or tools. These three books, though, are about the essence: the essence of programming, projects, and people. Other books may offer more immediate, concrete recommendations for your current situation. However, these books are the foundation. If you understand them, everything else will make more sense, and you will be able to make more effective use of more specific recommendations. We don't see these three books becoming dated anytime soon.

The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas. If there's only one book that every working programmer should read, this is it. "PragProg," as it's known, is about the essence of programming: what programmers really do, and how to get better at it.

Agile Software Development: The Cooperative Game (Second Edition) by Alistair Cockburn. This book is an awesome exploration of how to think about process and software, and how to adapt your process to the needs of your organization and project. This book attempts to get to the bottom of how software projects work and the factors that make them succeed or fail.

Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister. This book is aimed at software projects, but the focus is the human element: people and teams. Just as good and relevant today as when it was first published in 1987.

Software Development

The Mythical Man-Month: Essays on Software Engineering (Anniversary Edition), by Fred Brooks. This is the all-time classic about software project management. It predates Agile methods by a long time, but it's still packed with wisdom and insight, including compelling analyses of some of the problems with traditional development processes.

Patterns of Enterprise Application Architecture by Martin Fowler. Yes, it's a patterns book, but don't let that scare you away. It discusses the patterns in use by Rails, Django, JEE, and the tradeoffs and reasoning behind them. Whatever architectural style you usually prefer, this book provides a valuable dose of context by explaining the situations where that style may not be appropriate, and showing you a number of useful alternatives.

Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister. Methodology failure is just one of many kinds of risk your projects face. Unfortunately, most Agile books don't give risk management the attention it deserves. This book explains how and why to take risk seriously and manage it carefully. It's an excellent primer on risk analysis and how to plan for failure. (It also includes one of our favorite quotes: "Risk management is project management for grownups.")

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. We've known for years that a clean, expressive domain model that reflects the terminology of the problem domain makes every part of the development process easier. Eric Evans' book does a great job of explaining why that's true, and how to achieve a good domain model.

The Deadline: A Novel About Project Management by Tom DeMarco. Politics, intrigue, risk management, romance, kidnapping, schedule chicken, and spies. What more do you need to know?

I.M. Wright's Hard Code by Eric Brechner. This book deals specifically with the agile project manager role. Most importantly, it describes how to be a better manager in the "servant/master" model; rather than dictating to the team what to do, the manager sets direction and removes obstacles. That style works well in general, and especially well on an agile project. (Also, it has valuable tips on how to interact with other teams that are working on your project.)

Agile Methods

Extreme Programming Explained: Embrace Change (Second Edition) by Kent Beck. A concise and clear explanation of traditional software methodologies and why they are broken, and why XP works and is better. The first edition is rather detailed and prescriptive, focused on developers. The second edition has a higher-level viewpoint and is a bit more relaxed.

The Buzz About Bees: Biology of a Superorganism by Jürgen Tautz. Some people are unsure about agile methods because they don't feel comfortable with the idea of emergent behavior (i.e., simple, localized rules that result in complex, apparently organized large-scale effects). This book is an excellent explanation of that idea, with many insights that apply to human organizations.

A Simple Model of Agile Software Processes --or-- Extreme Programming Annealed by Glenn Vanderburg. This paper explains how a collection of focused practices, with very little overall coordination or up-front planning, can reliably lead to good results. Although the paper deals explicitly with Extreme Programming, the core idea---that agile processes consist of nested, optimized feedback loops at various scales---applies to other agile processes as well.

Agile Estimating and Planning by Mike Cohn. Agile teams still estimate costs, make plans, and set schedules. But we do it a bit differently. This book by Mike Cohn explains how an agile team sets plans, and how to change your thinking about plans and the ways that they help you.

Reflection and Responsiveness

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. Kevlin Henney likes to say that some programmers with ten years of experience seem to have had the same year ten times. Some teams are like that, too. Experience isn't very valuable if you don't learn from it, and we've found that you can't just take that for granted. Retrospectives are wonderful for making sure you learn the right lessons from both your mistakes and your successes. This book can show you how.

Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weinberg. Even if you're not a consultant, this book is well worth reading. It's all about how to see problems, identify solutions, and communicate successfully within an organization. It's about effecting change from a position of very little power. Who hasn't needed to do that?

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam. This book is about thinking visually about processes and problems. It's also a great way to learn about low-cost, high impact techniques like paper-prototyping and ad hoc data visualization.

Personal Development

The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler. There's debate about whether agile development requires exceptional developers. But it's absolutely clear that having good developers helps a lot. Chad has written a wonderful book that can inspire you and others on your team to improve your craft and polish your skills. The entire team will benefit.

What Did You Say?: The Art of Giving and Receiving Feedback by Charles N. Seashore, Edith Whitfield Seashore, and Gerald M. Weinberg. Agile processes are all about efficient feedback, and feedback between and about people is an important part of that. But giving personal feedback is hard, and receiving it is even harder. This book can help you get better at giving feedback constructively and reacting to it positively. Unfortunately it's out of print, but of course used copies are available on Amazon or Alibris.

Beyond This List

The resources listed here are great places to start. We also offer training on agile practices. But there's a lot of other relevant literature. In fact, as a couple of the examples here demonstrate, there's a lot we can learn about software development by reading about other fields, and even about other species. (Our friends the Pragmatic Programmers once gained valuable insights about software development by reading about training in the nursing profession and U.S. Marine Corps warfare doctrine. And we've been learning a lot lately by reading about music theory, cognition, the practice of medicine, and the history of bridge engineering.)

Furthermore, things are still changing. This bibliography will probably look very different in five years or so. (In fact, you can probably think of good resources we've missed. Tell us in the comments!) We learn new things about programming, and about software teams, every year. Sometimes it may seem like we have it all figured out, but more often we suspect that our whole industry is still fumbling in the dark, only gradually coming to understand the fundamentals of software development.

We intend to keep reading and discovering, and you should too. It takes a long time to get really good at software development, and there's always room to improve. Read at least a few books on software development each year. Also, seek out some good blogs or online magazines that discuss these topics. There is a rich and fascinating dialogue happening all the time in the community of software developers. You owe it to yourself---and your team, and your employer---to be a part of it!

Mar 25 2009


Agile Retrospectives

Agile teams manage change and risk by adapting. But to adapt, you must identify opportunities for change and take them. Retrospectives are a fun, cost-effective way for your team to learn and change.

In this talk, we will begin by conducting a mini-retrospective, so that you get a feel for the basic process. Next, we will review the core principles of a retrospective, and use these principles to compare and contrast a variety of retrospective activities from the book Agile Retrospectives.

Next, we will explore a few retrospective activities in greater detail. These are some of the favorites that we use regularly at Relevance:

  • team radar
  • prioritize with dots
  • learning matrix

Finally, we will talk about how to tune retrospectives to the needs of your team at a specific moment in time. No two retrospectives are alike, and an experienced facilitator adds value by adapting a retrospective to meet the current need.

Popular Tags