What Makes an Agile Team Success

Before you and your team can crush it, there are certain things you’re going to want to fight for to help set yourselves up for success in agile process to make project run in happy path

Co-location

1.  Dramatically improve the productivity of your team, it would be to have everyone sit together.
2. Co-located teams just work better. Questions get answered fast. Problems are fixed on the spot. There is less friction between interactions.
3. Trust is built more quickly. It’s very hard to compete with the power of a small co-located team.
4. if co-located teams are so good, does that mean if your team is
5. Distributed teams are becoming a way of life for many. And although a
6. tight co-located team will always have an advantage over a distributed one, there are things you can do to close the gap.
7. For one, you can reserve some budget at the beginning of your project to bring everyone together. Even if it’s just for a few days (even better if you can swing a couple weeks), that time spent getting to know each other, joking around, and eating together goes a long way in turning your ragtag bunch into a tight, high-performing team. So, try to bring everyone together at the start.
8. every communication tool and trick in the book
9. team seem like a co-located one even though you’re not.

Engaged Customers

1. There is a lot of software that still gets written today by teams that don’t have engaged customers. It’s sad, and it ought to be a crime.
2. How can teams be expected to build compelling, innovative products if the very people they are building them for aren’t part of the process?
3. Engaged customers are those who show up to demos, answer questions, give feedback, and provide the guidance and insight necessary for the team to build compelling software. They are core members of the team and full-on partners during delivery

Self-Organizing

1. Agile teams like to be given a goal and then have everyone stand back as they collectively figure out how to get there. To do that, agile teams need to be able to self-organize.
2. Self-organization is about checking your ego at the door and work  with your team to figure out how you as a team (with all your unique skills, passions, and talents) can best deliver this project

Accountable and Empowered

A good agile team will always want to be held accountable for the results they produce. They know customers are counting on them to come through, and they won’t shirk from the responsibility that comes with having to deliver value from day one

Cross-Functional

A cross-functional team is one that can serve their customer from end to end. That means having the necessary skills and expertise on your team to take any feature your customer would need and be able to

deliver it fully.

Comparing Agile Methodologies

Purpose of this post is to  compare  different Agile methodologies and compare their respective strengths and weaknesses.

Scrum

Strengths

1. Can be used together with an existing practice
2. Accommodates feedback opportunities in teams that are self-motivated
3. Supports customer involvement and direction
4. Focuses on the business value of a project
5. Contains a certification process

Weaknesses

1. The only process supported is project management
2. No technical practices are defined
3. Time-consuming, especially when customizing priorities for requirements

DSDM

Strengths

1. Demands a high level of testing – a minimum of one tester is required on every team
2. Focus is on business value
3. Clearly defines the importance of every requirement in an iteration
4. Stakeholder expectations defined at the start of every project – specifies that every requirement may not be able to be fulfilled

Weaknesses

1. Very heavyweight and demanding
2. High level of user involvement required
3. Requires a high level of documentation and specifies various work products for every project phase
4. Reference material monitored by a consortium – fees are charged to access resources

XP

Strengths

1. Requires rigid technical practices
2. Estimates owned by develops
3. Features owned by customers
4. Supports regular feedback sessions
5. Popular, especially in the US

Weaknesses

1. Customers needed onsite
2. Minimal record keeping - Verbal communication and code are used to document feedback and progress
3. New users may find this method difficult to understand in terms of software architecture and design

Lean

Strength

1. Can be used together with an existing practice
2. Main objective is the project ROI.
3. Keeps project waste to a minimum
4. Supports cross-functional teams

Weaknesses

1. No technical practices are defined
2. Metrics collecting is constant
3. Theory of Constraints can be difficult to understand and implement

AUP

Strengths

1. Contains multiple artifacts and disciplines
2. Can be adapted to large projects
3. Supports a distributed team environment by using good documentation practices
4. Bases priorities on levels of risk

Weaknesses

1. Too many guidelines can slow project progress
2. Team dynamics are neglected
3. Documentation is very formal

FDD

Strengths

1. Accommodates the need for multiple teams
2. Monitors all project elements according to its features
3. Contains design by feature and build by feature aspects that are simple to implement
4. Can be adapted to suit large teams and projects

Weaknesses

1. Does not support shared or team ownership of code; rather, individual code ownership is encouraged
2. Iterations are poorly defined
3. Model-centric aspects can impact systems if no models are in place

Crystal

Strengths

1. Can be scaled according to project size and criticality
2. Supports life critical projects
3. Cross-functional teams created in proportion to the project size
4. Considers the "human" element of the project support structure
5. Demands a high level of testing – a minimum of one tester is required on every team

Weaknesses

1. Each project has to be tailored individually, according to its size and structure in order to fulfil Crystals requirements for that particular type of project
2. Does not support adaptations mid-project – not upward or downward compatible

What Is Agile?

“Agile” is a collective term for methodologies (and practices) that have emerged over the past two decades to increase the relevance, quality, flexibility and business value of software solutions. These adaptive management approaches are specifically intended to address the problems that have historically plagued software development and service delivery activities in the IT industry – including budget overruns, missed deadlines, low-quality outputs, and dissatisfied users.

