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

Change Management

Readers, following my earlier post on the comparison between Change Management and Risk Management, received requests on more about these two Project Management disciplines. I will discuss Change Management in this post and Risk Management in a subsequent one.

Change Management as the name suggests is for managing changes. But, what changes? The changes that are considered for Change Management can be broadly classified as –

• Technology changes
• Domain changes
• Resource changes
• Location changes
• Sub-contractor changes
• Strategy changes

Steps in Change Management

1.   Identify the dependencies of the change and the dependencies on change. This is to quantify the change.

2.   Assess the impact of the change on the current scenario – this could be positive or negative immediately, but positive in the long run.

3.   If the change is regarding a product that is in market, conduct a customer survey to know the likely response to the change.

4.   Identify any risks that are foreseen for implementing the change.

5.   Estimate the duration and budget for change.

6.   Estimate the resource requirements for the change.

7.   Enquire on the availability of the resources.

8.   Take a decision on implementing the change.

•  The change can be accepted for immediate implementation.
• The change can be accepted but for a delayed implementation.
• The change can be put on hold for want of more information or for a clarity on the situation.
• The change can be rejected if it is not viable due to budget constraints or resource crunch or any other reasons.

Change Management Board

In an organization, the change management is normally taken up by a change control board comprising of the field personnel who would be accountable for the change, top management who can make business decisions, subject matter experts if the change is regarding technology and/or domain.

Based on the type of change and magnitude of change, change control board might have to meet once or several times and ensure that a decision on change is taken as soon as possible.

Change Management and Risk Management

I had come across people trying to find the difference between Change Management and Risk Management. Thought of putting these two management activities together with clarity so that one can differentiate between the two and also understand when to use which one. One should remember that these two are distinct project management activities with certain information exchange when required.

Change Management

Change Management deals with making decisions regarding major unforeseen changes that might crop up during the execution of a project. A decision to accept or reject the change might have an impact on any of the following –

• Budget and Cost
• Resources
• Schedule
• Customer Relationship

Thus, the people involved in making such decisions also need to possess enough authority to accept the impact on these factors and absorb the impact. So, most of the organizations set up a change control board which analyzes the required change, arrive at the possible impact and take decisions. The execution team is bound to abide by the decision made by the change control board.

Risk Management

Risk Management involves

• Identifying the potential risks
• Analyzing each identified risk to assess its probability of occurrence and the heft of the impact in case it occurs
• Deciding whether the risk requires mitigation or contingency planning based on its probability and impact
• Monitoring the identified Risks
• Managing the Risk Mitigation and Contingency Plans that are put in place

Change Management and Risk Management

As you have observed, Change Management and Risk Management are two distinct project management activities. However, as with the case of any project activities, these two also have certain inter-dependencies.

Change Management has to consider the potential risks while taking decisions on changes. A simple example would be – suppose there is a scope creep into the project, and the change management board has taken a decision to absorb the change, while meeting the schedule timelines so as to meet the customer expectations. Here, the assumption that is made by the board is that the entire team would stretch to absorb the scope creep. But, there are potential risks in this decision –

• Some of the team members may not extend cooperation on the decision made. This would lead to schedule slippage
• Team burnout can occur with the stretched timings
• Attrition can happen with the team members not in favor of the decision made

So, Change Management has to cross-check with Risk Management on these aspects.

Risk Management has to consider time to time the possible changes in the domain, technology, resources, voice of customer and customer contact personnel interacting with the team. Any of these changes would ultimately have an impact on the project execution and /or project deliverables, amounting to the project success or failure.

Conclusion

Change Management and Risk Management are two distinct activities in management with clearly defined objectives. However, there are inter-dependencies between the two activities at the defined junctures.

Project Estimation Methods – WBS, 3-Point Estimation and PERT

Work Breakdown Structure (WBS) is used in three types of Estimation:

1.   Estimation using Work Breakdown Structure

2.   Three Point Estimation

3.   PERT

