Colocated Team Vs. Distributed Team in Scrum

One very important factor considered while forming Scrum team is physical location of team members– are all of them located at the same place or in geographically dispersed locations. For many of the Scrum practices, high-level, frequent communication between members of the Scrum Team, Product Owners, and Scrum Masters is required and to enable this, it is preferred that team members are colocated. Colocation allows both formal and informal interaction between team members. This provides the advantage of having team members always at hand for coordination, problem- solving, and learning. Some of the benefits of colocation are –

·         Questions gets answered quickly

·         Problems are fixed on the spot

·         Less friction occurs between interactions

·         Trust is gained and awarded much more quickly

However it is always not possible to have colocated teams. At times the Scrum teams may be distributed due to outsourcing, offshoring, different physical locations, work from home options, etc. In case of distributed teams, appropriate infrastructure has to be made available to ensure that regular communication takes place among team members. Whenever possible, a distributed team should have an in-person Project Kick-off Meeting at a common location. This will help establish the basis for future communications. It is also a best practice to have different team members relocate to another site to act as cultural liaisons to ensure proper communication throughout the project.

Collaboration tools play a very important role in effective communication between team members.Collaboration tools that can be used for colocated and distributed teams are as follows –

1.    Colocated Teams (i.e., teams working in the same office) – If teams are colocated, preferred modes of communication include face to face interactions, decision rooms or war rooms, Scrumboards, wall displays, shared tables, and so on.

2.    Distributed Teams (i.e. teams working in different physical locations) –Some tools that could be used for effective collaboration with distributed teams include video conferencing, instant messaging , chats, social media, shared screens, and software tools which simulate the functionality of Scrumboards, wall displays and so on. Because in person Daily Stand-up Meetings are not possible in case distributed teams, they need to be done electronically. One important point to consider here is to fix an acceptable time for everybody for the daily meeting - for example, early morning for America, mid-day for Europe, and evening for Asia Pacific and so on.

For more information on Scrum, Scrum Body of Knowledge (SBOK^TM Guide) from SCRUMstudy is a recommended reading.

Change Management in ITIL

Under the ITIL framework, the three types of changes are: standard, normal, and emergency changes. Let’s have a look at the first two kinds of change namely standard and normal changes and then talk about emergency changes.

Changes that go via the fixed process of change management are considered to be normal changes. These are changes which start with the creation of a Request for Change (RFC) which is in turn reviewed and assessed.

Standard changes are those that are pre authorized and are of low risks. In organizations, they would have their own method of deciding the type of standard changes that are allowed and also the conditions for a change to be considered as standard. They would also decide on who is approved to allow such changes and also how to manage such changes. Recording and approval is needed on the lines of normal changes. The approval of this kind of change does not travel up the management of change. It is rather done by someone who is pretty much closer to the action in real time scenario.

Normal changes do vary in the terms of complexity that they go through in the change management process. Those service changes which are major i.e. which have an impact on multiple divisions inside the organisation would require an exhaustive change proposal along with the RFC and also needs the approval of the IT management board. Those changes which would incur high cost and risk will need to be approved by the business board. Those changes which are of low risks can be approved by the Change Advisory Board (CAB).

The CAB approval process can be sometimes painful and long. However as per ITIL this process can also be performed in an electronic manner and it does state that not all in CAB needs to approve all change.

Cooperation between the CAB and the delivery team is important in order to make the approval process efficient.

Changes which come under emergency procedures may often be due to poor planning but either ways they are unavoidable.

An Emergency service change if not addressed causes service interruption which has high impact or can affect a number of users must be responded to at the earliest.

ITIL framework recognizes the need for IT processes to be swift enough to encounter the demands of business. The ITIL Change Management process hence integrates a procedure for Emergency Change, which can only be raised when a Change is required to fix a high priority IT Incident that is causing a major impact on business operations. 

Benefit Realization in Scrum

Benefit Realization in Scrum

Throughout a Scrum project, it is very important to ensure that intended benefits are being realized as originally planned. Strong benefit realization planning and appropriate verification techniques are required to confirm that the project deliverables with benefits and value are being created by the Scrum team members. This ensures full utilization of project resources. Prototype demonstration and functionality simulation are some of the techniques for confirming benefits and value.

A benefit realization plan helps to forecast contribution of individual project to the overall programme. The plan should be an integral part of any project from start to end. Benefit Realization plan helps to track the sustenance of intended benefits even after the end of a Scrum project.

First step towards benefit realization plan is to identify the intended benefits, stakeholders and the outcomes required followed by measurement of realized benefit, allocation of delivery responsibility, prioritization and identification of delivery dates. Prioritization helps to focus on the benefits with more impact.