Although there is a broad range of Agile methodologies in the IT industry – from software development and project delivery approaches to strategies for software maintenance – all Agile methodologies share the same basic objectives:

• To replace upfront planning with incremental planning that adapts to the most current information available (i.e. the “apply, inspect, adapt” mindset)
• To build in quality upfront and then relentlessly confirm the integrity of the solution throughout the process
• To address technical risks as early in the process as possible to reduce the potential for these resulting in cost and time blowouts as the project progresses
• To minimize the impact of changing requirements by providing a low overhead structure to accommodate variations to the originally-identified requirements throughout the project
• To deliver frequent and continuous business value to the organization by focusing staff on regularly delivering the highest-priority features in the solution as fully functional, fully tested, production-ready capabilities
• To entrust and empower staff to continuously deliver high business-value outputs
• To encourage ongoing communication between the business areas and project team members to increase the relevance, usability, quality and acceptance of delivered solutions.

Agile methodologies are common-sense approaches for applying the finite resources of an organization to continuously deliver low-risk, high business-value software solutions

Traditional PM Methods Vs Agile PM Methods

Traditional Project Management

1. Detailed and rigid planning with formal and controlled change procedures.
2. Formal task breakdown and allocation, may not be adaptable.
3. Human resources can be changed easily which might lead to morale issues.
4. Command and control leadership style.
5. Upfront stakeholder and scope identification which increases the cost of change.

Agile Project Management :

1. “Plans are nothing, planning is everything.” - Dwight D. Eisenhower
2. Collaborative and prioritized task breakdown.
3. Self-organizing, empowered, cross-functional, cohesive teams leading to high morale.
4. Servant leadership style. Empowering, guiding, coaching.
5. High team-stakeholder involvement and focus always on the most important scope needed now.

Twelve Principles of Agile Software

1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4.Business people and developers must work together daily throughout the project.
5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile Software Development

1. Empirical and adaptive.
2. Iterative and incremental.
3. Just-enough planning.
4. Just-enough development.
5. Adaptable to scope changes.
6. Collaborative and whole-team.
7. User centric.
8. Value driven.

7 Wastes in Software Development

1. Partially Done Work.
2. Extra Features.
3. Relearning.
4. Handoffs.
5. Delays.
6. Task Switching.
7. Defects.

Planning Poker in Scrum

1. A Moderator, who will not play, chairs the meeting.
2. The Product Owner provides a short overview.
3. The team asks questions and clarifies assumptions and risks.
4. A summary of the discussion is recorded by the Project Manager.
5. Each individual lays a card face down representing their estimate.
6. Everyone calls their cards simultaneously by turning them over.
7. People with high estimates and low estimates are given a time box to offer their justification for their estimate and then discussion continues.
8. Repeat this process until a consensus is reached.

 Planning Poker is a fast, card based approach to team estimation. Team members are given cards with the numbers 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 on them to represent development effort estimates.

User stories are presented to the team and discussed as a group to round out understanding, Then everyone selects a card that represents their estimated effort for the development. The cards are kept private until everyone has selected a card and then they are all revealed together.

If the resulting estimates are close then it is safe to record the estimate and move onto the next story. If there is significant divergence then people are invited to discuss why they believe it will be so different (for example last time we added a column to the account table it took 8hrs to regression test the legacy applications). Then in light of this new information people estimate again, as before only revealing their cards when everyone has selected a card. The process iterates until sufficient consensus has been reached.

Planning Poker takes the group based consensus building and anonymous estimating concepts of Wideband Delphi estimation and packages them in a faster, more enjoyable format. 

Steps to Successful Story Point Estimation

1. Identify base stories.
2. Talk through the requirements of the story.
3. Discuss and jot down things you want to remember when implementing this story.
4. Some of these questions team ask themselves when they start sizing.
5. Find some point of relative comparison.
6. Reach a consensus among entire team present as to the size of the story as per definition of done.
7. Validate that your estimates are internally consistent among stories as you go along.
8. Periodically ensure that all of the 1′s are about the same, all of the 2′s match, etc.

Scurm Estimation using Story Points

1. An abstract number to measure size of a feature.
2. Does not mean anything in isolation, but conveys relative size of features when compared.
3. Different teams size-up the same features differently but the relative measures between features might be the same.
4. Fibonacci series preferred as story points: 1, 2, 3, 5, 8, 13, 21, …
5. Geometric series also preferred: 1, 2, 4, 8, 16, 32, …

Story point estimation allows us to:

1. Rapidly estimate long-term product backlogs without requiring detailed specifications and complicated dependency charting
2. Provide broader insight from diverse functional experts (which offers checks and balances and less point sensitivity) to ensure that estimates aren’t being padded nor under-baked
3. Ensure that the entire ‘brains trust’ of the team is able to understand and assess the merits of the requirements, allowing for early detection of any potential issues as well as areas for improvement
4. Leverage the knowledge gained from completing legacy work
5. Actually have some fun whilst conducting a traditionally mundane and frustrating task. Planning Poker sessions are interactive, lively and much faster than traditional estimation marathons
6. Sound pretty snazzy as talking about your ‘team velocity’ is way more exciting than mumbling something about your ‘team rate of progress’ – ok maybe leave that one out…

