When talking about almost any kind of work, most customers want to know two things: “How soon can it happen?” and “How much will it cost?” There’s an implicit assumption of predictability. When people ask me how to choose a software development partner, I always recommend (if at all possible) finding someone who’s developed something very similar several times before. I know, easier said than done—and probably more expensive (since they know how much it actually costs). But also (I hope) more predictable.
In software development, there’s a movement known as “Agile Software Development” that attempts to address the issue of predictability. It’s been around since at least 2001, when a group of like-minded developers published “The Agile Manifesto,” which is short enough to reproduce here in its entirety:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, [and] responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.
To quote Martin Fowler, one of the people behind the Manifesto: “…[but] if you believe you can be predictable when you can’t, it leads to situations where people build a plan early on, then don’t properly handle the situation when the plan falls apart. You see the plan and reality slowly drifting apart. For a long time you can pretend that the plan is still valid. But at some point the drift becomes too much and the plan falls apart. Usually the fall is painful.” Sound familiar?
If something is predictable, then you can turn it into a process where time and cost are known quantities (think McDonald’s and fries). But if you’re trying to innovate, you don’t know what the outcome will be. By its very nature, innovation is unpredictable. Agile processes deal with a lack of predictability by defining “user stories” that deliver value to the business. Work that doesn’t create value for the business doesn’t get done (at least in theory). A user story must be small enough in scope to be completed in a short timeframe, called a “sprint,” which may last anywhere from a week to a month. At the end of a sprint, the team demonstrates the result.
By prioritizing these user stories, people are always working on the tasks (the things you need to do to satisfy a user story) that deliver the most value to the business. With a team of skilled, cross-functional workers, an agile approach can be quite effective, with each team member taking on the next unassigned task.
User stories take the general form of: “As a (role), I want (something) so that (benefit).” For example, “As a customer, I’d like to place my lunch order in advance so it’s waiting when I arrive.”
Although Agile is aimed at software development, having your own prioritized list of “things that would make our business better” (user stories) is a useful tool for any business. Prioritization can be as simple as numbering items from one to 10. Take the top item from the list and give it to someone to break down into tasks, and make that task list available to your team. Let people pick off tasks (and support them when you can see they may be stretching their abilities). It’s a great way to help people grow while making sure they’re working on something with a clear value to you or your customers.
Commons
One of the best things I encountered during my recent three-month stint with a Marin-based engineering group was the internal website known as “Commons,” a private-labeled version of a “social intranet” from Jive Software. Despite the fancy name, it’s really just a nicely packaged implementation of a wiki (a user-editable website). What it provides is a way to capture the useful/important knowledge that’s floating around in people’s heads. For example, if someone figures out a workaround for a problem with a tool, they document it on Commons. Other people can edit (or just comment) as information changes or problems are solved. People can ask questions (“How do I use X windows to talk to my Linux VM from my Windows desktop?”) and get an answer or sometimes several different approaches. Commons is also used to keep a “face book” of employees, so you can match faces you see around the office with names, and put faces to the names of remote workers.
There are, however, two potential problems with a wiki. The first is duplication of information, which can be addressed by encouraging people to search before creating a new document. The second is making sure obsolete information is archived and removed.
Microsoft’s answer to group collaboration is its SharePoint Server, which started life in 2001 as a document repository for Microsoft Office documents and has grown into something much larger. I’m not a big fan of it—if you must use it, there are hosted offerings from a number of companies, letting you avoid the hassle of installing and maintaining it yourself. I find it amusing that Jive offers a front-end for SharePoint—what kind of awful collaboration tool requires an easy-to-use front-end?
AlterG
On a personal note, as of March 1, I’m the new chief software architect for AlterG, makers of the “anti-gravity treadmill.” These treadmills, which let you walk or run while “unweighting” your legs by supporting your body with an inflatable bag, are a new form of rehabilitation treatment that can really change people’s lives. They’re also used by elite athletes for high-intensity workouts without damaging their knees or other body parts. Even so, I’ll still show up in NorthBay biz each month, so drop me a line at mduffy@northbaybiz.com with your questions and comments.
