Scrum Methodology

What is Scrum?

Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.

• A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
• “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined below. Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic “waterfall” processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals. An agile Scrum process benefits the organization by helping it to

• Increase the quality of the deliverables
• Cope better with change (and expect the changes)
• Provide better estimates while spending less time creating them
• Be more in control of the project schedule and state

 

What are the Activities in Scrum Project Management?

The main activity in Scrum project management is the Sprint, a time boxed iteration that usually lasts between 1-4 weeks, with the most common sprint length being 2 weeks.

• Sprint Planning Meeting: at the start of each sprint a planning meeting is held to discuss the work that is to be done. The product owner and the team meet to discuss the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to complete during the sprint.
• Daily scrum or daily standup: each day during the sprint team members share what they worked on the prior day, will work on today, and identify any impediments. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint. These meetings are time boxed to no more than 15 minutes.
• Sprint Review: at the end of a sprint the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner and any users or other stakeholders who have been invited to the review.
• Sprint Retrospective: at the end of each sprint the team participates in a retrospective meeting to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.

What are the Artifacts in Scrum Project Management?

Scrum Project Management requires very few artifacts, concentrating instead on delivering software that produces business value. The main artifacts in Scrum are:

• Product Backlog: this is a complete list of the functionality that remains to be added to the product. The product backlog is prioritized by the product owner so that the team always works on the most valuable features first.
• Sprint Backlog: this is a prioritized list of tasks the team needs to complete during the sprint.
• Burndown charts: these are used to show the amount of work remaining in a sprint and provide an effective way to determine at a glance whether a sprint is on schedule to have all planned work finished.

 

3 Important Roles on a Scrum team

There are three main roles involved in Scrum project management:

• The Product Owner serves as the customer proxy and is responsible for representing the interests of the stakeholders and ensuring that the product backlog remains prioritized.
• The ScrumMaster is responsible for implementing the Scrum. A ScrumMaster differs from a traditional project manager in many key ways, including that the ScrumMaster does not provide day-to-day direction to the team and does not assign tasks to individuals. A key part of this role is to remove impediments or issues that might slow the team down or stop activity that moves the project forward.
• The Team is made up of a cross-functional group of 5-9 members who are responsible for developing the product. Scrum teams are self-organized will all members collectively responsible for getting the work done.

What You Need to Manage a Scrum Project?

Many teams start out using spreadsheets to manage the product backlog and task boards to see and change the state of tasks during the current sprint, often with a whiteboard and sticky notes. This approach tends to work well for small, co-located teams. However, as the backlog increases and remote members require project visibility many organizations implement a more sophisticated tool to centrally manage projects and enable cross-team collaboration.

one such example of the tool to manage is JIRA. To know more click here.

Tips to Mange Scrum Process in the real world?

• Be dedicated to daily Scrum Meetings :-

Throughout any sprint cycle there will arise seemingly good reasons to cancel the daily Scrum meeting. Don’t fall victim to this temptation. Once you cancel one, it becomes easier to cancel the next … and so on. The daily Scrum meeting is essential to the ongoing success of any sprint as it keeps everyone focused on the deliverable and, perhaps more importantly, keeps everyone committed to the other team members. Even if only a few team members are able to attend on any given day, NEVER cancel a daily Scrum meeting.

• Enlist a strong Scrum Master :-

The Scrum Master (similar to a Project Manager) acts as the day-to-day lead for the team. The Scrum Master schedules meetings, runs the daily standups, removes obstacles that present themselves and ensures the entire team works as effectively as possible throughout each sprint. This person also has a keen sense of the overall dynamic of the personalities of the team, and should be aware that each member is getting the support and tools that they need to perform their job effectively. The Scrum Master also acts as a facilitator for the group to ensure they stay focused in daily stand-ups, reach a consensus on what can be achieved throughout each sprint, and works to keep external distractions at bay so the team can focus on their daily tasks. At the beginning, and end, of each product development process, the strong skillset of the Scrum Master can make or break the success of the entire team.

• Make Scrum and Agile training a high priority :-

Understanding that Scrum is a methodology that was created with very specific processes and goals in mind, training your team on Scrum and Agile development is key to ensure each member understands how to play a role in creating an environment that allows for the most efficient product development. Getting project managers, developers and product owners trained and prepared to dive into Scrum doesn’t have to take a lot of time either.

• Be ready to change and adapt :-

