Agile Methodologies – Extreme Programming + Scrum – A Current Trend

Readers, of late Agile Software Development is gaining momentum with many organizations adapting the agile practices as made suitable to their requirements. Several Agile methodologies came into existence with each one focusing on a strategy that helps the organizations meet their objectives. Hence, the choice of an agile methodology should be at par with the organization’s goals. I will discuss the latest Scrum + Extreme Programming hybrid trend in this post.

Extreme Programming

Extreme Programming (XP) was developed by Kent Beck focusing on using the industry best practices and taking them to extreme. Extreme Programming is one of the earliest Agile Methodologies that is continuously evolving. Extreme Programming provides a flexible framework that can be fine-tuned to a specific methodology.

Extreme Programming Practices

Kent Beck defined the following Extreme Programming Practices in his Book – Extreme Programming Explained.

·         The Planning Game

·         Short Releases

·         Metaphor

·         Simple Design

·         Testing

·         Refactoring

·         Pair Programming

·         Collective Ownership

·         Continuous Integration

·         40 hour Week

·         On-site Customer

·         Coding Standards

These practices are interdependent and achieve the Extreme Programming objective – is any of the practices is weak, the strength of the other practices makes up for it.

Evolving Extreme Programming Practices

The Extreme Programming practices are continuously evolving and are found to be effective in the other agile methodologies also. Some examples of the evolved practices are the following:

·         On-Site Customer is evolving into Whole Team

·         The Planning Game is evolving into Release Planning and Iteration Planning

·         Testing is evolving into Acceptance Testing, Unit Testing and Test-Driven Development

·         Refactoring is evolving into Design Improvement

·         40-Hour Week is evolving into Sustainable Pace

Remember that any of the Extreme Programming Practices that you choose should be implemented be implemented without compromising on their values. Otherwise, you cannot claim that you are using Extreme Programming.

The recent trend in Extreme Programming is in the use is Scrum + Extreme Programming Hybrid.

Scrum

Scrum is a popular and widely used agile methodology. In Scrum, the development work is broken down into Releases that are accomplished in time-boxed short iterations called Sprints. In every Sprint, only the required and sufficient functionality that is prioritized by the Customer that you can deliver by the end of Sprint is taken up and is termed as Backlog Items. The developers and the testers are involved in every activity from the beginning to the end. Acceptance Criteria is defined as agreed with the customer at the beginning of the Sprint itself and continuous testing will be adapted. A working product increment is released at the end of every sprint.

Scrum, as with the case of any development methodology, is effective in certain situations, but has its own shortcomings.

·         The time-boxed Sprints will not allow any flexibility in the Release schedule that hampers both development and testing

·         Scrum, on its own do not give directions for development, and assumes that the agile manifesto is truly followed.

Hence, Scrum is usually combined with other Agile Methodologies that focus more on the Development Strategies.

Scrum + Extreme Programming Hybrid

Scrum is found to be more effective if incorporated with Extreme Programming Practices that are complimentary in nature. While Scrum focuses on the fixed scope for Sprints, Burn-Down charts, etc., Extreme Programming focuses on the aspects such as continuous communication, frequent feedback loops, refactoring, collective ownership, continuous integration, Test-Driven Development, etc. This hybrid is producing anticipated results, as

·         Scrum being a defined methodology, can be adapted from day-one of the project

·         Extreme Programming focusing on communication and team cohesion, enables the team to get more focused on the development

Scrum + Extreme Programming Hybrid Tools

SpiraTeam Tool and Rapise Tool can be used for Scrum + Extreme Programming hybrid projects.

For details, refer:

https://www.inflectra.com/SpiraTeam/

https://www.inflectra.com/Rapise/

Project Monitoring and Tracking

Readers, the core of any project is execution. A successful project is one that is executed within the stimulated time, within the budget and with the expected quality. Hence, project needs to be monitored on these aspects continuously and corrective actions need to be taken immediately. This would require gathering the following information periodically –

·         Scheduled Work vs. Completed Work

·         Time Elapsed vs. Remaining Time

·         Budget Expended vs. Remaining Budget

·         Resources Planned vs. Resources Availability

·         Estimated Effort vs. Actual Effort

·         Metrics on required parameters, such as Defects

There is a subtle difference between project monitoring and project tracking. Project tracking involves gathering the above information from time to time and taking actions accordingly. For e.g. if there is an expected schedule slippage, put more resources to complete that work on time. If any planned resource is unavailable due to unforeseen conditions, arrange for an alternative resource.