The Project Management Body of Knowledge (PMBOK) defines the Work Breakdown Structure as a "deliverable oriented Hierarchical Decomposition of the Work to be executed by the Project Team." WBS is usually derived with the participation of the entire team and is based on the team’s collective experience.

WBS can be used to arrive at the effort estimates for the project. WBS is also used in the estimation methods – Three Point Estimation and PERT. I have seen that some confusion exists regarding Three Point Estimation and PERT and they are used interchangeably. However, the two techniques are different.

Estimation using Work Breakdown Structure (WBS)

In this estimation method, the system is broken based on the activities in the system. The activities are further broken into tasks. Based on the tasks, effort and schedule are estimated.

Normally, Wideband Delphi method is used for arriving at the effort estimate of the tasks. One can use Three Point Estimation method also for the effort estimate.

Three Point Estimation and PERT

Three Point Estimation and PERT are based on three values for each task –

1.     a most optimistic estimate (O)
2.    a most likely estimate (M)
3.    a pessimistic estimate (Least likely estimate (L))

Three Point Estimation

Three Point Estimate (E) is based on the Simple Average and follows Triangular Distribution.

E = (O+M+L)/3

As you are aware, in a Triangular Distribution,

Mean = (O+M+L)/3

Three Point Estimation is typically used for small repetitive projects.

PERT (Project Evaluation and Review Technique)

In this method, the most-likely estimate (M) is weighted 4 times more than the other two estimates (optimistic (O) and pessimistic (L)). Thus, PERT Estimate (E) is a weighted average and follows Beta Distribution.

E = (O+4*M+L)/6

PERT is commonly used along with CPM (Critical Path Method). CPM highlights the tasks that are critical to the project. If there is a delay in these tasks, the project gets delayed.

PERT is classically used for large non-repetitive projects, usually R&D projects.

Project Estimation

When to do the Project Estimation?

·         At the start of the project

·         At every project milestone

·         When requirements change

·         When there is a scope creep

·         If and when there are any changes in the team (If a team member leaves the organization / if a team member has to take unexpected leave, etc.)

·         When you notice that any of the assumptions you made are not holding good

Assumptions

You need to jot down all the assumptions that you are making while doing the estimation. This is because if any of the assumptions topple, your estimates also go haywire.

Basis for Estimation

·         Past Data/Past Experience

·         Available Documents/Knowledge

·         Assumptions

·         Identified Risks

Estimation Methods

There are several estimation methods in practice. You can choose the one that suits your project. Following table gives you an idea on how to choose an estimation method:

S. No.	Project Context	Estimation Method
1	When there is limited information about the current project. When estimates are used in deciding if an upcoming project is profitable to the organization.	Analogy
2	When clear requirement specifications are available with regard to the functionality of the software to be developed.	Function Points (FP)
3	When there are tasks that are critical in the project. If there is a delay in these tasks, the project gets delayed. Project is large and non-repetitive, such as an R&D project.	PERT
4	When the project is small.	Three Point Estimation
5	When the requirements are in Use Cases form.	Use Case Points
6	When the requirements in User Stories form, as is the case in agile projects, mostly Scrum.	Planning Poker
7	When the project is to be decomposed into small sized deliverables	Work Breakdown Structure (WBS)
8	When there is a panel of experts to do the estimation	Wideband Delphi

Next, let us look at each of these Estimation methods.

Analogy

Project Manager and Team need to collaborate in arriving at the estimates by Analogy. If there are past projects similar to the current project, the historical data is used to arrive at the estimates. Otherwise, from the historical data of the projects, data related to the similar modules and similar activities is collated and the estimates are drawn from them.

This method mostly relies on the past data. If there is reliable past data, the method is found to be accurate up to 60%.

Function Points

Function Points is a standard widely accepted estimation method for software sizing, though the method needs expertize in arriving at the required parameters for the computation.

International Function Point Users Group (IFPUG) defines the standard set of rules, processes and guidelines for Function Points (FP) Counting and publishes them in Counting Practices Manual (CPM). One needs to abide by CPM if Function Points (FP) is chosen as the estimation method.