The Sprint Planning Meeting – Warnings

1. The product owner does not attend the meeting.
2. The scrum master does not attend the meeting.
3. A major part of the team is missing from the meeting.
4. The product backlog is not prioritized or groomed.
5. Other stakeholders are part of this meeting and prioritizing activities.
6. The Sprint goal is vague.
7. Team doesn’t estimate even the top priority user-story into tasks.
8. The scrum master and/or product owner are deciding tasks taken into sprint backlog.
9. The scrum master and/or product owner are doing the estimates.
10. Meeting does not get over in the specified time-box.

Agile Estimation Basics

1. Traditional PM methods estimate by activities – Break the scope into activities, estimate the duration of activity, add them up.
2. Agile PM methods estimate by features – First estimate size of features, then estimate duration of features.
3. Estimation of size happens as early and as often as possible.
4. Estimation of duration happens as late and as often as possible.
5. Always be a whole-team activity.
6. Estimates of size: User story or ideal days.
7. Estimate of Duration = [sum of all user stories or all ideal days] / [velocity]

Velocity in Scrum

velocity is the amount of work that a team can complete in a specified period of time.

The "amount of work" is the total number of story points if the team estimates by size, or the total number of "ideal hours spent on tasks. All acceptance criteria must be met in order for a story to be considered complete. The "specified period of time" is usually an iteration between one and four weeks long.

Velocity is simply work divided by time — story points per iteration or ideal hours per iteration.

Velocity is a measurement of how much the team gets done in an iteration ( called as Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned.

In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Highlight points for Velocity in scrum

1. Velocity = [Total number of story points moved to ‘done’ in a sprint].
2.  Product owner identifies a user-story as ‘done’/’not done’ during sprint review.A metric to measure of the Scrum team’s rate of progress.
3. Velocity is calculated at the end of every Sprint after Sprint review.
4. Velocity for a team improves over time based on closing the continuous improvement areas identified in Sprint retrospective.

User Story in Agile

User stories are used with Agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.)

1. A user story represents a value adding requirement of the product.
2. Contract between development team and PO that discussion will take place before implementation.
3. This usually follows the following template:"As a <user type> I want to <do some action> so that <desired value added result>“.
4. INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable.
5. Implemented by a development team in one sprint.
6. User stories are Complemented by with conditions of satisfaction.

User stories Vs Use Cases

User stories

1. Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.
2. Must be accompanied by Acceptance Testing procedures (acceptance criteria) for clarification of behaviour where stories appear ambiguous

Use Cases

1. Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
2. May be delivered in a stand-alone document.

Burn-up chart

• A chart displaying the current progress of the sprint and estimated time to burn down the complete product backlog.
• Displays the value earned through all Sprints.
• X-axis is the iterations since start of the project.
• Y-axis is the total ‘done’ effort.
• The green line is the total scope. The dashed line extrapolates the estimated total scope.
• The red line is the total scope ‘done’ for each iteration. The dashed line extrapolates the estimated time required to burn down entire scope based on Scrum team’s current velocity.

Sprint Burndown chart

By reviewing a sprint burn down report, you can track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.

Burn down chart displays the remaining effort for a given period of time.

When they track product development using the Burn down chart, teams can use a sprint Burn down chart and a release Burn down chart. This article concentrates on the sprint Burn down chart as it is used on daily basis.

Sprint Burn down Chart

• A chart displaying the current progress of the sprint.
• Displays the remaining work in the current Sprint.
• Updated by the development team everyday.
• X-axis is the days remaining in the Sprint.
• Y-axis is the total estimated effort remaining to get the tasks identified for the Sprint to done.
• Green line is the ideal Burndown based on number of hours committed to in the Sprint.
• Red line is the daily estimations of remaining work updated by development team daily.

Definition of Done (DoD) in Agile

 Done Done means the coding is done, it’s been tested, installers and deployment packages have been created, user manuals have been updated, architecture docs have been updated, etc.

1. A transparent exit criteria to decide whether an item in the product backlog is completely implemented.
2. An input for the development team to decide how much work it can commit to deliver in a sprint.
3. As the scrum team matures the exit-criteria become more strict.

Actually done means to finish below all mentioned activity :

Column One

User Story Clarity
User stories selected for the sprint are complete with respect to product theme, understood by the team, and have been validated by the detailed acceptance criteria.

Tasks Identified
Tasks for selected user stories have been identified and estimated by the team.

Build and package changes 
Build and package changes have been communicated to the build master. These changes have been implemented, tested and documented to ensure that they cover the features of the sprint.

Product owner approval
Each finished user story has been passed through UAT (User Acceptance Testing) and signed off as meeting requirements

Updating Product Backlog
All features not done during the sprint are added back to the product backlog. All incidents/defects not handled during the sprint are added to the product backlog.

Column Two

Environment ready

