CMMI - Organizational Process Focus (OPF) in Agile environment

Requirements Tracebility Body in Agile - It is RTBA for your CMMI Requirements Management PA!

Requirements Management (REQM) process area, in CMMI, is much easier for your implementation if you just think of the tracebility like a body, and choose the easiest practices for connecting this body.
It is RTBA (Requirements Tracebility Body in Agile), here is the first version 1.0

The body welcomes your comments.

Predicting the team's Velocity: yesterday's weather method

I would like to share this article with you:

How much software will you deliver in the next Sprints/iterations?" - do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: "Where we will be in three months from now?".

If you track your team's Velocity you are able to answer such questions somewhat accurately, which is great. I personally don't know better tool for answering presented questions than tracking development team's Velocity.

Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team's Velocity.

Velocity
In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint - see Measures of size article. This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.

What will be the weather today?
If you had to answer such question the best one would be that the weather today will be the same (or very similar) as yesterday (I assume you are not weather professional and you can only guess). The same is with Velocity and the amount of work you can predict doing in the upcoming Sprint. How much can you deliver? The same amount (or very similar) as in the previous Sprint - simple. You should take into account only the yesterday's weather i.e. only the last Sprint. Note that the yesterday's weather is one but not the only method to predict team's Velocity.

Let's consider the following example. Development team is composed of Mike, Martha, Paul, Josh and Julia. They worked on the project we are estimating following numbers of days (Sprint length is four weeks):

Team Member	Days Worked
Mike	16
Martha	10
Paul	14
Josh	16
Juila	14
Sum:	70

They delivered software worth 25 story points (sp) i.e. the team's current Velocity is 25. They claim that story for 3 sp is 80% done but this story is not DONE from the user's perspective. This story is not and cannot be taken into the final sum of delivered software - therefore we still have 25 sp instead of 28 sp.

To summarize - the team delivered software worth 25 story points in 70 work days.

How many story points we can deliver next Sprint?
If everybody in the team is available exactly the same amount of time in the project in the upcoming Sprint you can assume that the Velocity will be about 25. Depending on the team's experience in Scrum and their estimation skills it can vary i.e. if the Velocity of the beginner team will be 20 or 30 in the next Sprint it's still OK. The Velocity usually stabilizes after few Sprints (but it can still fluctuate slightly - you will probably never have the same results in two subsequent Sprints) but even if we consider experienced Scrum team we can expect that the Velocity in the next Sprint can be slightly lower or higher than 25.

If the team members will not be available in the next Sprint the same amount of time because of many reasons, or the Sprint itself will be shorter (e.g. because of some national holidays) you should verify planned Velocity.

The following example is based on techniques used in a real project that was developed be me and my teammates at Intel. Of course, names and numbers are not real.
The first thing to do is to sum team members' availability in the next Sprint. In four weeks we have 20 work days but there is one day of national holiday, therefore we have 19 work days. I also assume that team members can spend their 20% of time on developing some fresh stuff, learning, researching new technologies, etc. I will subtract 20% of time available for each time member separately. Let's take a look at the following table:

Team Member	Days Planned	Days Available (-20%)
Mike	19	15
Martha	15	12
Paul	19	15
Josh	10	8
Juila	10	8
Sum:		58

If the team delivered software worth 25 story points during 70 work days it means that they can commit to ~21 story points during 58 work days in the next Sprint (58/70 * 25 = ~21). So, predicted Velocity is about 21 story points.

Commitment
I assume that you have prioritized backlog of stories you have to deliver. I also assume that you know that you have to deliver them ordered by priority. This way you can start picking the stories until you collect about 21 story points in this example. It is really important to say about word - we are still in the estimation level, we don't know the accuracy of our estimates. That's why teams should commit to deliver about N story points.

What if the granularity does not allow you to hit exactly 21 story points? In this case you should take one smaller user story that is not at the top of your current backlog (still close to the top priorities ones) or exceed planned Velocity if and only if the team feels that can deliver selected stories. It is also pretty natural that the team can commit to 20 or 19 story points if they feel 21, 22 or 23 will be too much. Team is the most important here and they have the strongest deciding voice. At any rate the Velocity will be verified in four weeks i.e. at the end of next Sprint.

