Can Scrum be used in any type of project and in any industry?

Probably this is one of the most frequently asked questions in relation to implementation of Scrum and still baffles everyone. The old school of Scrum was very apprehensive about Scrum being used beyond software development. No prize in guessing that the inventors and early followers were from software development background and they never thought of taking Scrum beyond their own backyard. The lack of vision in the early adopters hurt the Scrum framework badly. In fact, Scrum was so crippled by this limited mind-set or simplistic vision that after almost 2 decades of its first use, it is still called as an ‘Agile Software Development’ framework and not a generic project management framework. For many years, people graduating (yes, you read it correct) in this framework, are trained to see this through the glass of few selected “so called” experts. It’s like “I am passing my ‘KFC’ secret recipe to you. Damn you, if you try to use other ingredients in my chicken or try to use my secret formula in other recipe.” The vision never grew beyond the backyard.

The philosophy behind Scrum was very powerful and it could have easily become the most efficient and popular project management framework 10 years back. Scrum talks about flexibility and adaptability, but the same ingredients were missing in its very existence. It was largely restricted to software or product development.

Thankfully Scrum has evolved to some extent over the years. The new generation of project managers and many innovative companies have tried to use Scrum philosophies beyond IT software development or product development. Today, we can see people experimenting with Scrum in any kind of projects imaginable with excellent success rate. Of course, following Scrum does not guarantee success in your projects. The key is to proper tailoring of the framework to suit your project need and to execute effectively. In spite of growing success of Scrum projects, until recently there was no unified collaboration to make it a standard best management practice. There are thousands of books on Scrum written by individual authors from their experience but those are mere case studies or memoir of individual experience. Finally, SCRUMstudy tried to came up with a generic, industry agnostic ‘Scrum Body of Knowledge’ by collaborating with several Scrum experts. The SBOK Guide has suggested a structured framework of implementing Scrum in all types of projects across all industries. We are sure the first edition of the SBOK Guide will be far from perfect; but no doubt this noble effort from SCRUMstudy has built the much needed foundation to make Scrum a sought after project management philosophy.

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 <a href="http://www.scrumstudy.com"> Agile process </a> 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.

AGILE PROJECT FEASIBILITY

Feasibility: The big picture

                In this chapter we will be discussing how feasibility fits into the overall agile lifecycle. The agile process is represented by five virtual phases. We use the term virtual because in reality you may perform feasibility, planning, development, or adapting at any point in an agile project. The work is not performed in a serial fashion.

                First is the Feasibility phase. You use this phase to determine if an idea is feasible in going forward with more detailed requirements, planning, funding, and staffing. What is the reason for you in doing this project? What value will this project bring? What are the risks in pursuing this project? The Feasibility phase provides all answers to the above questions.

                The Planning phase gets started by reviewing the output of the Feasibility phase and going deeper into the information provided. You use the Planning phase to break the idea into discrete pieces of functionality called features or user stories. You then prioritize the features and loosely assign them to development iterations.

                The release plan provides a first pass at the work that will be created, tested, and demonstrated during the Development phase. This work is completed in iterations and queued for later deployment. Each iteration is a deliverable subset of features; these features are demonstrated where development iterations end.

                When the team reviews the features that are delivered, they adapt. The team gathers feedback from the customer during the Adapt phase to ensure their needs were satisfied by the features delivered. The team also reviews their velocity (pace) to see if their capacity estimates are correct. The team uses this information to adjust the plan for the forthcoming iteration.

                The last phase is Deployment, which begins after the last iteration is complete. You use this phase to deliver code to the production environment. You also use the Deployment phase to prepare all of those affected by delivery of the project: you train customers, prepare support organizations, turn on marketing plans, and complete the phase with a project retrospective.

                The company management team should initially identify the project based on the selection criteria. After a project has been endorsed for feasibility analysis, you assign an individual or a team to perform the work. The work can be performed by an individual if the idea is simple, such as a slight enhancement to existing functionality. More complicated ideas should be reviewed from various perspectives, and a team is required to provide the analysis.

                First, you must determine what type of team members are needed to do the feasibility work. Second, you need to review the known requirements with the feasibility team and have the members perform research in their respective areas. The feasibility guide focuses the team on the areas they should be researching during the phase.

                When the team feels they’re reaching diminishing returns, or their time limit expires, they will summarize their findings and present them to an approval body. The team will make a recommendation on “go/no go” at the conclusion of the exercise, and the approval body will make the ultimate decision about whether to proceed.

