Question

1. What is an iteration from the agile approach and how does it compare to phases from the traditional software development life cycle?

2. What is team velocity and how does it impact the development of a project?

3. What is the purpose of SCRUM meetings, and how can one best prepare to take part in it?

I would like a very detailed answer, I need to understand the concept of agile very well.

Answer 1

Ans1:

AGILE Software Development

Agile development is based on the idea of incremental and iterative development, in which the phases

within a development life cycle are revisited over and over again. It iteratively improves software by using

customer feedback to converge on solutions.

In agile development, rather than a single large process model that implemented in conventional SDLC,

the development life cycle is divided into smaller parts, called “increments” or “iterations”, in which each of

these increments touches on each of the conventional phases of development. The major factors of agile factors include the following four:

1. Early customer involvement

2. Iterative development

3. Self-organizing teams

4. Adaptation to change

There are currently six methods that are identified as agile development methods, which are Crystal

methodologies, dynamic software development method, feature-driven development, lean software

development, scrum, and extreme programming.

Traditional Software Development

Software methodologies like Waterfall method, V-Model and RUP are called traditional software

development methodologies and these are classified into the heavyweight methodologies. These

methodologies are based on a sequential series of steps like requirements definition, solution building,

testing and deployment. Traditional software development methodologies require defining and documenting

a stable set of requirements at the beginning of a project.

There are four phases which are characteristic of traditional software development method.

The first step is to set up the requirements for the project and determine the length of time it will take to implement the various phases of development while trying to predict any problems that may arise in the project. Once the requirements are laid out, the next step moves into the design and architectural planning phase where a technical infrastructure is produced in the form of diagrams or models. These bring to the surface potential issues that the project may face as it progresses and provide a workable road map for the developers to implement.Once the team is satisfied with the architectural and design plan, the project moves into the development phase where code is produced until the specific goals are reached. Development is often broken down into smaller tasks that are distributed among various teams based on skill. The testing phase often overlaps with the development phase to ensure issues are addressed early on. Once the project nears completion and the developers are close to meeting the project requirements, the customer will become part of the testing and feedback cycle and the project was delivered after the customer satisfy with it.

The traditional software development methods are dependent on a set of predetermined processes and

on-going documentation which is written as the work progresses and guides further development. The

success of a project which is approached in this way relies on knowing all of the requirements before

development begin and means that implementing change during the development lifecycle can be somewhat

problematic. However, it also makes it easier to determine the costs of the project, set a schedule and allocate

resources accordingly.

Difference between Agile and Waterfall Model:

Agile	Waterfall
It separates the project development lifecycle into sprints.	Software development process is divided into distinct phases.
It follows an incremental approach	Waterfall methodology is a sequential design process.
Agile methodology is known for its flexibility.	Waterfall is a structured software development methodology so most times it can be quite rigid.
Agile can be considered as a collection of many different projects.	Software development will be completed as one single project.
Agile is quite a flexible method which allows changes to be made in the project development requirements even if the initial planning has been completed.	There is no scope of changing the requirements once the project development starts.
Agile methodology, follow an iterative development approach because of this planning, development, prototyping and other software development phases may appear more than once.	All the project development phases like designing, development, testing, etc. are completed once in the Waterfall model.
Test plan is reviewed after each sprint	The test plan is rarely discussed during the test phase.
Agile development is a process in which the requirements are expected to change and evolve.	The method is ideal for projects which have definite requirements and changes not at all expected.
In Agile methodology, testing is performed concurrently with software development.	In this methodology, the "Testing" phase comes after the "Build" phase
Agile introduces a product mindset where the software product satisfies needs of its end customers and changes itself as per the customer's demands.	This model shows a project mindset and places its focus completely on accomplishing the project.
Agile methdology works exceptionally well with Time & Materials or non-fixed funding. It may increase stress in fixed-price scenarios.	Reduces risk in the firm fixed price contracts by getting risk agreement at the beginning of the process.
Prefers small but dedicated teams with a high degree of coordination and synchronization.	Team coordination/synchronization is very limited.
Products owner with team prepares requirements just about every day during a project.	Business analysis prepares requirements before the beginning of the project.
Test team can take part in the requirements change without problems.	It is difficult for the test to initiate any change in requirements.
Description of project details can be altered anytime during the SDLC process.	Detail description needs to implement waterfall software development approach.
The Agile Team members are interchangeable, as a result, they work faster. There is also no need for project managers because the projects are managed by the entire team	In the waterfall method, the process is always straightforward so, project manager plays an essential role during every stage of SDLC.

Ans 2: Team Velocity

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

Knowing velocity, the team can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction, even though rarely a precise one.

Velocity can be a very useful predictor of how much work an agile team will complete in the future. It can be especially helpful when looking forward at least four or five iterations.

This is because over the short term, velocity can vary from iteration to iteration. But, velocity is more stable over the long-term as the law of large numbers kicks in and errors in individual product backlog items are balanced out.

We observed the following factors, which can impact the development of a project:

Sprint Length: Some projects may have variable sprint lengths, based on how they operate – this approach may confuse the teams on how much to commit for that sprint. It is a good idea to plan fixed length sprints for consistency by considering their efforts & release expectations.

Estimation approach: Project team needs to decide the estimation techniques used for the entire tenure. Any approach changes in between the project will have an effect on the story point relativity and may affect the scheduling process.

Team Composition: Each team needs to be comprising of all required skill-sets to successfully deliver sprint commitments in a timely manner. Not having required skills on the team may result in dependencies on others and delays. Also, it is not a good idea to change the team members frequently – any change in the team members will have an effect on velocity.

Collaborate to meet Commitments: A very high cooperation among team members and other teams is required to progress the work in a timely manner. Developers and QA need to work very closely to develop and test the work without wasting time. Team members who completed their work, need to help others to finish their work also so that, overall sprint commitments are met. Sprint work is purely a cooperation game!!

Communicate to Clear Barriers: Establishing required communication channels with different stakeholders on the projects will help everyone to collaborate and progress the work. Use every meeting/agile ceremony as an opportunity to notify/identify and clear the barriers. Having right tools to communicate/collaborate is key for success.

Detailed Planning: Detailed planning (breaking the stores in to granular items) helps to understand the scope and efforts better. When user stories are broken in to small pieces that makes the team members job easier to finish one by one quickly to achieve the sprint targets.

Scope changes: Scope of the user stories & the acceptance criteria must be well defined by the time team picks the work. One should avoid changing the scope of the user story in between the sprint, as team may not be able to finish that work. If there is a need to change the scope of majority of the items, it is better to cancel that Sprint. Pushing the teams to do extra work because of scope changes may have side-effects.

Slack time: One needs to consciously plan some slack time in the sprints. Not having any slack time makes the team members focus on their own work only and may not collaborate well. Having Slack time will help the team in generating ideas and finding better ways of doing things, which will eventually help the project.

Technical Debt: Team needs to continuously clear the technical debt on the project to avoid quality issues. Not working on Technical Debt may lead to low quality and hence low team motivation.

Velocity Goals: Setting velocity goals may have side-effects on quality and timelines. One needs to understand that story point estimates are subjective and team knows how much they can commit to.

Comparing Teams: Each team is unique in their own way (experience levels, technical skills, personalities etc.) and they have their speed. We cannot compare two teams on the basis of their velocities and this metric is not meant for that.

Velocity Improvement: A Team’s Velocity improves naturally, based on their understanding of the project, technology and implementation. Each team takes their own time to get into a rhythm and show consistency and improve. All we need to do is, facilitate the required things to the teams to perform better.

Project teams need to find out the most negatively affecting factor on their Team Velocity and try to fine tune that area for positive results.

Ans3: Purpose of SCRUM meetings

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team's level of knowledge. This is a key inspect and adapt meeting.

Scrum meetings are an integral component of a work environment which adopts the Scrum methodology. They are considered to be an invaluable source of collecting information and feedback from the development team and help in keeping the team aligned with the Sprint goals.

Types of Scrum Meetings

Let’s begin by having a look at the types of Scrum meetings. There are 6 types of Scrum meetings which occur at a particular time during a Sprint cycle and each particular type serves a distinct purpose.

1. Sprint Planning Meeting
2. Daily Scrum Meeting
3. Sprint Review Meeting
4. Sprint Retrospective Meeting
5. Backlog Refinement Meeting

Sprint Planning Meeting

At the beginning of every Sprint, Sprint planning meeting is held. Usually, the entire team is expected to be present during this meeting, including the product owner and the Scrum master.

The goal of this meeting is to develop realistic Sprint backlog and define the highest priority tasks which need to be done during the length of each Sprint. The product owner is responsible for explaining the backlog items to the development team and open discussion is expected from both ends to clear all kinds of ambiguities.

During the meeting, team members also communicate the amount of work they can complete in a particular timeframe, so basically, at the end of this meeting, development team comes back with a Sprint goal, as well as a Sprint Backlog.

Daily Scrum Meeting

Daily Scrum meeting, or daily standups – as many people call them, are short 15 minutes meetings which occur on daily basis. They are typically held at the same time and same place every day and are strictly timeboxed to no longer than 15 minutes. This ensures the discussion to stay light, relevant, and quick.

