Recently at my organization there was a need for a new piece of software and a very short timeline to develop it. The Executives came to me about making sure the project was completed on time. I had 2 requirements before I would accept the project: 1. I would not use our Software Development Life Cycle process (SDLC); 2. I would manage the project with a co-manager who heads up our network systems group.
So why would we ditch our predefined SDLC process?
Our SDLC process has many excellent documents and procedures on the process, but the issue with using it for this project was a short timeline and we wanted to review the software as it was being built (which helped us determine those requirements that we were not sure of at the start). So I wanted to move forward with an Agile method.
Why have a co-manager?
I wanted this so we could develop our own documentation templates that we could use for future projects and hopefully after several projects we can prove to the executives that an Agile method is an acceptable method for us (we would need to calm their fears about FDA reviews).
Let’s get it started!
We started by first selecting a team of expert content users (the stakeholders). Many times I’ve seen software development projects where the executives sit in each meeting. Why? I understand why they are there for the kick-off, but if they are not going to use software (so they are not expert content users, but they are a stakeholder) we spend a lot of our time in meetings explaining how things work to them. Having the right team is critical for this process to work (Jesse Fewell recently wrote an article about this: Tail of two teams).
Next we had our kick-off meeting where we told stories about what we wanted the software to do. From these stories we pulled out the requirements and came up with 3 stages (or sprints) for the project. The requirements were documented within their stages and we also included acceptance testing within it. We did not put this into a burn down chart (improvements for next time) and I recently read an article about making screen shots to add to your stories (link)
You want to meet again?!?
The key to making this work is frequent face-2-face meetings for the team to report what they have done and what they are doing next (helps to keep people on track) and this is an opportunity for show and tell of the software. Agile methodology recommends daily meetings, but we stuck with meeting 2-3 times a week. During these show and tell times some new requirements came out and we determined if they were within scope of the project and, if so, what phase to put them in and determined if there was any effect on the timeline (changes are welcome). Now, this is in contrast to the SDLC or waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.
Our lessons learned from this process was that it was key to only have the expert users at our meetings and having more than 1 meeting a week really kept the project moving along.
Checkout the application in use!
In most organizations, a stakeholder's attention span is pretty short. Long projects that require a lot of stakeholder patience tend to falter and ultimately fail. Providing value regularly, at short (3-4 week) intervals, keeps stakeholders engaged and interested. -@task blog
Going forward …
Determine other organizations using Agile methods who are submitting to the FDA: