You CAN Develop with Loosely Defined Requirements

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

We just opened up a beta site at www.plantcollections.org.

I’m the Business Analyst on the project. Wonderful idea, connect all the Plant Kingdom databases into a single repository and let anyone who wants it, access the data.

The initial requirements were, essentially, let me export the data I want based on any field in any view and allow me to download it in an Excel spreadsheet where I’ll manipulate it to get what I really want. And I need this yesterday. Originally they had identified eight classes of users – from Botanical Garden Curators down to grade school kids. After a little work, we were able to change that to four types- A Domain Expert (Curator, Scientist, Taxonomist), Horticulturalist (College Profs and Students, upper level horticulturalists, conservationists and the like), Gardeners (K-12 Teachers/Students, gardeners, botanic garden visitors- the public) and Administrators (site administrators). The key is that the data remains the same- but the display and especially the searching tools will change because domain knowledge (like scientific names) is intrinsically involved.

Orthogonal was chosen to move it from proof of concept to production.

And the client really needed the site up within three weeks for demonstration to a professional organization.

Now under normal circumstances that would not be possible. The first thing I thought was if the team is not dazzling smart and very fast on every front, this isn’t going to work. Turns out, it was.

• The client project manager is superb, extraordinarily flexible and a SME himself and one of the easiest with which I’ve worked. His team is very understanding of the challenges since it’s been involved in the project for at least a couple of years- and they all provide great insight and comment.
• Our Lead Architect, Noel Rappin, built a rock solid foundation upon which we’ll be able to build a might structure. Noel wrote the book on Ruby so he was working to mitigate the technical risks in between all the other stuff he did.
• John McCaffrey is a developer-turned Project Manager who’s practical and able to abstract in his sleep.
• Our Information Architect, Brian Dillard, turned from his day job as Orthogonal’s Technical Evangelist into a super hero developer-making the task and work flows as smooth as possible noting areas of
  future improvements and gaps.
• Developer Sharad Jain worked miracles in setting up the interfaces, queries and query returns between the application and Google Base as well as setting up builds on the run in virtual machines of which we never heard.
• Justin Ficke, with whom I worked on a previous project and knew him to be a data wizard, set up the XML machinations for the first Query Object at Google Base.

What happened was three weeks of iteration work, sprints and huddles. The developers were pairing with other Pathfinder developers constantly to pick up expertise quickly. The DevTeam took the minimal requirements, reactions and comments the client management team provided, I turned into technical requirements on the fly and between my guesses and these talented developers’ code, we essentially prototyped our way into the first release.

My job was to act as the question conduit, sketch out base-line wireframes/requirements and act as the Sanity Checker for functionality.

In the next sprint, we’re going to continue educating the Business Team in the Agile Method and move to, um, less chaotic development techniques. We knew how important it was to meet their deadline and practicing Agile made it happen. Now we will have more sane sprints and since the site is live even more feedback from real users to help us drive requirements and enhancements.

The first sprint taught us a lot:

• Being practical and flexible can work, but everyone has to communicate, communicate well and often.
• Pairing really, really works.
• Agile Method techniques are very important, but if you’re careful, you can stretch them a lot- if you have an extremely high-level team.
• Scot needs to draw better wireframes. VISIO works, but it doesn’t look as cool as Brian’s work.