Revisiting the Benefit Realization plan at predetermined review points helps the team members to decide whether the changes incorporated are still providing the intended benefits. If the answer is no, then the team should take corrective measures. Consensus of team members and their involvement towards the same output will help the team to move ahead in realizing the desired benefit.

A project manager is responsible for helping the customer gain the desired business benefits. However, the truth is that many successful projects have failed to deliver the desired benefits as planned. Working closely with customers can more clearly determine whether the features are adequate and it helps to make sure that the product gets embedded in the organization. Customers might realize the need for additional features; therefore, the development team should be able to accommodate such changes during product development. Meeting customer expectations and interpreting their requirements are key criteria in realizing benefits. It helps to gain more support from customers and stakeholders.

Some of the techniques and methodologies to confirm benefit realizations are carrying out visual presentation, demonstration of prototypes, workshops and training, arranging product release or launches, accommodating change and being creative in finding problem solutions. Change during such approaches must be sustained even after the end and it leads to realize desired benefits. After delivery of every successful project it is very important to ensure that the product or service that was delivered is used or implemented in the organization.

Agile Fitness Test: Readiness Assessment

While transitioning to Agile, a major mistake that many organizations make is that they are not sure if the organization has the characteristics essential to successfully make this transition. Then once the transition begins, they realise this existing gap and rectifying it at a later stage is extremely difficult.

Hence, any organization before adopting Agile should conduct an Agile Fitness Test, so as to identify if the company is ready to plunge into Agile. This fitness test will broadly cover the following points:

1.       Management Hierarchy: It is important to know if the senior management is ready for a more collaborative style of functioning, which the essence of Agile is. If the management has become too used to deliver orders and expecting them to be followed without any consultation, adapting to the Agile Methodology will prove difficult. Also, if the Power Distance between the hierarchies is high, then consultation, negotiation and collaboration will be tough to practice.

2.       Manager Buy-in: Whether your immediate reporting manager is ready to adopt Agile is extremely important, as basically he becomes more of a facilitator and less of a manager. If the manager’s attitude in this transition process seems to be a concern, it is important to be upfront about it and handle it in the right manner i.e. Get his/her buy in or get someone else in his/her place. For successful transition, this point must be considered carefully.

3.       Developer Buy-in: It has been found that at least initially, the entire team does not participate the way it is supposed to be in Agile. Developers, testers, Business Analysts etc. many of them take a lot of time to adjust to this new methodology. Many of them also don’t see much benefit in providing any feedback or being a part of the planning process. So, they have to be inducted into Agile Mind-set by proper coaching, so that the actual benefits of this methodology can be reaped.

This readiness assessment has to be quantified and input of all the stakeholders in terms of feedback forms has to be analysed to get a clear picture of where the organization stands viz-a-viz Agile adoption. The risks associated with this transition will also be visible in this assessment, and hence the senior management can do a risk vs. benefit analysis to reach a conclusion of whether to adopt agile methodology or stick with the current methodology.

Changes to Sprint in Progress

Scrum is a simple framework which believes in responding quickly to changes in business environment and the ability to respond to changes is one of the reasons that made Scrum popular. The Product Owner is responsible for getting the Product Backlog ready and prioritizing the items in the Product Backlog. The Scrum Master and the development team will use the Product Backlog as the basis for planning the Sprints based on the priority of the items listed.

We could come across situations where the product owner has to decide to add/remove any item from the Product Backlog or change the priority of the items listed in the Product Backlog in the middle of a Sprint. This could be a challenge for the Scrum Master and the Development Team as it would hamper the Sprint in progress, especially changing the priority of the backlog items. Even though Scrum has enough room for responding to change, the mid-sprint alterations should be kept minimal and should not be tolerated unless very badly required. The sprint backlog user stories must not be altered in the middle of a sprint except in the rare scenario something far-reaching emerges that can’t wait until the next sprint.

There are several negative implications on the Scrum team when a mid-sprint change is required. Mostly in such cases, the current Sprint will have to be stopped and a new Sprint will have to be initiated right from the Sprint planning stage. This would affect the morale of the Scrum team and the team will lose its momentum. Also, there will be a great deal of time loss and delay in product delivery. Having said that, if the task is something of top priority and cannot wait till the next sprint, then the team should have the flexibility to include it in the current Sprint if possible or kill the current sprint and start a new sprint. In such cases it’s up to the Scrum Master on how he handles the situation. It has to be noted that adding a new task to the current sprint could cause difficulty in managing the Burn-Down chart.

The Product Owner has an important role in minimizing/avoiding mid-sprint changes to Product Backlog. The PO should have clear visibility and thorough idea about the needs of the customer and the end product he wants. This would help the PO in preparing the Product Backlog meticulously; prioritizing the back-log items accurately and minimize drastic pop-up of business requirements at a later stage.