Wrap up
I hope this post helps you, I explained what Velocity is and how useful it is. I also hope you will be now able to answer the question "How much software will you deliver in the next Sprints?". Use the force which is Velocity in this particular example.

If you need more detailed information about agile estimation, planning, Velocity and all similar topics you should read Mike Cohn's book: Agile Estimating and Planning. It is brilliant and written with a very accessible language.

If you have some comments, want to ask some questions, something is not clear then comments section is all yours.

Resources
You may find following links valuable:

• http://agilesoftwaredevelopment.com/blog/pbielicki/predicting-team-velocity-yesterday-weather-method
• http://agilesoftwaredevelopment.com/blog/jeremy/velocity-measuring-and-p...
• http://agilesoftwaredevelopment.com/blog/cspag/team-velocity-more-sum-it...
• http://agilesoftwaredevelopment.com/blog/jeremy/productivity
• http://agilesoftwaredevelopment.com/2006/12/measures-of-size

Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment

The Capability Maturity Model Integration (CMMI) has been broadly used for assessing organizational maturity and process capability throughout the world. Although most of the customers give priority to CMMI certified organizations over others for guaranteeing the quality, the nature of their rapid market change can no longer accept heavyweight plans, requirements specification, change requests, contract negotiation, and other documentation. Moreover, the rapid change in information technology has caused increasing the frustration more, especially that there are new competitors started using lightweight processes that invite to customer collaboration over contract negotiation and working software over comprehensive documentation that is called “Agile” methodologies that have been adopted to tackle this challenge. Agile development methods and CMMI are often perceived to be at odds with each other. In fact, it’s possible to embrace both to dramatically improve business performance. This paper focuses on the verification of implementing CMMI Project Management process areas in agile organizations based on a real and practical experience in Agile and CMMI successful projects.
The authors are going to share their practical experiences in interpreting the CMMI model's project management practices in an Agile environment to address the model intent and not compromising on the credibility or value of the practices.

The paper covers these process areas:
- Project Planning (PP)
- Project Monitoring and Control (PMC)
- Integrated Project Management (IPM)
- Risk Management (RSKM)

Find paper abstract in CMMI 9th Technology Conference and User Group, National Defense and Industrial Association (NDIA)
http://proceedings.ndia.org/0110/9230.pdf

Download the full paper, if you are interested, please send to aamahdys@gmail.com and I will reply with the paper attached.

Practical Report: CMMI Measurements and Analysis based on Agile (Scrum) Method

Software industry is one of the most empirical industries due to its high dependence on technology and people. Each software company adopts a specific development methodology, and furthermore seeks to build a system for its process improvement by adopting one or more Software Process Improvement (SPI) models. CMMI is a process framework which is widely adopted by software and systems development companies, while Scrum is one of the more recent project management agile method whose adoption is growing rapidly. CMMI is basically a process improvement framework which provides a set of processes for software and system development management, Scrum can be thought of as an iterative project management framework for development activities, CMMI has a wider scope and different aims to those of Scrum and covers production support, maintenance, product implementation and application transition type projects as well.
Scrum and other agile methods have clearly appeared in 2001, This paper shows how to implement the Measurements and Analysis (M&A) process area of CMMI model and clarify how M&A can be achieved in the agile (Scrum) organization. Most of the promising objectives of any software development method or process are delivering working software on time, quality and budget. Software Engineering Institute (SEI) has paid a lot of efforts to mostly satisfy these objectives in its process improvement models, and lately CMMI version 1.2 has been released. Nevertheless, the world becomes convinced with adding another objective, which is delivering a business value to the customer. Along the years, software engineers have proposed several methodologies
Agile is the most known and latest proposed development method that can achieve this objective beside the other fore mentioned objectives.
Our objective in an agile environment is not to do software measurement. We must learn to build reliable software measurement process based on valid software measurement tools. If we try to do too much too soon, we will likely fail. Basically, software engineering measurement is not a resource issue; it is a commitment issue. The bottom line is that all the usable measures from practicing Scrum on a project could be used to address the practices of M&A process area. Infact, the alignment of these measures to the information needs is very visible due to the very nature of “value-based” focus of the scrum method. In our research, we found that there need not be any additional measures that are required to be “invented” to fulfill the M&A goals from CMMI model. Usage of existing ones is enough and we will share those mappings and arguments with you for your application and subsequent extension to other process areas in the model. We are also going to share our learnings from carrying out these discussions/learning events with you.