Internal Logical File (ILF) is a user identifiable group of logically related data or control information is stored in a file within the application boundary. External Interface File (EIF) is a user identifiable group of logically related data or control information that is used by the application for reference purposes only.  The data resides entirely outside the application boundary and is maintained in an ILF by another Application.

External Input (EI) is how the application gets information from outside the boundary to inside.  The data can come from a data input screen or another application. The data can be either control information or business information. External Output (EO) is how data comes out of the application in the form of a report and/or an output file sent to other applications. Additionally, an EO may update an ILF.  External Inquiry (EQ) is for data retrieval.

Record Element Type (RET) is the largest user identifiable sub group of elements within an ILF or an EIF.  Data Element Types (DETs) are the different elements within each RET that are unique and user identifiable.

File Type Referenced (FTR) is the largest user identifiable subgroup within the EI, EO, or EQ that is referenced to. A Data Element Type (DET) is the user identifiable unique data subgroup within an FTR.

Use the counting rules for counting FTRs and DETs in ILFs and EIFs. (Refer to the IFPUG CPM). Determine the functional complexity (L=Low; A=Average; H=High) for each ILF and EIF from the counts of corresponding DETs and RETs, using the ILF/EIF complexity matrix:

RETS	Data Element Types (DETs)
	1-19	20-50	>50
1	L	L	A
2 to 5	L	A	H
>5	A	H	H

Obtain the FP Counts of each ILF and EIF from their functional complexities.

Functional Complexity	FP Count for ILF	FP Count for EIF
Low	7	5
Average	10	7
High	15	10

Similarly, use the counting rules for counting FTRs and DETs in EI, EO and EQ. Determine the functional complexity (L=Low; A=Average; H=High) for each EI using the EI complexity matrix from the counts of corresponding FTRs and RETs. Determine the functional complexity (L=Low; A=Average; H=High) for each EO and EQ using the EO/EQ complexity matrix from the counts of corresponding FTRs and RETs.

EI Complexity Matrix:

FTRs	Data Element Types (DETs)
	1-4	5-15	>=16
0-1	L	L	A
2	L	A	H
>=3	A	H	H

EO/EQ Complexity Matrix (EQ must have a minimum of 1 FTR):

FTRs	Data Element Types (DETs)
	1-4	5-15	>=16
0-1	L	L	A
2	L	A	H
>=3	A	H	H

Obtain the FP Counts of each EI, EO and EQ from their functional complexities.

Complexity	FP Count for EI / EQ	FP Count for EO
Low	3	4
Average	4	5
High	6	6

FP Count is obtained by summing up all the ILF, EIF, EI, EO and EQ counts.

Use Case Points

Counting Use Case Points is based on the Use Cases and Actors that are identified for the application to be developed. This estimation method also results in the software size.

To arrive at the Use Case Points of an application, perform the following steps:

** Find the number of transactions in each Use Case. If user goal levels are used to write the Use Cases, a transaction is equivalent to a step in the Use Case. So, you can find the number of transactions by counting the steps in the Use Case.

** Determine the complexity of each Use Case based on its number of transactions.

** Assign Use Case Weight for each Use Case based on its complexity.

Use Case Complexity	Number of Transactions	Use Case Weight
Simple	≤ 3	5
Average	4 to 7	10
Complex	> 7	15

** Sum up the Use Case Weights of all the Use Cases to obtain the Unadjusted Use Case Weight (UUCW).

** Similarly, determine the complexity of each Actor and the corresponding Actor weight.

Actor Complexity	Example	Actor Weight
Simple	A System with defined API	1
Average	A System interacting through a Protocol	2
Complex	A User interacting through GUI	3

** Sum up the Actor Weights of all the Actors to obtain the Unadjusted Actor Weight (UAW).

** Sum of Unadjusted Use Case Weight (UUCW) and Unadjusted Actor Weight (UAW) gives Unadjusted Use Case Points (UUCP).

** Adjust the Unadjusted Use Case Points (UUCP) for Technical Complexity and Environmental Complexity to obtain Use Case Points (UCP).

We will discuss the other Estimation methods in the upcoming blogs.