On the other hand, project monitoring involves holistic approach for project management. It involves the following activities –

·         Communication with the customer and stakeholders to discuss the project status and obtaining timely feedback

·         Managing any changes that occur in the work that is being executed

·         Identify, assess and manage the project risks

·         Ensure customer satisfaction throughout the project

·         Analyze the performance of resources

·         Arrange training and/or mentoring if and when necessary

·         Focus on team cohesion by team building, team motivation and team collaboration

·         Monitor quality aspects of the work

·         Take timely decisions as and when required.

Maintaining a project dashboard visible to the entire team is a good practice. Similarly, mail communication and periodic status reports to customer will enhance transparency.

Risk Management

Introduction

As promised in my earlier post, I will discuss in detail about Risk Management in this post. Let me start defining what we mean by a Risk –

“A Risk is any event that if happens can have a significant influence on execution”.

•         if happens – amounts to probability of happening – meaning it may happen or may not happen, but there is a likelihood of happening.
•         Influence – amounts to impact on the execution.

Thus, a Risk has two parameters – Probability and Impact.

A note here – by CMMI Institute’s definition of a Risk, Impact mentioned is negative. While, by PMI definition of a Risk, Impact can be either negative or positive.

In this blog, I go by CMMI Institute’s definition that if there is a Risk, it would mean that it can have negative impact if it occurs. This is because of two reasons –

1.   World renowned CMMI Lead Appraisers abide by this definition.

2.   Several organizations that I guided for quality implementation and sustenance, successfully managed their projects with Risk Management following this Risk definition.

Risk – An example –

With this introduction, we will get into the Risk Management activities.

Risk Management Activities

Risk Management involves the following activities –

1.   Identifying Risks

2.   Assessing Risks

3.   Planning Risk Mitigation

4.   Planning Risk Contingency

5.   Monitoring Risks

1.   Identifying Risks

This is the most important and necessary activity in Risk Management. And it is an ongoing activity and not a one-time activity. When you identify Risks, the statement of Risk as a likelihood event should be recorded. For e.g.

•         The incessant rains may damage crops.
•          The peak rainfall may cause a flood.

These are valid statements of Risks, whereas the following are not.

•          The incessant rains damaged crops.
•          The peak rainfall will cause a flood.

It is recommended to have a Risk database wherein you have a record of earlier Risks and unforeseen events. This would help you as a ready reckoner for identifying the Risks in a particular field.

It is important to record the identified Risks, preferably in a tracker to facilitate monitoring.

2.   Assessing Risks

Once a Risk is identified, it needs to be assessed.  You need to find the two parameters of the Risk - probability of occurrence of the Risk and the extent of the impact if the Risk occurs.

I suggested and found practical, the following quantification of the Risks –

•        Probability – An integer in the Scale of 1-5 (1-Lowest, 5-Highest)
•        Impact - An integer in the Scale of 1-5 (1-Lowest, 5-Highest)

A third parameter, Risk Exposure is obtained from these two –

Risk Exposure = Probability*Impact

Thus, Risk Exposure would be an integer in the Scale of 1-25.

The next step, would be to compare the Risk Exposure to Risk Exposure Threshold.

The Risk Exposure Threshold can be defined at an organization level, a business unit level or a project level.

•          If Risk Exposure of a Risk is more than the Risk Threshold, then you need to plan Risk Mitigation and Risk Contingency – steps 3 and 4 given below.
•          Otherwise, proceed to step 5, skipping steps 3 and 4.

This comparison is required because, it is not cost effective to plan mitigation/ contingency for every Risk identified, unless it is of significant magnitude.

3.   Planning Risk Mitigation

A plan to mitigate a Risk aims at decreasing the probability of occurrence of the Risk.

E.g. Mitigation Plan for the Risk given in the example above.

4.   Planning Risk Contingency

A contingency plan for a Risk aims at decreasing the impact of the Risk if it occurs.

E.g. Contingency Plan for the Risk given in the example above.

5.   Monitoring Risks

Risk monitoring involves the following tasks –

•          Tracking the status (open/closed) of the Risks. A Risk that is no more valid or a Risk that already happened and will not repeat in near future can be closed
•          Noticing symptoms for occurrence of the identified Risks so that action can be taken at appropriate time. Everyone involved in the work can contribute to this task as anyone can get feelers about the symptoms. Hence, it is a good practice to discuss Risks in group meetings
•          Execution of Risk mitigation plans when required
•          Execution of Risk contingency plans when required
•          Identifying Risks from time to time
•          Contributing identified Risks to the Risk database