Find paper abstract in CMMI 9th Technology Conference and User Group, National Defense and Industrial Association
http://proceedings.ndia.org/0110/9225.pdf

Download the full paper, if you are interested, please send to aamahdys@gmail.com and I will reply with the paper attached.

The Role of the Agile Coach

One of the new roles introduced by Agile software development is that of the team Coach. Until Agile came along coaches were confined to the executive suite or the sports field. As with any new role it takes a while before it is fully understood and scoped.Agile teams can, and do, exist without the Coach role being filled but such teams do not necessarily achieve peak performance. Reports from Yahoo* suggests that coaches can make a significant contribution. In this study Scrum teams without coaching support increased their productivity by 35%, while those with Coach support recorded 300% or greater improvement.
What then is the Coach’s role? And what does a Coach do?
For some people the title Agile Coach is self-descriptive but for others it leaves the questioner none the wiser. So let me offer a definition: an Agile Coach help a teams or individual adopt and improve Agile methods and practice. A Coach helps people rethink and change the way they go about development.
Trainer and consultant
The Coach role is part embedded trainer, part consultant – specifically an advisor. Even the best Agile training courses cannot cover every detail or eventuality a team will encounter. The Coach is there to continue the training after the formal classes are over.Having an onsite Coach will help team members put their training into action. Too often people attend training, think it’s good stuff, and then fail to incorporate their new learning into their daily work. This is particularly true when the organization sends mixed messages about change.The Coach also helps teams apply Agile and Lean thinking to the specific environment and impediments they face. Working as an advisor the Coach can help the team adapt the methodology to their environment, and help the team challenge the existing environment.Taken together these two sides make the Coach into an effective change agent - someone who is both motivating change and making it happen. That an organization is prepared to spend money on a Coach demonstrates they are serious about making the change happen.So as well as helping the team execute the Agile vision the Coach may also help motivate the team to that vision. The Coach does this by painting a picture of how the Agile world works by telling stories and providing explanations.
Three types of Coach
While every Agile Coach brings their own approach to an assignment there are broadly three types of Coach. The first is technical, such a Coach works mainly with those cutting code and sometimes becomes fully integrated with the developers. Technical coaches are likely to be found pairing with developers to help them apply test driven development, support developers in refactoring work, help improve the continuous integration system or other activities that are close to the code.Technical coaches are experts in what they do, they aim to both transfer their knowledge and enthuse team members to try new approaches and techniques.The second type of Coach is again an expert who aims to transfer their knowledge however the focus is not on technology but on process, management and requirements. Coaches like myself work with project managers, line managers, business analysts, product managers and others who are responsible for making the work happen.Rather than working at the code-face coaching tends to happen in meetings and in one-on-one sessions. There is a greater focus on facilitating events that help create change and improvement.For example, in addition to moderating stand-up meetings and planning meetings, I normally run retrospectives and “future-spectives”. A future-spective is an event which applies many of the same ideas and techniques as a retrospective but is used to kick-off a new project or Agile transition.When working with managers there is more to coaching than simply knowledge transfer. It is much more about helping people rethink their inbuilt assumptions and mental models. Many managers have experienced career success with other development modes so may perceive Agile as a threat. Here coaching gives way to the third type.The third type of Coach may work across everyone in the team but mostly finds himself working with managers and analysts. In this mode the Coach drops the expert persona and focuses instead on helping individuals and teams solve their own problems. To do this the Coach takes on a non-directive approach. When working as an expert authority the Coach is providing direct advice and recommendations. This is known as directive coaching. In the non-directive mode the Coach may – or may not – be an expert in the field but they assume the coachee is the expert and the Coach helps facilitate their learning.While directive coaching is often found in sports teams the non-directive approach is used by coaches who help business leaders. This approach is set out in books such as Coaching for Performance** and Effective Coaching*** and anyone thinking about embarking on this approach is well advised to read at least one.The diversity of coaching roles makes it difficult for one person to fill all. A technical expert will find it difficult to switch to a non-directive mode and team members may be confused when an expert starts throwing questions back at them. Even if one individual can cover all bases on all but the smallest projects there is unlikely to be enough time to do each role justice.
Longevity of coaching
However a Coach works, and whatever approach they take they the Coach needs to avoid creating a learned dependency. This happens when the team comes to depend on the Coach, without the Coach the team fall back to their old ways. Coaches need to be able to withdraw when the time is right and let the team continue.While many companies will have their own coaches on staff and some will work with teams day-in, day-out for months or even years, there is a lot to be said for using external coaches and limiting the period of coaching.While internal coaches will start with the advantage of knowing the team and domain, external coaches benefit from bringing a fresh mind and new perspective. This allows them to challenge assumptions more easily and suggest alternative approaches.Some coaching activities – such as running retrospectives – can become stale and formulaic over time. Changing the facilitator can inject energy and new ideas.
Scrum Master or Coach?
As an Agile Coach I am frequently asked “What is the difference between a Coach and a Scrum Master?” Indeed, there may be very little difference if a Scrum Master decides to play the role from a coaching perspective. However this is not always the case, some organizations see Scrum Masters as thinly disguised Project Managers. In such cases the difference between Coach and Scrum Master is wide.There are perhaps two main differences between the Scrum Master and Agile Coach role. In Scrum the Master is tasked with ensuring the team follows the Scrum process and rules. An Agile coaches remit is somewhat wider with a greater emphasis on the change agenda.As such, the second difference is one of duration. All Scrum teams should have a Scrum Master who works with the team in every sprint and stays with the team for the duration of the work. An Agile Coach may stay with a team but they may also move on, or they may stand back over time.On an assignment last year I coached several teams at one company. Initially I started with some training and by walking each team through the Agile ceremonies – planning, daily meetings, retrospectives, etc. As the teams became more familiar with the activities I reduced my involvement and allowed team members to take over.Again, this approach casts the Coach as change agent. It may be that teams need different coaches at different stages of their development: A technical coach to help the developers master TDD; a second Coach to lead the team through early adoption and a third to refine the processes and practices later.
Conclusion
Much of the Coach’s work is about changing individuals’ mindsets, the mental models and short-cuts which they have build up over years. As my fellow Coach Niels Malotaux put it recently “Coaching is about resetting people’s intuition.”There are hundreds, even thousands, of small decisions made every day during software development. These decisions are based on people’s mental models of how development works – or how it doesn’t work. Part of the Coach’s role is to help people unlearn many of these models and relearn models based on Agile values. Cumulatively these many small decisions are more important than the few big decisions made occasionally. By definition big decisions aren’t made that often and you usually know they are being made but small ones are made without thinking. It is no use switching to Agile if you keep making the small decisions based on some other model.The architect Mies van der Rohe once said “God is in the detail” and so it is with Agile: “Agility is in the detail.” It is the small decisions that can’t be seen in advance that often derail work. It’s the Coach’s job to help spot the small decisions and ensure they Agile principles are applied.Part of the reason I prefer working as a Coach with a team rather than as a Trainer is because you see the change play out over time. Yes I deliver training but when I’m gone do people use it? When I’m there as a Coach I walk people through the changes, the details and I see the change happen.

References:
Rolling Out Agile in a Large Enterprise, International Conference on Software System, Hawaii, 2008, http://www2.computer.org/portal/web/csdl/doi/10.1109/HICSS.2008.382
Coaching for Performance, John Whitmore, 1992
Effective Coaching, Myles Downey, 1999

Scrum model in one page!

Source: http://alistair.cockburn.us/JDKrise+Scrum+laid+out