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.

Comparison between Agile Vs. traditional Project Management

Traditional project management specifically emphasizes on conducting a long and detailed upfront planning for all projects irrespective of whether the requirements are known or not. The long upfront planning is emphasised to ensure fixing the variable like time, cost, scope etc. Lot of time is spent on upfront planning these parameters. In today's fast changing environment, requirements keep changing, and all this upfront planning is wasted if there is a major change in the specification at a later point of time.

While Agile is a general approach used for software development, agile emphasizes on teamwork, frequent deliveries of working software, customer collaboration, and time boxing events and allowing the ability to respond to change quickly.

Scrum is one of most common used form of Agile. Scrum encourages iterative decision making and reduces time spent on unknown variables which are prone to change. Scrum embraces change like no other. Scrum is based on the concept to deliver the greatest amount of value to the customer in the shorted period of time, ensuring a potentially shippable product at the end of each sprint otherwise called iteration.

Traditional project management emphasis on linear processes, comprehensive documentation, spends high time on upfront planning; all requirements prioritization is fixed for the lifetime of the project, and works in managed organization. Traditional project management is adverse to changes and follows a formal change management system. The Return on Investment is after the project is closed and the customer inputs or the involvement in the project may vary depending on the project life cycle.

While Agile Scrum follows an iterative processes and are divided into sprints of shorter span, as agile is more open to changes in the specification, there is less amount of time spent on upfront planning, prioritization of requirements is based on business value and the product backlog is frequently groomed by the product owner. Agile follows self-organized style as individuals are not managed and the organization is de-centralized. Since Agile is split in iterations they pick up small amount of work and rest can be changed and updated to the prioritized. In Agile the Return of Investment is achieved early as release happens in phased and received throughout the project life. The customer involvement in the project is very high as the development work on the concept of customer collaboration.

These are the major differences between a traditional vs agile project management. 

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.