Culture is the number one roadblock hindering every agile transformation. Your training can be top-notch, your team members’ book knowledge of agile processes may be spot on, but if the organizational culture does not change to accept and support a full transition to an agile way of working, the transformation will fail. Set the tone that your company is an Agile development organization that runs on a Scrum methodologies. Show department managers and C-level executives how they can benefit from the Scrum process by having further visibility into product development, allowing for more insight to develop the company strategy. To get things started, invite members of other departments to be a fly on the wall of daily Scrum meetings to get an idea as to how the product team works together.

• Record, Report and Rejoice Results :-

Agile is not just a theory. Its success can be validated. This is important to understand because your initial enthusiasm for what you learn will only carry you so far. To continue putting agile methodologies into practice, you need to be able to see the positive results for yourself. Record what has been achieved during each sprint cycle. Report those achievements to your managers, and the C-level executives who aren’t as involved in the day-to-day process. And remember, even if a sprint didn’t go as planned and several of the goals remain unachieved, a sprint review that leads to actionable steps resulting in more productive future sprints can be considered a viable achievement in its own right. Most of all, rejoice with your team and celebrate their accomplishments. It’s all too easy to get caught up in planning for the next sprint, and then get caught up in the next sprint itself, and to neglect to reflect on all that has been achieved.

Agile process

Agile SDLC model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks and may go upto 4 weeks.

Every iteration involves cross functional teams working simultaneously on various areas like −

• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.

At the end of the iteration, a working product is displayed to the customer and important stakeholders.

 

What is Agile?

Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames) to deliver specific features for a release.

Iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of features; the final build holds all the features required by the customer.

The Agile thought process had started early in the software development and started becoming popular with time due to its flexibility and adaptability.

The most popular Agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now collectively referred to as Agile Methodologies, after the Agile Manifesto was published in 2001.

Following are the Agile Manifesto principles −

• Individuals and interactions − In Agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software − Demo working software is considered the best means of communication with the customers to understand their requirements, instead of just depending on documentation.
• Customer collaboration − As the requirements cannot be gathered completely in the beginning of the project due to various factors, continuous customer interaction is very important to get proper product requirements.
• Responding to change − Agile Development is focused on quick responses to change and continuous development.

 

The above phases may make a developer whose has worked in other development process methodologies difficult to adapt in the beginning. I had worked in waterfall model which i will discuss in some other post. When I started working in Agile it created a lot of problem for me to grasp.

If you haven’t worked on Agile you may also feel the same. But, eventually will adapt to it.

 

Agile Vs Traditional SDLC Models

Agile is based on the adaptive software development methods, whereas the traditional SDLC models like the waterfall model is based on a predictive approach. Predictive teams in the traditional SDLC models usually work with detailed planning and have a complete forecast of the exact tasks and features to be delivered in the next few months or during the product life cycle.

Predictive methods entirely depend on the requirement analysis and planning done in the beginning of cycle. Any changes to be incorporated go through a strict change control management and prioritization.

Agile uses an adaptive approach where there is no detailed planning and there is clarity on future tasks only in respect of what features need to be developed. There is feature driven development and the team adapts to the changing product requirements dynamically. The product is tested very frequently, through the release iterations, minimizing the risk of any major failures in future.

Customer Interaction is the backbone of this Agile methodology, and open communication with minimum documentation are the typical features of Agile development environment. The agile teams work in close collaboration with each other and are most often located in the same geographical location.

 

What are the Pros and Cons of Agile Methodology?

Agile methods are being widely accepted in the software world recently. However, this method may not always be suitable for all products. Here are some pros and cons of the Agile model.

The advantages of the Agile Model are as follows −

• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.

The disadvantages of the Agile Model are as follows −

• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which it will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction.
• There is a very high individual dependency, since there is minimum documentation generated.
• Transfer of technology to new team members may be quite challenging due to lack of documentation.

 

Will discuss the most popular and widely used Agile methodology “The Scrum”. For details click here.

Intro to Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality softwares. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

• SDLC is the acronym of Software Development Life Cycle.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software development process.
• ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.

 

What is SDLC?

SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

 

What are the phases in SDLC?

Following are the steps in SDLC shown in the above diagram:-

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational and technical areas.

Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through an SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS – Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.

Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base.

SDLC Models

There are various software development life cycle models defined and designed which are followed during the software development process. These models are also referred as Software Development Process Models”. Each process model follows a Series of steps unique to its type to ensure success in the process of software development.

Following are the most important and popular SDLC models followed in the industry &miuns;

• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model

Other related methodologies are Agile Model, RAD Model, Rapid Application Development and Prototyping Models.

I will be talking about Agile as this is the most in demand software development process models and its most popular method SCRUM currently being implemented.

To know more click here.