Agile and CMMI

I wanted to talk about this issue a long time ago, but I didn’t have much to share with you.

My first trigger for this post was few months ago when Software Engineering Institute (SEI) of Carnegie Mellon University published a report under the name CMMI or Agile: Why not embrace both! which is a confirmation by CMMI authors that you can satisfy both requirements.

The report summarizes the history of both paradigms and why it is perceived that CMMI is waterfall while it isn’t. It also summarized the misconceptions in both ideas and how to overcome them. And it ends by a call for action for both practitioners and trainers to bridge the gap between both.

The report also addresses other issues such as:

  • The Origins of Agile Methods
  • The Origins of CMMI
  • Lack of Accurate Information
  • Terminology Difficulties
  • There Is Value in Both Paradigms
  • Challenges When Using Agile
  • Challenges When Using CMMI
  • Problems Not Solved by CMMI nor Agile

Yesterday, I have been in a 2-days workshop on the same issue where we have conducted some real life case studies to discover how we can come out with processes that satisfy both, and get useful feedback from experts in both schools.

If I can summarize what I have learnt in those 2 days, it is that you have to be first convinced why you need Agile and why you need CMMI, and when you do, you will be able to select to which level you want to embrace each, and what are the practices that would "add value" to your organization (not only individual projects)

Finally, I would like to refer you to this 2 years old post by Jeff Sutherland in which he says that Scrum supports CMMI level 5


Scrum for Team System

It is unlikely to find an agile software project not using JIRA, Subversion, CruiseControl, or some other agile productivity suites. One of the most commonly used suites in Microsoft Environment is Team Foundation Server which combines Source Control, Task Planning, Testing, Bug and Issue Tracking, a Build Server, and a Dashboard interface to share documents and ideas in a wiki-like manner.

TFS has an out-of-the-box process template for agile projects, but this template is not fully compliant with Scrum. Since TFS is open for any custom process template, some vendors have provided free templates for Scrum.

The first effort in this area was Scrum for Team System by Conchango. Then a group of VSTS MVPs created a light-weight process template that is easier to install and configure which makes it more appropriate for small projects with small teams.The latest one is eScrum which is provided by Microsoft but as an additional download.

It was also convenient to view the sprint tasks in the form of task board with drag-n-drop capabilities to move tasks between panes. Conchango also had provided Task Board for Team System but it is commercial with one month free trial.

I personally prefer using the TFS integration with MS Office to add tasks in Excel with a running sum of used capacity and then post the tasks to TFS at once. There are many other uses for showing tasks in Excel like conditional formatting of cells to indicate different states, severity, priority and so on.

I have failed a sprint!

Welcome back everyone. I have been busy for the last month working hard trying to achieve a substantial success in this sprint as it had a special value to me; first, because it came after a long time of being idle, and second, because we had just resolved some external issues that held us back in the previous sprints.

At the beginning of the sprint we went through with a high velocity without the need for any overtime nor affecting quality which impressed me and later we had some tasks that required additional efforts than expected so we started losing velocity. We were still inline with the optimal burn-down but not for long.

I was still convinced that the remaining tasks can be squeezed in the final few days of the sprint. So we kept the hard work crossing our fingers to finish on time. Unfortunately, we had to extend the sprint for one day, ignore some features, jeopardize quality, and finally (as expected), the final build was rejected.

It is hard to admit the failure, but the bitterness of failure is the medicine that heals your weaknesses, and our sprint retrospective was really fruitful and full of lessons learned, so here are some:

  1. Pairing of tasks does not always result in dividing the effort (the famous example: nine women cannot give birth to a baby in one month).
  2. Instead of pairing, you can divide tasks into smaller ones, which have more benefits; more accurate estimation, a checklist to define what’s is meant by “done”, and less dependency of tasks.
  3. It is better to be pessimistic in you estimation till your team proves otherwise than to commit to what you are not 100% sure you can achieve.

And my personal lesson I learned was:

  1. It feels good to be superman, but it feels worse if you fails to prove it.

Planning Poker Cards

If you don’t know what are planning poker cards are, it is one of the nice ways used by Agile teams to estimate the effort of a user story, as the whole team of developers are involved in estimating the effort, not only managers.

If that estimation is done manually, you can have funny cases like these, so some would recommend doing it using cards. I personally think that a nice deck of regular poker cards would do the job, but they might not be as interesting as the Agile version.

You can also play the planning game online here which is brought to you by agile consultants and trainers at Mountain Goat Software.