Beyond The Yellow Bubble

The traditional way to approach formal application development is to create a project, draw up a list of requirements to be included, estimate the effort, commit resources, prepare a project plan, get approval, and then try as hard as possible to deliver the requested changes within the agreed time frame.  This approach I call "fixed content" development and forms the basis of most waterfall SDLC's.
The approach works well in many situations but does have its problems:-

1. Scope Creep: Whenever someone decides to change the requirements this usually has an impact on the project causing delays in delivery and cost overruns.  Participants in the project often have conflicting priorities when trying to resolve these changes.
   
2. Delays: If the project stops going to plan for any reason (including scope creep) there can be a ripple effect across this project and onto other projects that are interrelated because the applications interact in some way or because resources are shared across multiple projects.  This often results in changes being required to project plans for one or more projects and can lead to issues with resource availability.  The most like change is to make the project late which then can lead to other projects being delayed.

In  many organizations Lotus Notes tends to be implemented as a solution for small-medium sized applications.  Notes application development is often way faster than other development platforms.  As a result, the typical Notes developer is often working on a much larger number of projects in a given timeframe than say a Java or C# developer.  Notes developers are therefore more likely to have to deal with the issues that arise whenever one or more of they projects fall behind schedule.  Many SDLCs simply do not apply well to Notes development.

In order to address these issues I have been slowly trying to adapt my approach to demand/project management by focusing more on what I call "fixed time" development.  This is an adaptation of some of the newer agile methodologies, in particular SCRUM.  The following is a brief outline of how this works:-

1. Projects are now broken down into fixed time cycles/units (aka Sprint).  In my case I find a week is a workable unit for the Notes applications I develop/support.  In a given week I can typically spend 60-80% of my time on "new development".  The remainder goes in to administrative tasks, addressing QA defects, and performing releases etc.  So a weekly cycle roughly equates to 25-30 hours per week.  (It is charged as 40 hours to cover those other costs).
   
2. When a project is assigned we allocate a fixed number of cycles and we provide an assessment of how many requests can be completed in that cycle.  Note: For any one application there is often more requested features than can be delivered so these are added to a backlog queue.
3. Now when development starts we either add or subtract requests based upon the developers burn rate during the course of the week.  No matter what development for that cycle is completed at the end of the cycle (week).
4. If we are falling behind schedule we also have the option of adding additional resources and/or increase the hours worked for that cycle.  This is not required but an option that can suit some circumstances.
   
5. If a project consumes more than one cycle then QA can start with the output from the first cycle so that QA issues can be addressed as part of the next cycle.  If is suits the project then the output from each cycle can be released into production so that users of the application can take advantage of the added features without having to wait for them all to be completed.  Note: This is not a requirement, but an option where it makes sense.
6. For really really small projects, two (or more) could be scheduled in a single cycle.
   

The advantages of the above approach include:-

1. Because we always hit our delivery time the organization does not consume significant amounts of time changing project plans and working out how to juggle projects/resources that are downstream from this project.
2. Projects almost always come in on time and on budget!  Sometime we may not have all the features we had originally hoped, but sometime we have more.
3. If a customer/analyst chooses to make late changes to requirements they do so knowing that it will probably come at the cost of something else getting bumped.  Its surprising how this seems to moderate the number of changes requested and sets more balanced expectations!
   
4. Life is so much easier to plan in advance when every project is running in fixed units.  e.g. Meetings etc can be booked well in advance because we have a greater degree of certainty of exactly when things will happen.  A meeting room can be reserved for the same day of every week.
5. My future availability is so much easier to represent as I have weekly cycles into which sprints are allocated.  Rescheduling involves juggling my weeks, not reworking milestones for each and every project I am involved.
   
6. Applications are typically enhanced by smaller more frequent releases.  Users are more likely to be more flexible with what they require because they know if it is not done now it will be in the next release in the not too distant future.  Feedback from smaller releases can be applied before we develop the functionality of the next release.  With organizations constantly in change we are less likely to deliver features that are no longer relevant.

The above is not suited to all projects or even all developers.  For this Notes developer it does seem to work, making me more productive and reducing stress from trying to constantly juggle the many conflicting demands from various stakeholders in the large number of projects I am assigned.

Note: I presently have a new OpenNTF project called .SCRUM that aims to provide a Notes application capable of assisting in the management of projects using a modified form of SCRUM such as the one above.  It will be a Notes 8.5.1 application and based upon the .Domino Framework 2.0 project I am kicking off July 1.  For now I am working on refining the business process before I write too much of the code.  Anyone who wishes to share there own experiences please do as I am sure there are a great many tricks/techniques that can be accommodated within .SCRUM as it is built.

Some time ago I had the opportunity to work with agile programming techniques as part of an ASP.Net development team.  The methodology we ended up using was an adaptation of the SCRUM methodology.  I wanted something more sophisticated than Excel spreadsheets to manage the projects I was working on, and ,as is often the case in many large organizations, it became a political minefield trying to convince someone to invest in a third-party tool to assist with the management of the SCRUM process.  Being an ex-Notes developer I was able to quickly develop a basic tools for managing the SCRUM process.
Now that I am back doing full-time Notes development I am again in a position where I wish to exploit the power of the SCRUM methodology to manage the many Notes projects I am now working on.  To do this I am taking this same SCRUM application I developed for C# development and expanding/adapting it to meet my current environment.  In the process I plan to implement the application using the .Domino Framework I have been developing (available as an OpenNTF project).
The new application will also be an OpenNTF project so that others in the Notes world with an interest in SCRUM may be able to take advantage of the work done.  If there are any Notes developers out there with an interest in SCRUM and would like to contribute to the project please feel free to contact me (peter@presnell.com).  The same applies with the .Domino Framework itself.....
All going well I hope to have an initial beta release available on OpenNTF within the next 1-2 months.