• Development environment is ready with all third-party tools configured.
• Staging environment is ready.
• Continuous integration framework is in place. The build engine is configured to schedule hourly, nightly, and release builds.
• Desired build automation is in place. Why "desired"? Because there is no end to build automation :)
• Test data for the selected features has been created

Design complete
Design analysis is complete as per the user story or theme. UML diagrams are either created or updated for the feature under development.

You might need to prototype various components to ensure that they work together.  Wireframes and prototype have been created and approved by the respective stakeholders.

Unit test cases written
Unit test cases have been written for the features to be developed.

Documentation Ready
Documentation (Just enough or whatever the team agrees to) to support the sprint demo is ready

Pre-Release builds 
Pre release builds (hourly/nightly) have been happening and nightly build reports have been published on regular basis.
The following could/should be part of pre-release builds:

1. Compile and execute unit test cases (mandatory)
2. Creation of cross reference of source code
3. Execution of automated code reviews for verification of coding rules
4. Code coverage reports are generated
5. Detection of duplicate source code
6. Dependency analysis and generation of design quality matrix (static analysis, cyclomatic complexity)
7. Auto deployment in staging environment
8. It comes down to build automation; there is no end to what can be achieved from automated hourly, nightly builds. The team along with the product owner needs to decide on how much build automation is required.

Column Three

Code Complete
Source code changes are done for all the features in the “to do” list.” Source code has been commented appropriately.

Unit testing is done
Unit test cases have been executed and are working successfully

Code Refactoring
Source code has been refactored to make it comprehensive, maintainable and, amenable to change.

A common mistake is to not keep refactoring in the definition of done. If not taken seriously, refactoring normally spills out to next sprint or, worse, is completely ignored.

Code checkin 

1. Source code is checked in the code library with appropriate comments added.
2. If project is using tools which help in maintaining traceability between user stories and the respective source code, proper checkin guidelines are followed.

Code merging and tagging
Finalized source code has been merged with the main branch and tagged appropriately (merging and tagging guidelines are to be used)

Column Four

Automated Code reviews
Automated code review has been completed using the supported tools/technologies. Violations have been shared with the team and the team has resolved all discrepancies to adhere to the coding standard. (Automated code reviews should be hooked up with CI builds.)

Peer reviews
Peer reviews are done. If pair programming is used, a separate peer review session might not be required.

Code coverage is achieved
Code coverage records for each package are available and whatever the team has decided as the minimum benchmark is achieved.

Project metrics are ready
Burndown chart has been updated regularly and is up to date.

Release Build

1. Build and packaging
2. A Build (successful) is done using continuous integration framework. Change log report has been generated from Code Library and Release notes have been created. Deliverables have been moved to release area.
3. Build deployment in staging environment
4. Build deliverables are deployed in staging environment. If it is easy, this step should be automated.

Column Five

Functional testing done
Automated testing
All types of automated test cases have been executed and a test report has been generated. All incidents/defects are reported.
Manual testing
Quality assurance team has reviewed the reports generated from automation testing and conducted necessary manual test cases to ensure that tests are passing. All incidents/defects are reported.
Build issues
If any integration or build issues are found, the necessary steps are repeated and respective “Done” points are adhered to.
Regression testing done
Regression testing is done to ensure that defects have not been introduced in the unchanged area of the software.
Performance testing done
A common mistake is to not keep performance testing in the definition of done. This is an important aspect. Most performance issues are design issues and are hard to fix at a later stage.
Acceptance testing done
Each finished user story has been passed through UAT (User Acceptance Testing) and signed off as meeting requirements (see also Product Owner Approval).
Closure
All finished user stories/tasks are marked complete/resolved. Remaining hours for task set to zero before closing the task.

The Sprint Backlog

1.  This is a forecast given by the development team as to what functionality will be done in the next increment and how it will be delivered.
2. Contains a set of product backlog items identified for a Sprint and the tasks needed to get those items to done.
3. Tasks are estimated in hours.
4. This is a dynamic document evolving throughout the Sprint.
5. Development team updates the backlog as it works through the plan and understands more the work needed to be done.
6. New work is estimated and added to the backlog by development team.
7. Estimations for remaining work is updated by development team.

9 Tips for Creating a Good Sprint Backlog:

1. Involve every team member in the process.
2. Discuss how every item should be implemented.
3. Have a definition of done.
4. Identify all kinds of tasks.
5. Don't estimate tasks at all. 
6. Don't assign tasks up front
7. Review the sprint commitment. 
8. Don't use too much time.
9. Evolve the Sprint Backlog during the sprint.

The Product Backlog

1. The single source of requirements for the product.
2. Prioritized list of requirements arranged as value-creating user stories ordered by business value.
3. The user-stories nearer the top are clear and detailed than those below.
4. User-stories taken into sprint backlog are fine-grained enough to be done in a Sprint.
5. User-stories at the bottom are usually vague in scope. They are called Epics (fairly vague ideas) or Themes (extremely vague ideas).
6. This document exists and evolves all through the product’s lifetime.
7. Editable by anyone but owned and prioritized by Product Owner.

