Agile Life Cycle Support in SEER

Published on Author Dan Galorath

While Agile is a methodology, not a specific life cycle, it does suggests certain kinds. Let’s start with a notion of what Agile at its core represents. From the Wikipedia article:

Some of the principles behind the Agile Manifesto are:

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (Co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

Some of the points above translate into a choice of life cycle. Often mentioned ones are Scrum, an “agile” SDLC (system development life cycle), Crystal, the Dynamic Systems Development Method. A key point here is that Agile projects employs a diverse set of methods and approaches; all you need is a process that is able to “sponsor” these.

We have found that a key aspect of a reasonable life cycle for Agile is one which has some upfront requirements definition, and then lots of iteration that includes all activities (detailed design, code, test, integration), followed by a packaging phase. This is not unlike the traditional Unified Process – the MS Project Integration for SEER features RUP Lite, which is even more agile!

If you are thinking “wow, that’s it?” then have a look at the “Nokia test” for proof our thoughts are not outliers.  The following is taken from:  Hopefully it represents the way Nokia really does things and is not out of context, but it is worth giving because it is consistent with what we are saying:

First, are you doing Iterative Development?

  • Iterations must be timeboxed to less than 4 weeks
  • Software features must be tested and working at the end of each iteration
  • The Iteration must start before specification is complete

The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

  • You know who the product owner is
  • There is a product backlog prioritized by business value
  • The product backlog has estimates created by the team
  • The team generates burndown charts and knows their velocity
  • There are no project managers (or anyone else) disrupting the work of the team

As far as project plans provided by Galorath are concerned, our job still is to give you a reasonable estimate for all the functionality you’ve told us will be a part of your software project.  If you desire a plan, then we can deliver one to you, one that supports Agile methodologies such as pair programming (XP) and timeboxed “sprints”, but it’s still the development team’s job to actually implement the methodologies, essentially below the radar of what a project plan can usually provide.

In the upcoming release of the MS Project Integration for SEER for Software we are delivering two Agile life cycles, Agile SDLC and the Scrum Framework.  The Agile SDLC template is more appropriate for sprints, while the latter is named “Framework” because it is intended to imply that multiple sprints will occur within the activities that it lays actually out.

SEER MSP Integration's Scrum Lifecycle In MS Project

The Scrum Framework is intended to capture activities in total, at the level of an iteration or release.  It is assumed that much shorter time boxing will occur within each iteration.  The activities shown will therefore will not occur strictly in series as shown.  Instead, they will be broken up into pieces that are iterated with each sprint.  You may take the activities as shown and break them up further, on a per sprint basis, or use the estimated effort and duration for each activity to plan required effort and get a sense for the proportion of time spent in each activity, while sprints are underway.

One more thing to note is that there is no widespread agreement on what names should be used for specific activities.  The activity designations selected by Galorath were decided after reviewing numerous sources; in the end we tried to choose names that were simply as clear as possible.

There are Galorath consultants with experience in Agile environments, our development projects have varying degrees of agility, and we have kept our ears to the ground for ongoing developments.  We also recognize that you, the customer, may have your own experiences to relay, so give us a call.  On the Galorath staff, Lee and Dave are probably the best people to talk with.