Agile, Scrum, Waterfall, and CMMI Development

We are currently in the middle stages of the SDLC at work for a new application.  Our company operates under a number of different methodologies that have been merged together into a hybrid environment, (which is pretty common from what I hear).  There is no one perfect methodology – you have to take what you like from them and make it unique to how you want to operate.  The best way to describe our environment is Agile/Waterfall/Scrum/CMMI.  There is some disagreement on this subject.  Some may say that these are conflicting or opposed methodologies, while others find many simularities.

The largest influence over us is CMMI (Capability Maturity Model Integration), which is an approach for effective process improvement.  In order to be CMMI certified (we are currently level 3 and pursuing level 5), we have to adhere to and be audited on certain procedures and processes.  It requires that we complete things like project plans and risk analysis for each of our projects.  We also have to meet to approve each other’s projects, etc.

Although there are obvious difference between CMMI and Agile methods, they have a lot in common.  Agile requires us to complete activities such as requirements, specification, architecture, design, implementation, testing, deployment, and maintenance.  The CMMI tasks coordinate with and are incorporated with the Agile tasks.  Waterfall allows us to complete these tasks in a sequential process, with one step flowing down to the next.  We generally do not start on the next task until the first one has been completed.  (There is some overlap, but nothing goes out of order.)  For instance, we do not design while we are writing requirements.

Most recently, we have incorporated some of the Scrum (not to be confused with my hilariously embarrassing twitter typo “scum”) methodology into our process.  We started having daily, 15 minute long, Scrum meetings (or “Scrums”), with 1 person in charge, called the Scrum Master.  So far, we have noticed that these meetings are extremely productive and helpful to the team.  We created a wiki page on our Sharepoint site for the team to post their questions prior to the meetings and we have been going through everyone’s questions and answering them right there, on the spot, so that the developers can immediately incorporate the changes into their development (and me into my documentation).

As the lone writer at this company, I am an integral member of this team and I often have just as many questions as the application developers do.  I am writing the user manual as they are developing and even though we have written all of the requirements and use cases, I am still discovering things that need to be addressed while writing step-by-step instructions.  I find things like, modals that have not been mocked up, or incomplete processes in key functionality, etc.  I can’t imagine the tech writernotbeing a part of these meetings.

I like how we have the freedom to pick and choose the processes that we like from each of these different methodologies and create our own hybrid process.  I think we have taken the best elements from each and found what works for us.  We are a small company, and an even smaller software development team, so efficiency is crucial since some of us are wearing multiple hats.

Which methodology has your company adopted?  Are you in a hybrid environment like me?

Advertisements