"The product backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product."

At its core, the product backlog is an ordered list of items that is managed by a person with the ability to understand the business’ needs.

The product backlog is used to:

capture requests for modifying a product.  This can include add new features, replacing old features, removing features and fixing issues; and ensure the delivery team is given work which maximizes the business benefit to the owner of the product

Artifacts in the Scrum Framework

List of Artifacts in the Scrum  Framework

1. The Product Backlog
2. The Sprint Backlog
3. The Increment

Product Backlog :

The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of easily. This agile backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

Sprint Backlog :

The Sprint Backlog consists of the necessary tasks to realize the final accepted a version of the Selected Product Backlog. The team uses it to synchronize its activities. The tasks turn the Selected Product Backlog into working product functionality.

Increment:

Increment = [all backlog items done in this sprint ] + [increments done in all previous sprints]

An increment must always be in “done” and usable condition.

Sprint Retrospective Meeting

1. Meeting for scrum team to retrospective on how the Sprint went with respect people, process and tools.
2. Team identifies what went well and what can be improved.
3. Team identifies a plan to implement identified improvements.
4. Other stakeholders are not allowed.
5. An opportunity for the team to make continuous improvements.
6. Maximum time box of 3 hours for a 4 week Sprint

The Sprint Retrospective Meeting - Warnings

1. The retrospective meeting is not conducted.
2. Identified improvements are not followed up with actions.
3. The scrum master or/and development team does not attend.
4. Other stakeholders are not allowed.
5. Maximum time box of 3 hours for a 4 week Sprint.

What is Sprint Retrospective?
Each Sprint in Scrum has to a meeting – Sprint Retrospective at the end. It is very essential that the Scrum Master never allows the team to skip these meetings. These meetings uplift Inspect and Adapt principles of Scrum and help the product to be better and better after each Sprint.

Team along with Scrum Master asks 2 questions:

• What went well in last sprint?
• What could be improved in next sprints?

  Rules for Sprint Retrospective ?

1. Ensure that everyone can speak freely.
2. Sprint retrospective meeting is not the place for advocating ones personal agenda.
3. Do not play the blame game.
4. Do not allow vague statements.
5. Transform identified improvements to concrete action points.

Key elements of the Sprint Retrospective are:

• Process improvements are made at end of every Sprint - ensures that the project team is always improving the way it works.
• The Retrospective is a collaborative process between all members of the Team, the Product Owner, and the Scrum Master.
• All team members identify what went well and what can be improved
• Scrum Master prioritises actions and lessons learnt based on Team direction
• Team devises solution to most vexing problems - helps to build the team ownership and self management.
• Helps the team formation and bonding as any areas of conflict can be identified and dealt with.

The Sprint Review Meeting

1. Meeting held to demo the increment delivered by development team.
2. Dev team demos all items it has “done” and clarifies queries about it.
3. Everyone is invited. PO and all stakeholders see the demo.
4. PO confirms on what is “done” and what is “not done” in the increment.
5. PO discusses the product backlog at that point. Everyone discuss on what has been achieved and what to do next. Product backlog is revised as needed.
6. Maximum time box of 4 hours for a 4 week Sprint

The Sprint Review Meeting - Warnings

1. Product Owner does not attend the sprint review meeting.
2. Dev team demos what it has done in a simulated environment rather than actual production environment.
3. Members from the development team skip the demo.
4. Demo is shown on code from development environment rather than production environment.

The Daily Scrum Meeting - Warnings

1. The Scrum Master does not ensure that the daily Scrum is conducted.
2. The development team does not show interest in attending the meeting.
3. The development team members speak to the scrum master / product owner / another manager rather than addressing the team.
4. Team members tend to solve the problems raised in the meeting then and there.
5. Meeting extends beyond 15 minutes.
6. Managers tend to take over the meeting and direct discussions.

What Is Agile?

First, what does agile really mean?  It’s not considered a methodology, a process, or even a set of procedures.  It’s more of a conceptual development framework which allows our team to iteratively prioritize & plan the work, perform the work, and review the work.  As opposed to the classic waterfall approach, agile acknowledges that we don’t have all the answers at the start of a project. 

1. Agile value individuals and interactions over processes and tools.
2. Agile value working software [or any product] over comprehensive documentation.
3. Agile value customer collaboration over contract negotiation.
4. Agile value responding to change over following a plan.

The Daily Scrum Meeting

1. Daily synchronization and planning meeting.
2. Time box is 15 minutes maximum.
3. Held at same place and time everyday.
4. Open to all but only development team can talk in the meeting.
5. Others can only observe.
6. Not a problem solving meeting.

Each team member answers these 3 questions:

1. What was accomplished since last meeting?
2. What will be done before the next meeting?
3. What impediments are blocking this?

Daily Scrum Meeting Rules

