Timeboxing Risks

Before I got delayed we were talking about delivering software projects on time. Using the Timeboxing approach, the delivery schedule is the one absolute in the implementation plan. What features will be included in the delivery can slip, but never the date. New requests from the user are added to the queue, but the date is not modified to accomodate them. Unexpected technical problems may delay a feature, but never an install. With this approach, progress may be slower than anticipated, but it never halts, as it can with traditional scheduling, where an installation might be put on hold until all the planned features are completed. We've outlined the benefits to this approach, but there are also some risks. The most critical risk is safety. If Timeboxing is taken to mean that we just work away at the application until the scheduled delivery date, and then install whatever we have, users can get some nasty shocks. A major new feature might be only partially implemented. Spurious messages meant only for the programmers might appear. Untested calculation might charge people incorrect fees. The solution is release planning. Timeboxing is not a come as you are party. Sometime before the due date, the team needs to decide what requests can actually be included. Testing on those items must be completed. Features that are not ready for prime time need to be hidden. Changes that should not be delivered need to be rolled back out. This is where a good version control system comes in. Even the sacred install date can be slid by a day or so - not more -- to assure that the work already done is ready to debut. What this really means is that internally the timebox needs to end a day or two early, so the app can be cleaned up for its public appearance.

Hot-button telepathy

Agile methodology Guru Alistair Cockburn wrote that software development is "a cooperative game of communication and invention." But as George Bernard Shaw told us: "The single biggest problem in communication is the illusion that it has taken place." And so we arrive at the challenge when software guys sit down with organizations to make the system do what their users need. Recently we'd been having a number of conversations with a prospective client. Everything seemed to be going well, and I was pretty sure we were going to get the gig. When we didn't, we of course asked our prospect what particular issues had led them to buy elsewhere. "Well, we loved your software, but there were a few aspects of your approach that really turned us off. One was that you mentioned several times you deliver all the source code with the application. But none of us are programmers; we wouldn't know what to do with it. So we decided we wanted a vendor that did not make us take the source code." Like so many times in business and life, our first thought was "Boy, these guys don't understand anything! Sheesh!" But then if you want to communicate, you've got to take responsibility for being understood. What mistake had we made that allowed this misunderstanding? Our mistake was to assume what I call "hot-button telepathy" In our business, openness of applications is a hot-button issue. "Can I have the source? Can I get at the data? Can I host it on my own server" are big questions in our world. So it never dawned on us for a minute that someone might not "just know" that having the source code is a good thing. Hot-button telepathy is an error users can make too. Your technology vendors do not know the hot-button issues in your non-profit work. You may think every day about the issues involved in fighting malaria in West Africa, or educating girls in Central Asia. But your technology vendors are not. And this can lead to all sorts of miscommunication. I was at a meeting once where one of the YMCA's we work with was interviewing a prospective networking firm to install a Citrix farm for them. The sales rep, in summing up his presentation, said, "You guys know how to run a health club - you shouldn't also need to learn how to run a wide-area network". Well, saying this almost cost them the gig. Doesn't everybody know that private health clubs are fighting in the courts to have the Y's 501c3 status revoked on the grounds that they are just another health club, and to refer to Ys as health clubs is therefore to deny all the other valuable work the YMCA does in the community? What an insult! Of course this networking professional was not familiar with this issue, and meant nothing of the sort. After a brief cool-down period the conversation resumed and they won the project. But it just goes to show how right ol' G.B. Shaw was. Image of George Bernard Shaw from Wikipedia Commons. Description and Attribution.

Thinking about Software Requirements

Is your organization getting ready to think about its software requirements? Sometimes when organizations approach us about their software needs, we are struck by how poorly they have thought out what it is they are looking for. We cannot even guess from their few pages of notes what major pieces of functionality they are seeking, or why they are seeking a new system. Other times we find ourselves staring in dismay at a 100 page Software Requirements Statement detailing field lengths and report structures, to which we are expected to respond in detail. These guys have gone to a lot of effort. But both of these documents are nearly useless in the context where they are usually handed to us - where an organization's staff and ours are trying to decide if we are a good match for their critical software needs. It's not a problem of having to much or not enough of a requirements statement. The problem is misunderstanding what requirements are, and what they are for. Following a link in a sidebar of an article in the current issue of Dr Dobbs Magazine, a venerable developers journal, I found a great piece by Karl Wiegers - 10 Requirements Traps to Avoid -that should be a great help to anyone trying to write a requirements statement. Trap 1 is as far as we are going today. It involves failure to recognize the type of requirements you are setting down. Wiegers identifies three distinct levels of requirements. Business Requirements lay out the needs from the standpoint of organizational problems and goals. From this standpoint there is one actor - the org - with one set of needs. User Requirements look at the information system from points of view of the different staff roles within the organization, and specify what tasks each actor demands of the the software in order to meet the Business Requirements. Finally there are Functional Requirements - detailed descriptions of individual functions the software is going to perform in meeting each user requirement. For software selection, keep your focus on your organization, not on the application's buttons, checkboxes, and fields. If the task at hand is to distinguish between vendors, the statement of functional requirements is the wrong tool. Instead your starting point ought to be how the vendor and its software will help you address your key business requirements. Ask the vendor how their tools and their approach will help you meet your organization's articulated information systems business requirements, rather than have them check-off whether or not they have certain sorting abilities in a certain report you may not really need. A focus on the micro level can give you the feeling you are doing your due dilligence, but really you are taking your eyes off the prize, which is selecting the software that best supports your mission.

