Scrum and Project Management

Scrum and Project Management

A role such as that of a project manager doesn’t exist in Scrum. But, in the organization there are project managers. Then, what is the role of the project manager in the event of the team migrating to Scrum. Well this question has been asked so many times, however the answers are different and are conflicting.

Let’s take up an example to understand this. Mike is a Project Manager and his project is about to migrate to Scrum. From a very long time, Mike is working as a manager in his career. Mike has respected his team mates and trusted them to be responsible about their jobs. His ideology about the finest approach to obtain the outcomes is to develop a team of exceedingly driven professionals, set goals, take initiatives and ensure all needed resources towards their work are there without obstacles. The team looks up to Mike if they have any problems or concerns, as they feel quite at ease intimating project estimates to him because of no “Boss pressure”. He is always careful of their requirements with high importance. It has always been Mike’s goal to enable and support effective communication, prevent and resolve clashes, eliminate obstacles, and make certain maximum prominence into the project for all the involved stakeholders.

Would Mike be a good Scrum Master for his team? Yes, he will be a good Scrum Master.

The product owner is equally vital as the Scrum Master. In the absence of an effective and efficient product owner, the project is unlikely to succeed. Preferably the role of product owner should be undertaken by the client, who isn't always plausible or the client is very engrossed with something that, though formally it is the product owner but whom always finds availability at all times to the team a major inability.

In this situation, there is a necessity for a product owner, or substitution product owner, indigenous to the team. A likely candidate can be the project manager. Interacting and working with numerous stakeholders to convert an incessant flow of change requests into a prioritized list is something the project manager can fare well as he would have prior experience on that.

Risk Identification in Scrum Projects

Risk Identification in Scrum Projects

The objective of the Scrum Team members and the Scrum Master should be to minimize the risk involved in attaining the project objectives, if not to remove it completely. Therefore, the Scrum  Teams and the Scrum Master should spend their time to attempt to identify the potential risks that    impact the project. This can be achieved only by looking at the project from different perspectives,   using a variety of techniques.The following techniques are commonly used by the Scrum Team and 

   the Scrum Master to identify risks.

Risk Identification Techniques:

1.  Review Lessons Learned from Retrospect Sprint or Retrospect Project Processes

Historical data is used to identify and access the risk involved in similar projects previously by the Scrum Team. Learning from similar projects and earlier Sprints in the same project and exploring the uncertainties that affected those projects and Sprints can be a useful way to identify risks.

2.  Risk Checklists

Risk checklist is a valuable tool to help ensure comprehensive risk identification. This checklist includes key points about the risks involved, steps to be followed in identifying the risks, steps to handle the risk and minimize the impact, etc.

3.  Risk Prompt Lists

There are the tools which are used to stimulate the thought about the sources from which risk may arise in a project or when the risk is encountered by the team. These tools are available freely in the market and Scrum Team members can use them to identify the risk during the course of project completion.

4.  Brainstorming

The project experts, stakeholders, Scrum Master and Scrum Team members involve in discussion and share their ideas openly. Each individual idea is picked up and discussed and a consensus is drawn about the risk that may be encountered by the team.

5.  Risk Breakdown Structure (RBS)

The risks are categorised into grouped on the basis of their characteristics like the financial, operational, physical risk etc.  Then strategies are drawn to minimize the impact of each group of risk.

The above techniques are not the final set to identify the risks involved in a project. There are other tools like individual expertise, Expert opinion, etc. to identify the risk which need to be used by the scrum teams to identify the risks so that they are well prepared in advance to minimize the impact the effect of these on the Scrum Projects.

Using waterfall and Scrum with Agile Best Practices

Using waterfall and Scrum with Agile Best Practices

Real-time Testing

Value of Scrum vs. waterfall can be seen in its capability to unravel snags as they transpire. A given set of necessities are being followed in Waterfall projects where testing gets carried out stage at the culmination of projects. Software bugs can be fixed within a three-week development under Agile best practices, thus ensuring serious problems or snags are not faced during the ending stage.

Under the waterfall approach, nothing is sure as to the flaws the project team would need to face, or the severity of those flaws.

Forecasting also becomes enhanced. In the course of iterations involved in a Scrum project, the team can predict more or less about meeting a project target or being unable to meet the project deadline.It helps in dealing with those issues real-time with the involved stake holders in terms of communication in an effective way.

That’s where Scrum or waterfall comes in as to the best approach to for managing the different facets of the project. Figuring out which approach would suit best regarding the various stages of the project – Scrum or waterfall, can impact the project. Waterfall is not responsible for any kind of changes or botches, whereas Scrum is.

Conflict is bound to happen in terms of friction whenever a set defined waterfall plan is broken down in to smaller plans with deadlines, which is actually a sequential methodology and not essentially an agile methodology.

Scrum can go bad even though it was good Scrum

In terms of competency regarding improvement and delivery, Scrum is way ahead of waterfall.

Integrating or linking the iterative pieces collectively from the various Scrum teams also spawns forth problems as different teams may be working on isolated project components which may not be related.

Waterfall methodologies can help to develop forthright architectural design and scope. They are crucial to define the requirements every team member will need to deliver. Thus, it can be integrated with the best practices of agile required in terms of meeting the project's end objectives.

It is highly imperative to have the correct project scope and vision. Having them allows the team to go on to improve features that work in unison with each iteration and the building goes on and on top of one over the other. So, the whole becomes unified at the end.

Characteristics of an organization for easier Agile adoption

Characteristics of an organization for easier Agile adoption

“Embrace the change” is the buzzword everyone is shouting at the top of their voice in every conference and seminars. ‘Follow the Agile process to succeed in your value delivery’ is also very much prevalent across discussions. Once the top management finalizes Agile transition, the entire approach changes dramatically. Hence, not all organizations respond to this change positively. In such scenarios, it will be better to stick to the traditional waterfall model or opt for a customized hybrid model.

Below are some of the desired characteristics of a company for a smoother Agile transition:

Urgency to deliver: Agile is best suited for teams and customers who know their priorities according to market dynamics. When all the features are of same priority, Agile will not be very effective. But when features have to be prioritized according to maximizing value for the customers, with an eye on the criticality and time constraint, Agile is best suited to deliver the highest value.

Volatile Requirements: Unlike waterfall model, wherein requirements are locked before design and development begins, Agile is all about expecting changes and embracing it. This thought process is very practical in nature because market dynamics and competition force your customers to be light footed and nimble. Also, there might be internal conflicts among different stakeholders about which feature should be given higher priority, which can also lead to change in requirements.

Customer Availability: Customers don’t have to be available at all the times, but there are several instances wherein their presence is mandatory. Customers have to provide inputs at the right instances; else the entire effort becomes futile. Also, once customers involve themselves more and more with the projects, they will start to appreciate the effort that is being put in by the delivery team, and they will become more supportive and considerate.

Consistent resources: In traditional method, functionality silos exist. But in Agile, “one team” culture is followed. The primary reason is that Agile teams have a learning curve, and they eventually get better with experience and time. Also, frequently changing resources in an Agile project will mean more effort from the new resource to understand the processes. So, highly motivated individuals are preferred who want to be part of the Agile transition, and as much as practically possible, teams should not be tinkered with.  

So, in case an organization scores high in the above mentioned characteristics, it can be assumed that transition to Agile process will be smooth, rewarding and satisfying.