1. Hold the Daily Scrum in the same place at the same time every work day. The best time for the meeting is first thing in the day so that Team members think about what they did the day before and what they plan to do today.
2. All Team members are required to attend. If for some reason a Team member can't attend in person, the absent member must either attend by telephone or by having another Team member report on their status.
3. Team members must be prompt. The ScrumMaster starts the meeting at the appointed time, regardless of who is present. Any members who are late pay a fine that is donated to a worthy charity!
4. The ScrumMaster begins the meeting by starting with the person immediately to his or her left and proceeding counter clockwise around the room until everyone has spoken.
5. Each Team member should respond to the following questions:
6. What have you done since the last Daily Scrum regarding this project?
7. What will you do between now and the next Daily Scrum meeting regarding this project?
8. What impedes you from performing your work as effectively as possible?
9. Team members should not digress beyond answering these three questions into issues, designs, discussions of problems, or gossip. The ScrumMaster is responsible for moving the meeting along briskly from person to person.
10. Team members should address the Team. This is not a "Reporting to the ScrumMaster" meeting.
11. During the meeting only one person talks at a time. Everyone else listens without any side conversations
12. Chickens (non Team members) are welcome to attend the Daily Scrum Meetings but they are not allowed to talk, make observations, make faces or otherwise make their presence in the meeting obtrusive.
13. Chickens stand on the periphery of the Team so as not to interfere with the meeting.
14. If too many chickens attend the meeting, the ScrumMaster can limit attendance so that the meeting can remain orderly and focused.
15. Pigs or chickens who cannot or will not conform to the above rules can be excluded from the meeting (chickens) or removed from the Team (pigs).

The Sprint Planning Meeting

Who, What, When, Where, Why
The Sprint Planning Meeting is attended by the product owner, Scrum Master, and the entire Scrum Team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.

Two defined artifacts that result from a sprint planning meeting:

A sprint goal

A sprint backlog

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. The following are typical sprint goals on an eCommerce application:

There are two parts in Sprint Planning Meeting

Part 1 – Prioritization 

What needs to be done by the end of this upcoming Sprint?

1. PO presents the ordered backlog items to the team.
2. Team discusses and understands the work for this Sprint.
3. Team forecasts and commits on the items that can be done.
4. Team creates the Sprint Goal for this Sprint.

Part 2 – Planning How will the chosen work get to done?

The output of the second planning meeting will be the Sprint Backlog.

1. Team arrives at the plan to get the items to done in a Sprint Backlog.
2. Team arrives at a design and work needed to achieve the Sprint goal.

The Sprint – 6 Early Warning Signs

1. The goal of the Sprint explicitly changes during the Sprint.
2. Certain changes are done that cause goal to change during the Sprint.
3. Team composition is changed during the Sprint.
4. Definition of done is changed during the Sprint.
5. Sprint duration extends beyond the agreed time-box.
6. Sprint duration is agreed to be beyond a month.

Meetings keep getting longer and there are too many of them.

If  daily standups are getting longer and longer, watch out. Something is going wrong. The team may be losing focus or getting off track. If more and more meetings are being scheduled to resolve issues, the team is likely to be struggling.

These are early warning signs of trouble. Pay attention. Keep to the 15-minute time limit for standups and use informal discussions rather than formal meetings whenever possible.

2. The team follows a hierarchy and seeks approval before acting.

At times teams will establish one or more hierarchies. For example, there may be an acknowledged system architect, a keeper of the build, or a quality guardian. It’s fine to have designated subject matter experts (SME). Problems develop when the team stops and waits for SME approval. The SME quickly becomes a bottleneck, slowing the team down.

If there is a SME on the team, that person should guide the team not look over everyone’s shoulders. A SME that is protective of his territory will only hurt the team.

3. The team keeps getting bigger.

Sometimes agile teams will add people to try and do more in less time. The strategy can work if there is enough time left in the plan for the newcomer to have a meaningful impact.

Management may conclude that if adding one more person helped, why not add another? And another? Maybe the underlying problems that are causing the team to appear understaffed should be fixed. If the team gets too large, consider splitting it into two autonomous teams.

4. Deadlines are missed and sprints are lengthened.

One solution to the problem of missing sprint deadlines is to make the sprints longer, right? It sounds reasonable but if the team is having trouble planning and executing short sprints, it will only get tougher to manage longer ones.

Missed deadlines are a symptom. There are many possible causes of the underlying problem. The key point is that if deadlines are missed, you need to dig deep and understand why.

5. The team gets bogged down in documentation and becomes resistance to change

At times, some people new to agile development may be uncomfortable with a lightweight agile approach. They may attempt to make up for that by ‘writing things down’ and trying to control change. This may also result in each sprint decomposing into analysis, design, code and test segments.

Retrospectives can help.

Scrum Sprint

Events in the Scrum Framework
Sprint = [ Sprint planning meeting + Daily Scrum +Development work + Sprint review + Sprint retrospective ]
Time-box of less than a month when team gets to “Done” a potentially shippable product increment.•Each Sprint contains:

1. A goal.
2. A design and plan to reach the goal.
3. The work done to achieve the goal.
4. The product increment.

The Sprint Cycle

Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria needs to be met for the work to be approved and accepted.

The duration of a sprint is determined by the scrum master, the team's facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts 30 days.