Now let me tell you what I want this thing to do....

A friend of mine likes to tell this story from his early days as a software consultant. His team had spec'd out a system for a client, and implemented it in somewhat more than three the time they'd included in the contract. Even though they'd lost their shirts, they were full of excitement as they delivered their shiny new application to the client. After the walkthru, the big guy tipped back in his seat, smiled, and said: "This is great. Now let me tell you what I want this thing to DO." The other night over Indian food I heard the same story from the other side of the desk. A friend who works with a non-profit here in DC was talking about the nightmare installation her group had been suffering through for a year now. They are still waiting for the developer to understand the sort of features they need to really support their workflow. He does deliver a new version every few weeks, but each change seems to break something else. "But I'll bet they're really sorry they agreed to do this for a fixed price" she concluded. I'm sure they are. But so is she. When Members Only Software was just starting out, we frequently sold our product in a fixed price engagement - basically saying "We will do what it takes to customize our application for your organization. We will do this for an amount of money we will agree on now, even though we have only a vague idea of what it is you will need." This approach created good clients, who had few special needs; and problem clients, who had many needs. Later we learned to charge for all of our time. We used to think this would make it difficult to give the client a clear project budget. But that's not true. It's easy to stick to a maximum figure - its just that in this reality the user may not be able to afford everything they would like. This reality encourages everyone to prioritize, and by setting a fixed number of hours to the engagement, makes it much more likely a defined project actually reaches completion. Amazingly, it also made all clients good clients. The ones with lots of special needs were suddenly sources of revenue, not drains on our time. This in turn was a benefit for our clients with smaller budgets, who could not afford customization but were excited to see the new features that would show up in our service packs as the fruit of someone else's custom need.

Agile Software Development for Non-Profits

"When the road bends, you cannot walk straight." It's an old gypsy proverb. I ran into it as the epigraph to Gypsy Caravan, a great film by director Jasmine Dellal, documenting the six week U.S. tour of gypsy musicians from all over the world. But it's also the secret of effective technology project management. When I first started out building software, one of the books I read was Tony DeMarco's Controlling Software Projects. It helped me understand the real forces that lead developers and other stakeholders to underestimate timelines and generally plan poorly. But somehow, (maybe it was the title) it left me with the feeling that when I got really good at this I'd be able to map out the path of a project in advance and steer it right in, exactly as imagined. All we needed to do was perfect our techniques at requirements analysis, estimation, coding, testing, deployment, training, documentation, and coffee-brewing. But it seemed that no matter how hard we tried on each project, the road always took an unexpected turn somewhere. At testing time the clients suddenly thought of an unanticipated set of requirements. At training time, a horrible bug surfaced. On the day the client was going to deploy, their network was brought to its knees by a virus. No matter how hard we tried to control the process, something went wrong that forced us to regroup. Gradually we were forced to surrender to the reality that significant software projects were always going to take us by surprise now and then. Others have discovered this too, and it's led to the approach referred to as Agile Software Development. Agile development recognizes that the road is going to bend - indeed it is rarely going to be straight. So agile methods stress responding rather than controlling. For example: We used to try desperately to assure that during training no bugs would be found and no specification changes would be offered. It was futile. Training rooms, with ten novice users banging at the keyboards are in fact perfect software testing labs that will inevitably find some lurking defects. And a roomful of your staff getting their hands on the new software for the first time are bound to come up with some new ideas. The fact is there will almost certainly be change requests and problem reports during my training sessions. So let's learn to manage them wisely. Today, at the beginning of a training session, we put up two flipcharts -- one to record any reported problems, and one to park any requested change or enhancement. These items can be acted upon later, but by capturing them here, we have turned what used to be a disruption in the training into added value that moves the project on, around the bend. In a way, all the repeatable improvements we've made in our methodology are no more than this -- to anticipate the unavoidable bends in the road, so we can take them at speed without leaving the roadway. Image originally posted as http://www.flickr.com/photos/improveit/525851663/in/set-72157600298986170/