Scrum Ceremony: Daily Stand-up/Daily Scrum

The Daily Scrum meeting is a short, time-boxed meeting (generally 15 minutes) for the team members to communicate their work statuses and their plans for the next 24 hours to the rest of the team. This is done by inspecting the work completed since the last Daily Stand-up Meeting and forecasting the work that could be done before the next one.

One by one, each member of the team reports three (and only three) things to the other members of the team:

1. What did I complete yesterday?

2. What will I complete today?

3. Am I facing any impediments?

The Scrum Master helps team members resolve issues or impediments. The Scrum Master is only a facilitator. The Scrum Master does not run the meeting. The Daily Stand-up Meeting is a forum for information exchange only. Any discussion or issue resolution, if required, takes place after the meeting.

Scrum Ceremony: Sprint Review Meeting

·          At the end of the Sprint, a Sprint Review Meeting is held to review the work completed during the Sprint.

·         The purpose of the Sprint review is for the team to present the Product Owner with the end-deliverable of the Sprint.

·         This is done to demonstrate and validate that the deliverable is done (according to the defined acceptance criteria).

·         It also helps the team get feedback from stakeholders.

·         The outcome of the Sprint review is either the acceptance or rejection of done backlog items by the Product Owner.

·         Items not accepted remain in the Product Backlog.

·         It is the responsibility of the Scrum Master to ensure that the Product Owner does not change requirements or acceptance criteria during the Sprint review and reject a done backlog item because it does not meet the changed requirements. If the requirements have changed, a Product Backlog item needs to be created to address the changed requirements in a future Sprint.

·         Only the product functionalities that adhere to the definition of done can be presented, and WIP functionalities are included in a future Sprint. Team members present the work completed during the Sprint, answer stakeholder questions, and note their suggested changes.

Risk mitigation in Scrum

Scrum is a light-weight framework for project management which is used for complex product development in volatile market conditions. With high competition, companies have to develop products fast and innovatively always adding value and greater customer satisfaction. Quick decision-making and prioritization help mitigate risks in a project. The constant flow of new information changes requirements which Scrum is tailored to handle well and risks are turned into valuable deliverables.

The Product Owner starts the Scrum cycle with identifying requirements of the client through a Stakeholder Meeting. It is up to the Product Owner to clearly outline the customer needs and place them in a Prioritized Product Backlog. Here risk plays a crucial role as it becomes essential to determine high risk elements and place them high in the backlog. The sooner these elements are identified and dealt with in early Sprints the better for the success of the project as the possibility of mitigating larger risks diminish with the progress of the project. Here the Product Owner plays a significant role in discussing various elements with the Scrum team and clarifying doubts. Thus the Product Owner gets a great deal of help from the Scrum Team in prioritizing requirements which the team in turn breaks down into definite User Stories and further into tasks.

The involvement of various stakeholders in the project with the technical personnel makes a mark in risk mitigation in Scrum. The “input-development-feedback” mechanism which is continuous in Scrum keeps everything transparent and pitfalls are readily visible. The Prioritized Product backlog is constantly groomed, i.e. it is analyzed and revaluated all the time as requirements change and/or issues crop up as development of a feature leads to finding a new element which demands immediate attention. Scrum as an Agile framework lets you do exactly that – be agile and incorporate changes in short notices. Scrum’s core principle of Empirical Process Control is thus practiced and upheld. In Scrum, planning is seen as an ongoing process and is represented by grooming of the Product Backlog and the Sprint Planning Meeting at the beginning of every Sprint. Unlike traditional waterfall methodologies where planning is detailed and upfront, this Scrum practice zeroes in on the risk factor. Yet, it is not to be taken for granted as active participation is required by the Product Owner, the Scrum master, and the Scrum Team to keep the mechanism running smoothly. Issues not addressed for long durations may turn into potential risks and take up more time and effort to resolve as time passes.

Some of the Scrum practices which help in mitigating risks are:

1. Flexibility of adding and modifying requirements

2. Regular feedback through the iterative nature of Scrum

3. Team ownership of Sprint Backlog items

4. Transparency ensures detection of risks and early communication

5. Iterative delivery reduces investment risk

In Scrum, it is important to learn and practice its basic principles which collectively and naturally help in effective management of risk.