After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The project owner may attend these meetings as an observer but is not allowed to participate unless it is to answer questions. (See pigs and chickens). The project owner may not make requests for changes during a sprint and only the scrum master has the power to interrupt or stop the sprint.

At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.

The Development Team Roles

Responsible for:

1. Delivering potentially shippable product increments at the end of each Sprint.
2. Doing the actual work in the Sprint.

Accountable for:

1. Quality of the deliverables.

Dev Team's Role

Self-organizing, cross-functional and fully available team of 3-9 persons.

1.They are not a part of line management. There will be very few members from the management ranks but the majority of the team will be "doers." The people that actually design, build, create, and test the code. This will add to the credibility as the methodology is rolled out to the company. It is not a management initiative being forced upon everyone; it is coming from real people who will be a part of the project teams.

2. Since the team is composed of doers they actually know the ins and outs of developing in your environment. This is different than when consultants come in suggesting standard practices and disregarding the realities of a specific company. The Agile Core Team has experience with your company and they will use that experience to develop a methodology that knows what to keep and what to discard within the existing practices.

3. Remember our earlier discussion of awareness, buy-in, and ownership? What better way to create awareness than to have Agile Core Team members come from each functional area. Imagine a member being from quality and going back to the quality team and telling them what is going on with the new methodology, or a developer doing the same with the development team. Having team members from all areas will initialize awareness across the company.

The Scrum Master – Do's and Dint's

Do's

1. Every Scrum team must have one Scrum Master.
2. The Scrum Master should be highly available to the team.
3. The Scrum Master should be an expert in Scrum and organization’s practices.
4. The Scrum Master should motivate the team to try and adapt Scrum.

Dint's:

1. A product owner is also the Scrum Master.
2. The Scrum Master agrees to every distraction from the PO and the management during a Sprint hampering the team’s focus.
3. The Scrum Master does not conduct the daily Scrum meeting.

The Scrum Master’s Services

Scrum Master to DEV and QA Team :

1. Is cross-functional
2. Is right-sized (the ideal size is seven -- plus/minus two -- members)
3. Selects the sprint goal and specifies work results
4. Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal
5. Organizes itself and its work
6. Demos work results to the product owner and any other interested parties.
7. Ensures that the team is fully functional and productive
8. Enables close cooperation across all roles and functions
9. Removes barriers
10. Shields the team from external interferences
11. Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
12. Facilitates the daily scrums

Scrum Master to Product Owner

1. Aids effective backlog management.
2. Facilitates Scrum events as needed.
3. Aids in the PO understanding and practising agility.

Scrum Master to Organization

1. Leads and coaches Scrum adoption and empirical development.
2. Impact s processes improving team’s productivity.
3. Increases Scrum’s effectiveness across

Scrum Master to Development Team

1. Coaches, even in environments where Scrum is not fully implemented.
2. Leads team to high value deliveries.
3. Removes impediments to team’s progress.

The Scrum Master Roles

Scrum Master Represents the management to the team.
The Scrum Master Role Responsible for:

1. Protecting the team from distractions and focusing it on the goal of the Sprint.
2. Ensuring that the Scrum process is followed as intended by the team.
3. Ensuring complete cooperation between all roles and functions in the organization and the team.

The Scrum Master Role Accountable for:

• Removing impediments preventing the team from delivering value.

The Scrum Master Role Consulted for:

1. Any impediments hampering the team.
2. Any doubts with the Scrum process and its interpretation.
3. Owner of the process and practices followed by the team.

In Brief about Scrum Master Role

1. Be a team player. The best Scrum Masters are real team players, who receive as much satisfaction from facilitating others’ success as their own.
2. Remove impediments.the Scrum Master should do everything in his or her power to remove obstacles that are preventing the team from accomplishing its sprint goals. for EX: If developers are complaining about the high temperature in the team room, the Scrum Master must find a way to cool it down.
3. Radiate information. Scrum Master’s primary responsibilities is to radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself. These radiators may take the form of various Scrum artifacts, from backlogs to burn down charts.
4. Support the Product Owner. Just as the Scrum Master removes impediments for the team, he or she also works to assist the Product Owner with various activities. These include communicating updates and impediments as well as assisting with backlog and release plan maintenance.
5. Facilitate creativity and empowerment for the development team. he should perform up to its potential if its members feel they have the support and confidence of the Scrum Master and Product Owner behind them.
6. Improve the team’s engineering practices and tools as needed. To fully facilitate productivity, the Scrum Master must make sure teams have the tools and know-how they need to succeed.
7. Communicate, communicate, communicate. Yes, communication is integral to each of the above points, but it’s so essential that it’s worth mentioning again. Scrum’s success hinges on clear and frequent communication among all stakeholders. 
8. The Scrum Master acts as a hub for all of that communication, ensuring that everyone—the Product Owner, the team, and various other stakeholders—are always up-to-speed.

The Product Owner – Must haves,Warnings and Values

The Product Owner – Must have

1. Every Scrum team must have one product owner.
2. The PO should be highly available to the team.
3. The PO should have a clear vision of the product roadmap.
4. The PO should motivate the team with this vision