It’s highly imperative that only task-statuses and hindrances are discussed during the daily Scrum meeting and other long planning related discussions are left for some other time.

So, what exactly happens during these short meetings? Well, there’s essentially a three questions agenda which is presented before each team member to get an overview of the task progress. These questions are:

• What did you accomplish yesterday?
• What are you working on today?
• Are there any impediments in your way?

Sprint Review Meeting

At the end of each Sprint, a Sprint Review meeting is held. The core objective of this meeting is to demonstrate the functionality of the product and what has been achieved during a particular Sprint. Generally, product owner, Scrum Master, and other stakeholders are present to review the product.

The product performance is also measured against the original Sprint goals developed during the Sprint planning meeting to oversee any major changes that are there or that are needed to be made.

Sprint Retrospective Meeting

Sprint retrospective meeting- as the name suggests- is solely held with a fundamental purpose of reviewing what went right and wrong during a Sprint. The meeting brings forth a great opportunity for the entire team to reflect back on the work and what improvements are needed to be made.

Retrospective meetings usually require minimum preparation time as they are merely a ‘lesson learned’ type of exercise, with a thorough analysis of what should be done in future.

Backlog Refinement Meeting

The last type of Scrum meetings is the backlog refinement meeting, also known as the product backlog grooming. Mostly, product backlog items need refinement for the next Sprint, to make the team understand them better for successful execution.

In backlog refinement meeting, the backlog items are categorized and prioritized after a technical discussion with the team to make sure that the team understands what exactly are the deliverables and what are the requirements.

Conducting backlog refinement meeting reduces the need for a long Sprint planning meeting and gives the team a chance to reflect on the backlog items before fully committing to the Sprint goals.

How to prepare to take part in scrum meetings?

Define Clear Objectives

Scrum meetings have a tendency to quickly go off the rails if the objectives are not clear. For meetings to stay crisp, yet productive, it’s important to define a clear purpose and objective before the meeting is held.

Most of the times, team members dread unplanned meetings if they’re not told beforehand what the meeting is all about. Therefore, before calling a meeting, identify the type of Scrum meeting it is and inform the team before the intended time.

By following this practice, you ensure that your team members come prepared and time wastage is mitigated to the maximum.

Begin and End on Time

Beginning and ending a particular Scrum meeting on time can put a halt to many other negative outcomes. You need to stick to your schedule no matter who is there to attend the meeting. If you keep waiting for team members to join as they arrive, you’ll lose precious time- and patience of those who arrive on time.

This particular Scrum meeting practice will also invoke a sense of punctuality in your team members the next time they join because it’ll be clear that meetings will always begin and end on time.

Another big no when it comes to Scrum meetings is to not try to fit in every team member’s individual feasibility of attending a meeting, because by doing so, you’ll quickly lose the overall decorum of meeting and you will have to shift the schedule multiple times- thus killing the productivity.

Daily Scrums for Monitoring Progress

The daily standups- for 15 minutes- should serve the intended purpose only, that is, to quickly address the 3 questions agenda and take a quick scan of the overall progress. The daily standups are not meant for rambling of team members- there should be other meetings for that.

Try to strictly contain the discussion in 15 minutes timeframe and make it short. One way to do this is to make sure that the meeting is held while standing up- yes, get rid of the chairs, and ask the team members to stick to the three questions agenda only.

This Scrum meeting best practice shows that daily standups are a highly effective way of monitoring the overall progress of the development work in terms of Sprint goals.

Prepare Scrum Meeting Agenda

This is one of simplest Scrum meeting best practice which helps in increasing the effectiveness of a Scrum meeting. Prepare a meeting agenda before the start of a meeting and share it with the meeting attendees.

Predefined Scrum meeting agenda helps in identifying only those elements which need to be discussed during a meeting, reducing the wandering off from the intended topic of discussion and saves significant time too.

Relevancy with the Sprint Goals

You really don’t want a team that’s mindlessly busy in their work without having any alignment with the Sprint goals. Each day, you have to make sure that each team member is contributing valuable input which is in line with the broader Sprint goals.

Daily standups or daily Scrum meetings are a great way to take regular reports from the team members and help them in reviving the vision if they’re strayed off. Make this a habit during Scrum meetings to ask the team members about how they’re progressing towards the goals rather than how busy they are.

Continuous Improvement

In the end, always strive for better results. Look back at your track record and learn. Mastering the skill of Scrum meetings requires practice and improvement from the last time it was held, so at the end of each type of meeting, sit back and contemplate. Compare the results with the original goals and be mindful of all the changes that are occurring around you, within your team.

This is one of the most effective Scrum meeting best practices because it helps you in evaluating your actions and what you can do to improve them.