The Product Owner – Warnings

1. A product owner is also the Scrum Master.
2. The PO does not own the product backlog and does not keep it updated.
3. The PO is not one person but a committee.

The Product Owner – Values

1. Visionary: Has a clear and convincing vision of the product’s roadmap.
2. Articulate: Should be able to sell the vision to the team and motivate it to high performance.
3. Clear: Should be transparent and client on what the customer wants and should provide correct feedback to the team on the vale delivered.
4. Available: Should be available to the team at all times, guiding it, clarifying the needs, motivating it.

The Product Owner Role

Represents the voice of the customer and stakeholders to the team.

 Product Owner Responsible for:

1. Defining features for the product as user-centric and value adding user-stories and prioritizing them.
2. The release date and content of the product.
3. Manages ROI and makes sure to deliver business benefits
4. provides boundaries to describe the realities within which the vision must be realised
5. Responsible for that the team builds the right product
6. Responsible for that budget constraints are met

Product Owner Accountable for:

1.  Managing the product backlog.
2.  The value delivered by the product. Accepts or rejects work results.
3.  Ensuring that the team delivers value at the end of every Sprint.
4. Consulted by the team, and counsels them, at all times for successful delivery of value.
5. Owner of the product backlog.

The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed. This of course varies tremendously based on whether the team is developing commercial software, software for internal use, hardware, or some other type of product. The key is the person in this role needs to have a vision for what is to be built.

As a Product Owner on Real time Project

1. Provide a vision for the product and communicate the project vision to the team
2. Motivate the team to subscribe to the product vision
3. Communicate the business benefits of the entire product and each individual feature
4. Prioritise the product backlog
5. Define release and sprint goals
6. Continuously answer questions to add detail to requirements
7. Accept/reject developed user stories at the end of the sprint (or during the sprint)
8. Communicate about the project within the organisation (e.g. demo attendance and invites, forecasting, management reporting)
9. Create and maintain the product backlog     

Note:(The product owner can delegate some of the work of writing user stories to a BA but the Product Owner is still responsible that the work is being done and is being done properly)

Roles in the Scrum Framework

A Famous Story to understand the roles for Agile Model

Story Name : The Chicken and Pig Fable
Story going like this : A Pig and a Chicken are walking down the road.
The Chicken says, "Hey Pig, I was thinking we should open a restaurant!".
Pig replies, "Hmm, maybe, what would we call it?".
The Chicken responds, "How about 'ham-n-eggs'?".
The Pig thinks for a moment and says, "No thanks. I'd be committed, but you'd only be involved!"

The story is presented as a riddle:

Question: In a bacon-and-egg breakfast, what's the difference between the Chicken and the Pig?

Answer: The Chicken is involved, but the Pig is committed!

Here we have two roles one is Chicken and second one Pig.
Chicken refers to : 

• Ancillary roles 
• Involved in success of the goal.
• Not dedicated to it, though.
• Managers and observers

Pig Refers to :

• Core roles.
• Committed to success of the goal.
• Team, Scrum Master, Product Owner

The fable is referenced to define two types of project members by the scrum agile management system: pigs, who are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress.  

A successful project needs both chickens and pigs. However, given the sacrifice required of being a pig —forswearing other projects and opportunities—they can be difficult to collect. Thus, the construction of a successful project-team must ensure that the project has sufficient "pigs" and that they are empowered to drive the project in return for committing to and taking accountability for it.

For a Scrum project, Scrum Master, Product Owner, and Team are considered as people who are committed to the project while customers and executive management are considered as involved but not committed to the project.

Scrum Framework History

Rugby approach to Agile

1.  1986: “New New Product Development Game” published by Hirotaka Takeuchi and Ikujiro Nonaka described the “Rugby approach” to commercial product development.
2.  1990s: Ken Schwaber used a similar method in his company, Advanced Development Methods, Jeff Sutherland used a similar method in his company, Easel Corporation. DeGrace and Stahl refer to this method as Scrum in “Wicked problems, righteous solution
3. 1995: “The Knowledge Creating Company” published by Hirotaka Takeuchi and Ikujiro Nonaka elaborates on the method published in their earlier paper
4. 2001: Ken Schwaber and Mike Beedle publish the book “Agile Software Development with Scrum”.

Agile Vs Waterfall Model

Agile Vs Waterfall Model

1. The main advantage is the backward scalability in Agile. but in waterfall Model  Under waterfall approach we cannot change the decisions and implementations that we had made under the previous stages.sequentiality, if we want to make changes under waterfall we will have to build the entire project from the scratch once again.
2. The flexibility to error check under any part of the development stage makes Agile more bug free and less erroneous as compared to Waterfall which can only test bugs at the end of the development module.
3.  Agile provides flexibility to make changes as per customer requirements and in Waterfall model which doesn't allow any modifications once the module has been completed.

Why Agile

• Iterative development
• Early and frequent review of the development process by the business
• Scope is never closed
• Continual reassessment of development priorities by the business
• Realistic measurement of development capacity based on the actual resources available