Agile Project Management

Management - Agile Project Management

Agile Methodology is an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to the waterfall, or traditional sequential development.

Classical methods of software development have many disadvantages:

• Huge effort during the planning phase
• Poor requirements conversion in a rapidly changing environment
• Treatment of staff as a factor of production

Agile Manifesto’s

12 Agile Principles

The Declaration of Interdependence (DOI)

• We increase return on investment by — making continuous flow of value our focus.
• We deliver reliable results by — engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through — iterations, anticipation and adaptation.
• We unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through — group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through — situationally specific strategies, processes and practices.

Agile Methods

SCRUM

Scrum is an agile methodology that delivers software to customer and end users faster, better, and cooler.

It does not matter if we are talking about usage of scrum in software development or not, it is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed.

Scrum, which is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk. “What is SCRUM” can also be considered through three pillars that uphold every implementation of empirical process control: transparency, inspection and adaptation.

The SCRUM Framework

The Scrum framework consists of a set of Scrum Teams and their associated roles:

• Time-Boxes
• Artifacts
• Rules

SCRUM Roles

• The Scrum Master
• The Product Owner
• The Scrum Team (The Team Members)

The Scrum Master

The Scrum Master is the person responsible for managing the Scrum project. Sometimes it refers to a person who has become certified as a Scrum Master by taking Scrum Master training.

• The Scrum Master is a new role. It can be played by an existing person (such as a former Project Manager or team-member).
• The Scrum Master serves the team (helping them remove any and all impediments that surface), protects the team (from any outside disruption or interference), and teaches and guides the team’s use of Scrum.
• Without a Scrum Master, the team has a high risk of failure.

The Product Owner

• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed 
• Accept or reject work results.

The Scrum Team (The Team Members)

• The ideal team size in Scrum is 7 +/- 2 people.
• The team is cross-functional. It has all the skills to produce finished product – designers, coders, testers, etc. and everyone contributes based on competency, rather than just job title.
• The team is self-organizing and self-managing. It is responsible for making a commitment and managing itself to hit the goal (or get as close as it can). Scrum provides tools to help team do this.

SPRINT and Time-Boxed Scrum Ceremonies

• Release Planning Meeting
• Sprint
• Sprint Planning Meeting
• Sprint Review Meeting
• Sprint Retrospective Meeting
• Daily Scrum Meeting

Release Planning Meeting

• The release planning meeting is a highly recommended planning session in which features and themes are reviewed and prioritized, key dates and milestones are established, and the team determines, based on their velocity (prior or estimated), roughly which features will be delivered in the timeframe identified.
• The ultimate goal of the meeting is to produce a high-level release plan with delivery dates, number of iterations and the primary stories that will be delivered.
• The key to planning a release is knowing the team’s velocity (how much estimated work they can complete in a single iteration).
• If velocity is known and the scope is fixed, the team can calculate the number of iterations required by dividing the total estimate of all the features by their velocity.
• If the delivery date is fixed (as is typical), then velocity is multiplied by the number of iterations to get an initial sense of how many features can be delivered.
• If the development team's velocity is not known, then they must provide an estimate for it, and the release plan should be considered less precise for the first few iterations until a reliable velocity for the team can be derived.

Sprint

• The Team works for a fixed period of time, called a Sprint.
• Sprints are typically between 1- and 4-weeks in length. Some people recommend starting Scrum with 2-week Sprints.
• Sprints occur one after another, without any down-time between them. Working at a sustainable pace is very important to avoid team burn-out.
• Team and Product Owner decide the Sprint length in advance.

Sprint Planning Meeting

• Before each Sprint, the team selects what it will commit to deliver by the end of the Sprint, starting at the top of the Product Backlog.
• The team creates a task-level plan for how they will deliver.
• The team works together to create an initial assignment of tasks, and compares total estimated task hours with total estimated available hours, to make sure the commitment is reasonable.
• Everyone on the team takes part, regardless of experience-level.
• It is very important that the Product Owner not pressure the team into committing to more than they think is doable. If there is pressure, the team will over-commit and either not finish, or burn themselves out after a couple Sprints.
• Many managers are initially concerned that their team might under-commit. In reality, most teams have the opposite problem: it may take them several Sprints to learn to not over-commit.

Sprint Review Meeting

• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal

o   2 hours preparation time rule

• Participants

o   Customers

o   Management

o   Product Owner

o   Other engineers

Sprint Retrospective Meeting

• The Team, Product Owner, and Scrum Master meet at the end of each Sprint to review their way of working, and look for ways to improve their effectiveness.
• This is the mechanism for continuous improvement, and also where critical problems are identified and addressed, or surfaced to management for assistance.

Daily Scrum Meeting

• Each day, the team has a short meeting to update each other on progress and surface blocks. They stand up, to keep it fast.
• To keep the meeting to <15 minutes, everyone reports just 3 things: done since yesterday, done by tomorrow, and blockages.
• Scrum Master notes blockages, and afterwards helps resolve them.
• Others can attend the meeting if the team invites them, but they do not speak. This meeting is not for monitoring team.

• Three questions:

o   What did you do yesterday?

o   What will you do today?

o   What are the obstacles in your way?

• Avoid other unnecessary meetings

• Is not a problem solving session
• Is not a way to collect information about WHO is behind the schedule
• Is a meeting in which team members make commitments to each other and to the Scrum Master
• Is a good way for a Scrum Master to track the progress of the Team
• Entire team sees the whole picture every day, so no email communications.
• Create peer pressure, to do what you say you’ll do

Scrum Artifacts

• The Product Backlog
• The Release Burndown
• The Sprint Backlog
• The Sprint Burndown

The Product Backlog

Product backlog is the complete list of requirements - including bugs, enhancement requests, and usability and performance improvements - that are not currently in the product release.

• The Product Backlog is the single master list of features, functionality, and other work required, prioritized based on business value and risk, in the judgment of the Product Owner.
• Items at the top of the list will be completed by the team soonest.
• The Product Backlog is constantly being revised (items added, removed, modified) by the Product Owner, to maximize the business success of the team’s efforts.

The Release Burndown

• The Release Burndown graph records the sum of remaining Product Backlog estimated effort across time.
• The estimated effort is in whatever unit of work the Scrum Team and organization have decided upon.
• The units of time are usually Sprints.
• Product Backlog item estimates are calculated initially during Release Planning, and thereafter as they are created.
• During Product Backlog grooming they are reviewed and revised, however, they can be updated at any time.
• The Team is responsible for all estimates.
• The Product Owner may influence the Team by helping understand and select trade-offs, but the final estimate is made by the Team.
• The Product Owner keeps an updated Product Backlog list/ Release Backlog Burndown posted at all times.
• A trend line can be drawn based on the change in remaining work.

The Sprint Backlog

Sprint backlog is the list of backlog items assigned to a sprint, but not yet completed. In common practice, no sprint backlog item should take more than two days to complete. The sprint backlog helps the team predict the level of effort required to complete a sprint.

• Estimates are updated whenever there’s new information
• A subset of Product Backlog Items, which define the work for a Sprint
• Is created ONLY by Team members
• Each Item has its own status
• Should be updated every day
• No more than 300 tasks in the list
• If a task requires more than 16 hours, it should be broken down
• Team can add or subtract items from the list. Product Owner is not allowed to do it

The Sprint Burndown

Shows the work remaining within the sprint and is updated every day. The burndown chart is used both to track sprint progress and to decide when items must be removed from the sprint backlog and deferred to the next sprint.

• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• The Burndown Chart graphs the total hours left for all tasks.

SCRUM Overview

SCRUM Process

Additional Information

• During the Sprint, what the team committed to deliver does not change, and the end-date of the Sprint does not change.
• This enables team to make and keep commitments, it gives the team focus and stability during the Sprint, and it trains Product Owner to clearly think through what is on the Product Backlog.
• If something major comes up, Product Owner can direct the team to terminate the Sprint prematurely, and start a new one.
• In return for not making changes during the Sprint, Product Owner can make any changes they want to the Product Backlog before the start of the next Sprint.
• Product Owner can add, remove, reorder, or change items. They can also ask the team to re-implement work that’s already been completed.

Scrum Pros/Cons

Advantages

• Completely developed and tested features in short iterations
• Simplicity of the process
• Clearly defined rules
• Increasing productivity
• Self-organizing
• each team member carries a lot of responsibility
• Improved communication
• Combination with Extreme Programming

Drawbacks

• Undisciplined Hacking (no written documentation)
• Violation of responsibility
• Current mainly carried by the inventors

The eXtreme Programming (XP)

Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Other elements of extreme programming include:

• Programming in pairs or doing extensive code review
• Unit testing of all code
• Avoiding programming of features until they are actually needed
• A flat management structure
• Simplicity and clarity in code
• Expecting changes in the customer's requirements as time passes and the problem is better understood,
• Frequent communication with the customer and among programmers

The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming.

XP concentrates on the development rather than managerial aspects of software projects. XP was designed so that organizations would be free to adopt all or part of the methodology.

The XP Values

               

• Communication
• Simplicity
• Feedback
• Courage
• Respect

The XP Core Practices

Whole Team

The team consists of developers, business analysts, QA, project managers, etc. The team works together in a lab space or open area where collaboration and communication are maximized.

The Planning Game

Development proceeds in very short iterations, typically 1-2 weeks in duration. Prior to each iteration features are broken down into very small stories. Stories are estimated by developers and then chosen by stakeholders based on their estimated cost and business value. The sum of story estimates planned for the current iteration cannot exceed the sum of estimates completed in the previous iteration.

Small Releases

Systems are released to production or pre-production very frequently. An interval of 2-3 months is the maximum. The minimum can be once per iteration.

Customer Tests

Stories and features are defined by automated tests written by the business analysts, and QA. No story or feature can be said to be done until the suite of acceptance tests that define it are passing.

Coding Standard

Codes, and other work artifacts, look as if they were written by the team. Each team member follows the team standard for format and appearance of the artifacts.

Sustainable Pace

Building software is a marathon, not a sprint. Team members must run at a rate they can sustain for the long haul. Overtime must be carefully controlled and limited. Tired people do not win.

Metaphor

Names within code and other work artifacts are chosen to be evocative of the system being created.

Continuous Integration

The whole system is built and tested end-to-end several times each day. While new tests are made to pass, no previously passing tests are allowed to break. Developers must continuously keep the system in a deployable state.

Collective Ownership

Codes, and other work artifacts, are not owned by individuals. Any member of the team may work on any artifact at any time.

Test Driven Development

Developers are not allowed to write production code until they have written a failing unit test. They may not write more of a unit test than is sufficient to fail. They may not write more production code than is sufficient to pass the failing test. The unit tests are maintained and executed as part of the build process. No previously passing unit test is allowed to fail.

Refactoring

Code, and other work artifacts, are continuously reviewed and kept as clean as possible. It is not sufficient that code works; it must also be clean.

Simple Design

The simplest design that suffices for the task at hand is the right design. More complex and general designs may become useful later, but not now. We do not wish to carry the weight of that complexity while it is not needed. Sufficient for the day are the complexities therein.

Pair Programming

Code and other work artifacts are produced by pairs of individuals working together. One member of the pair is responsible for the task at hand, and the other helps out. Pairs change frequently (every two hours or so) but responsibility stays with the owner.

The XP Planning & Feedback Loops

Feature Driven Development (FDD)

• Feature-driven development (FDD) is an iterative and incremental software development process.
• It is one of a number of lightweight or agile methods for developing software.
• FDD blends a number of industry-recognized best practices into a cohesive whole.
• These practices are all driven from a client-valued functionality (feature) perspective.
• Its main purpose is to deliver tangible, working software repeatedly in a timely manner.

Dynamic Systems Development Method (DSDM)

• Dynamic systems development method (DSDM) is an agile project delivery framework, primarily used as a software development method.
• DSDM originally sought to provide some discipline to the rapid application development (RAD) method.
• In 2007 DSDM became a generic approach to project management and solution delivery
• DSDM is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.
• DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritization of scope into must, should, could and won't haves to adjust the project deliverable to meet the stated time constraint.
• DSDM is one of a number of agile methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance.

Crystal

• Crystal methods are a family of methodologies (the Crystal family) that were developed by Alistair Cockburn in the mid-1990s.
• Crystal family is Cockburn’s way of cataloguing what they did that made the projects successful.
• Crystal methods are considered and described as “lightweight methodologies”.
• The use of the word Crystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values.
• The faces are a representation of techniques, tools, standards and roles.
• The family is divided into different colors. Some examples:
• Crystal Clear
• Crystal Yellow
• Crystal Orange
• Crystal Orange Web
• Crystal Red
• Crystal Maroon
• Crystal Diamond
• Crystal Sapphire

Lean Software Development (LSD)

• Lean software development (LSD) is a translation of lean manufacturing and lean IT principles and practices to the software development domain.
• Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the agile community.
• Lean is most popular with startups that want to penetrate the market, or test their idea and see if it would make a viable business.

Agile Process Overview

Value-Driven Delivery

• Value-Driven Delivery Projects are undertaken to generate business value, that is, to produce a benefit or to improve a service.
• When faced with a decision between two or more options, we should choose the one that is the most valuable to the business.
• What is most important is done first.

"Eat your dessert first."

Value Stream Mapping

Value stream mapping is a lean manufacturing technique that has been adopted by agile methods. This technique illustrates the flow of information (or materials) required to complete a process. It can help determine elements of waste that could be removed to improve the efficiency of the process. Value stream mapping usually involves creating visual maps of the process (value stream maps) and follows these steps:

1. Identify the product or service that you are analyzing;
2. Create a ... of the current process, identifying steps, queues, delays, and information flows.
3. Review the map to find delays, waste, and constraints.
4. Create a new value stream map of the desired future state of the process, optimized to remove or reduce lays, waste, and constraints.
5. Develop a roadmap for creating the optimized state.
6. Plan to revisit the process in the future to continually tune and optimize it.

Customer-Valued Prioritization

Customer-valued prioritization is concerned with working on the items that yield the highest value to the customer as soon as possible. This technique aims to engage the customer in the prioritization process, in which the team identifies high-value features and moves them up the backlog of items to work on.

The use of customer-valued prioritization schemes is a common thread through the different agile methods. While the terminology often varies—Scrum, for instance, has a “product backlog,” FDD has a “feature list,” and DSDM has a “prioritized requirements list”—the idea is the same.

The project works through a prioritized list of items that have discernible customer value.

Prioritization is essential for the team to be able to adjust the scope to meet budget or timeline objectives while still retaining the useful set of functionality that makes up the minimum marketable release.

Prioritization Schemes

MoSCoW Prioritization

The MoSCoW prioritization scheme, popularized by DSDM, is another example. This scheme derives its name from the first letters of the following labels:

• “Must have”
• “Should have”
• “Could have”
• “Would like to have, but not this time”

Monopoly Money

Monopoly Money Prioritization scheme that you distribute project budget amongst the system components/features.

100-Point Method

100-Point Method Each stakeholder gets 100 points and has to distribute them across the features.

Kano Analysis

Kano Analysis Classify customer preferences into one of four categories:

• Exciters: deliver unexpected, novel, or new high-value benefits to the customer.
• Satisfiers: bring value to the customer.
• Dissatisfiers: will cause the user to dislike the product if they are not there.
• Indifferent: do not have impact on customers.

Relative Prioritization

• Relative Prioritization A simple list removes the categories that people tend to fixate on from the debate and allows the focus of the discussion to be on priorities.
• It also provides a framework for deciding if and when to incorporate changes. When change is requested, the team can ask the business representatives, "What items are more important than this change?"

Product Roadmap

It is a visual overview of a product's releases and its main components. It is a communication tool that provides project stakeholders with a quick view of the primary release points and intended functionality. It is made of story map collections and shows what will go into each release.

It is usually created at the beginning of a project or after the vision statement has been defined.

Risk-Adjusted Backlog

Risk-Adjusted Backlog Through iterations, we can tackle high-risk of the project sooner.

Agile projects are both business-value and risk-driven. We often include risk responses into our backlog. To build it we usually merge two different lists:

• Prioritized feature list with ROI values
• Prioritized risk list

Prioritized Risk List

Prioritized Risk List We can build a list or risks ordered by severity and with values.

Expected Monetary Value (EMV) = Risk Impact (in dollars) X Risk Probability (as a percentage)

Agile Contracting

Agile projects attempt to fix resources and time (which are key components of cost) and vary functionality to achieve the highest priority, best quality system possible within those constraints. In contrast, when functionality is fixed, there is a risk the project will run out of money or time (or worse, produce a poor quality outcome).

WIP Limits

Work In Progress (WIP) (sometimes known as Work in Process or even Work In Play) is the term given to work that has been started, but has not yet been completed. Excessive WIP is associated with a number of problems, including:

•  WIP consumes investment capital and delivers no return on the investment until it is converted into an accepted product. It represents money spent with no return, something we want to limit.
• WIP hides bottlenecks in processes that slow overall workflow (or throughput), and it masks efficiency issues.
• WIP also represents risk in the form of potential rework, since there may still be changes to items until those items have been accepted. If there is a large inventory of WIP, there may in turn be a lot of scrap or expensive rework if a change is required.

Task and Kanban Boards

• They provide direct visual feedback and "touch" interactions between the team members.
• They are also good information radiators and very simple to understand.

Prototypes, Simulation, Demonstration

Demonstrations of functionality are critical to confirming success on soft ware projects. Software is intangible and difficult to reference. Companies rarely build the same system twice; this means projects are developing products that, for the most part, are new to the users. Therefore, the opportunity to look at something and try it out is very important for confirming whether the functionality is suitable. The term IKIWISI (I’ll Know It When I See It) is often used in soft ware development. It is not until something is demonstrated and used that the true requirements emerge.

Incremental Delivery

Incremental Delivery Another way to optimize the delivery of value on a project, the team regularly deploys working pieces of the product over the course of the project.

Customer-Valued Prioritization

Customer-Valued Prioritization By asking the business representatives or customer what their top-priority features are, we learn about their motivations, risks, and acceptance criteria.

Cumulative Flow Diagrams (CFDs)

Cumulative flow diagrams are valuable tools for tracking and forecasting agile projects. CFDs can help us gain insights into project issues, cycle times, and likely completion dates. The following diagram is an example of a CFD.

Little’s Law

It states that how long we are going to have to wait for benefits (the cycle time) is proportional to how much WIP we have (the queue size). In other words, we can predict completion times based on the size of the WIP queue.

Detailed CFD with Bottleneck Identified

Risk Burndown Graphs

They quickly inform stakeholders if the risks are moving in the right direction, or if they are escalating.

Cumulative Risk x Time

Wireframes

• Wireframing is an important step in any screen design process. It primarily allows to define the information hierarchy of design, making it easier to plan the layout according to how user to process the information.
• It's like an architectural blueprint; you need to see it in two-dimensional black and white diagrams before you understand how to build the actual house. Similarly for a screen design, one can't start building pixel layers in Photoshop, or writing blocks of code, without knowing where the information is going to go.
• At a deeper level, a wireframe is also very useful in determining how the user interacts with the interface.
• Wireframes focus on:

§  The range of functions available

§  The relative priorities of the information and functions

§  The rules for displaying certain kinds of information

§  The effect of different scenarios on the display

Personas

A persona, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person.

 

User Stories / Backlogs

• A user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.
• 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 note card.

 

Characteristics of a User Story à INVEST

Story Maps

A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release.

Information Radiators

An information radiator is a large, highly visible display used by software development teams to track progress.

An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.

• Is large and easily visible to the casual, interested observer
• Is understood at a glance
• Changes periodically, so that it is worth visiting
• Is easily kept up to date

Burn Down Charts

Burn-Up graph shows amount of work delivered (accepted) and changes made to the scope in iteration, release or a time period. Use this graph to know -

• Total features (user story points) delivered in iteration, release or a time period.
• Total features (user story points) delivered by an owner in an iteration, release or a time period.
• Initial amount of work scheduled, and scope changes during the iteration, release or a time period.

Burn Up Charts

A burn up chart, tracks progress towards a projects completion, in the simplest form of burn up chart there are two lines on the chart:

• A total work line (the project scope line)
• A work completed line

Velocity

Velocity is a capacity planning tool sometimes used in agile software development. Velocity tracking is the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project.

3 Levels of Listening

A good coach must be familiar with the three levels of listening and how each level differs from the other. The three levels of listening are Internal Listening, Focused Listening, and Whole Body Listening.

Level 1: Internal Listening

At Level I, Internal Listening, our attention is on us. We listen to the words of the other person but the focus is on what it means to us.

• At Level I the spotlight is on "me": my thoughts, my judgments, my feelings, my conclusions about myself and others.
• At Level I there is only one question: "What does this mean to me?

Example: When we are at a restaurant with another person, we typically have an internal conversation such as:

• “Should I have a beverage?”
• “Can I afford that item?”

Level 2: Focused Listening

At Level II, Focused Listening, there is a sharp focus on the other person. In the words of Gabriel Marcel, "When somebody's presence does really make itself felt, it can refresh my inner being; it reveals me to myself, it makes me feel more fully myself than I should be if I were not exposed to its impact."

• With Focused Listening, you make your presence known. You can see it in people's posture when they are communicating at Level II; both leaning forward, looking intently at each other.
• There is a great deal of attention on the other person and not much awareness of the outside world. We listen for words, expressions, emotions, what they don’t say.

Example: Once we finish the internal conversation in the restaurant, we will turn our attention to the other person with us.

• Desire to connect with them
• Sometimes we become oblivious to what is going on around us

Skills for Level II Listening

Clarifying

• Skill of clarifying is a combination of listening, asking, and reframing. Sometimes it simply testing different perspectives
• "Here's what I'm hearing…“; “Is that right?”

MetaView

• Big picture and opens room for perspective
• “What do you see about this situation from 5000 feet up?”

Metaphor

• Draw on imagery or experience to help the other person comprehend faster
• "Are you drifting in a fog? is better than saying “Are you confused?”
• the fog metaphor allows people to see a rich imagery for further exploration

Acknowledging

• Recognizes inner character, more than what a person did or what it means to you
• "Jane, you really showed commitment to learning“; “You took a big risk.”

Level 3: Global Listening

At Level III, Global Listening, you listen at 360 degrees. You listen as though you and the other person were at the "center of the universe receiving information from everywhere at once.

• Level III includes everything you can observe with your senses: what you see, hear, smell, and feel.
• One of the benefits of learning to listen at Level III is greater access to your intuition. From your intuition you receive information that is not directly observable, and you use that information just as you'd use words coming from the other person’s mouth.
• Level III is sometimes described as environmental listening (temperature, energy levels...)

Example: Reading a room, using your intuition, getting the sense from something

Honoring the Three Levels

Level One

• Speak confidently and with full expression
• Remain passionate AND unattached
• Watch for silencing yourself, apologizing for what you are about to say, speaking to look good or anticipating disagreement.
• No holding back, no judging, no acquiescing

Level Two

• You are present and connected to others
• You are curious and asking good questions
• No, yes, buts…lots of yes, and…

Level Three

• Comments advance or illuminate the discussion
• The tone and manner is supportive
• Focused on the shared goal
• Saying the hard thing
• Watch for blame and defensiveness, contributions that are not on topic or relevant, overly focused on a personal agenda.

Five Levels of Conflict

Participatory Decision Models

Simple Voting

Simple voting “For” or “Against” by a show of hands is easy, but often misses an opportunity for decision refinement. It strives for a result too quickly and can miss a better third alternative. Perhaps someone has a suggestion to tweak the options being voted on? A simple “For” or “Against” vote omits refinement as an integral step. As a partial solution we could agree to all discuss our thoughts before voting, but for the majority of no-brainer decisions this is time poorly used. I vote “No” on this approach

Thumbs up/down/sideways

Using a simple show of thumbs up, down, or sideways around the room is a much faster way of achieving a simple vote. People with a thumb sideways are then asked why they could not make up their mind. Sometimes they are just neutral, other times they have a conflict, concern or questions that needs further investigation. This approach is quicker than polling everyone for input, as most people will have no concerns and just want to move forward.

Jim Highsmith Decision Spectrum

Using this model team members are asked to indicate with tick marks where on a spectrum from “fully in favor” through “mixed feelings” to “No, veto” they feel about the decision at hand. This is an effective model because it allows people to indicate support for a decision and air their reservations at the same time. Giving people an opportunity to register their concern is an important component of achieving agreement to go forward while respecting dissenting views and keeping everyone engaged? People indicating they are not entirely in favor are then invited to share the concerns, but often just being able to register reservations is enough to allow people to commit to a new direction.

Fist of Five Voting

The Fist of Five approach combines the speed of thumbs up/down with the degrees of agreement from the Decision Spectrum.

A small problem with this approach is that two standards have emerged and so you really need to be clear upfront if 5 fingers mean “full agreement” or “no, stop”. One model (popularized by the American Youth Foundation) registers support by finger votes, a fist (no fingers) means no support, 5 fingers mean total support and a desire to lead the charge.

Servant Leadership

Servant leadership is both a leadership philosophy and set of leadership practices. Traditional leadership generally involves the accumulation and exercise of power by one at the “top of the pyramid.” By comparison, the servant-leader shares power puts the needs of others first and helps people develop and perform as highly as possible.

Adaptive Leadership

The adaptive leadership skills represent the major discovery from our research. That’s not to suggest we “discovered” these skills. Rather, we found that adaptive leadership skills are what set great leaders apart: these skills represent the otherwise intangible qualities that great leaders have in common. Adaptive leadership is a unique combination of skills, perspective, and guided effort that enable true excellence. The adaptive leadership skills can take a leader at any level to places others cannot go.

Five Stages of Team Formation & Development

Situational Leadership Model

Aspects of Emotional Intelligence

Coaching At the Whole Team and Individual Levels

Caves and Common

The phrase Caves and Commons refers to the creation of two zones in the room.

The Commons area is organized to maximize osmotic communication and information transfer. For this to make sense, the people in the room must be working on the same project.

The Caves portion of the room is organized to give people a private place to do e-mail, make phone calls, and take care of their need for separation.

An open workspace doesn't leave much room for privacy, and pair programming stations aren't very personal. This loss of individuality can make people uncomfortable. Be sure that everyone has a space they can call their own.

Osmotic Communication

Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work. Several people have related their experience of it much as this person did:

We had four people doing pair programming. The boss walked in and asked a question. A candidate started answering it, but gave the wrong name of a module. Nancy, programming with Neil, corrected me, without Neil ever noticing that she had spoken or that a question had been asked.

Modes of Communication

Implication of the Modes of Communication

Adaptive Planning

• Traditionally IT delivery planning would be described as predictive planning; with a plan defined at the beginning of a project and then managing the project to the plan.
• Adaptive planning will also start defining a plan but acknowledges that once work starts the plan will change, and the plan needs to reflect this new knowledge.
• Plans for an agile team will be adapted based on the delivery each iteration.
• Each iteration delivers a working, tested increment teams have an accurate measure on what can be delivered.
• For adaptive planning to be effective teams must:

§  Work off a prioritized backlog

§  Have close collaboration with the customer

§  Deliver a working, tested increment every iteration

§  Understand that the direction will change and the team will respond

§  Maintain consistent staffing

• The two tools to drive adaptive planning are:
• Velocity - The sum of the story points for delivered stories in iteration i.e. stories that are developed, tested and signed off by the customer.
• Burn up charts - A simple way to track delivery based on velocity showing the time the required scope will be delivered in.

Time Boxing

• Timeboxing refers to the act of putting strict time boundaries around an action or activity.
• In agile software development, a timebox is a defined period of time during which a task must be accomplished.
• Timeboxes are commonly used to manage software development risk.
• Development teams are repeatedly tasked with producing a releasable improvement to software, timeboxed to a specific number of weeks.

Progressive Elaboration

The concepts of rolling wave planning and progressive elaboration address the idea that planning near term work in detail and later work in less detail. Then as new details emerge, going back to the plans and updating them with the new data.

Cross that bridge when we come to it.

Minimum Marketable Feature (MMF)

• A Minimum Marketable Feature (MMF) is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it.
• A “MMF” is characterized by the three attributes:
• Minimum
• Marketable
• Feature.
• A feature is something that is perceived, of itself, as value by the user.
• Marketable means that it provides significant value to the customer; value may include revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty.
• A release is a collection of MMFs that can be delivered together within the time frame.

Value Based Prioritization

 

Agile Games (Collaborative/Innovative Games)

Innovation Games are proven techniques for working with all groups of customers to create innovative products and services. They are a means of fueling innovation by understanding what your customers really want.

Selecting the Game

Remember the Future

Goal: Understand your customer’s definition of success.

Activity: Hand each of your customers a few pieces of paper. Ask them to imagine that it is sometime in the future and that they’ve been using your product almost continuously between now and that future date (month, year, whatever). Then ask them to write down exactly what your product will have done to make them happy or successful or rich or safe or secure or art – choose what works best for your product.

Key point – ask “What will the system have done?” not “What should the system do?”

Spider Web

Goal: Clarify the operating context for your products and services.

Activity: Put the name of your product or service in the center of a circle. Ask your customers to draw other products and services, ask them to tell you when, how, and why these are used. Ask them to draw lines between the different products and services.

As your customers reviews when and where they user your offering, you can capture the various inter-relationships that exist between the different products and service that they use throughout the day.

 

Product Box

Goal: Identify the most exciting, sellable features.

Activity: Ask your customers to imagine that they’re selling your product at a tradeshow, retail outlet, or public market. Give them a few cardboard boxes and ask them to literally design a product box that they would buy. The box should have the key marketing slogans that they find interesting. When finished, pretend that you’re a skeptical prospect and ask your customer to use their box to sell your product to you.

Speed Boat / Sailboat

Sailboat is a risk and opportunity gathering technique that is very quick to set up and facilitate, but generates really good risk and opportunity outputs.

Goal: Identify what customers don’t like (about your process or system).

Activity: Draw a boat on a whiteboard or sheet of butcher paper. You’d like the boat to really move fast. Unfortunately, the boat has a few anchors holding it back. The boat is your system, and the features that your customers don’t like are its anchors.

Customers write what they don’t like on an anchor. They can also estimate how much faster the boat would go when that anchor was cut. Estimates of speed are really estimates of pain.

Shape the Product Tree / Prune the Product Tree

In this exercise we now get everyone to take the post-it notes from Remember the Future and transfer them onto a depiction of a product tree.

Goal: Build a product according to your plans.

Activity: Start by drawing a very large tree on a whiteboard. Thick limbs represent major areas of functionality within your system. The edges of the tree – its outermost branches – represent the features available in the current release. Write potential new features on several index cards, ideally shaped as leaves. Ask your customers to place desired features around the tree. Observe how the tree gets structured – does one branch get the bulk of the growth? Does an underutilized aspect become stronger?

Start Your Day

Goal: Understand how and when your customer uses your product.

Activity: Ask your customer to describe the daily, weekly, monthly, and yearly events that are related to their use of your product on pre-printed, poster-sized calendars or a simple timeline on poster paper. Ask them to describe events in time frames appropriate for your project. Special event that are unique to an industry or sector (like a conference), or days in which everything goes horribly wrong and they’re looking for help. While they’re doing this, be alert for how your product helps – or hinders – their day.

Buy a Feature

Goal: Prioritize features.

Activity: Create a list of features with an estimated cost. The cost can be development effort or actual cost you intend to charge for the feature. Customers buy features that they want.

Features are priced high enough that no single customer can buy the features. This helps motivate customers to negotiate between themselves as to which features are most important. Observation of this negotiation provides great insight into what customers are willing to pay for.

Show and Tell

Goal: Identify the most important artifacts created by your product.

Activity: Ask your customers to bring examples of artifacts created or modified by your product or service. Ask them to tell you why these artifacts are important, and when and how they’re used.

Pay careful attention to anything that surprises you – artifacts you expected them to create or modify that they have ignored, artifacts that aren’t used, or artifacts used in unexpected ways.

Me and My Shadow

Goal: Identify your customer’s hidden needs.

Activity: Shadow your customer while they use your product or service. Literally. Sit next to them and watch what they do. Periodically ask them “Why are you doing that?” and “What are you thinking?” Take along a camera or camcorder and record key activities. Ask for copies of important artifacts created or used by your customer while they are doing the work.

Give Them A Hot Tub

Goal: Use outrageous features to discover hidden breakthroughs.

Activity: Write several features on note cards, one feature per card. Include several completely outrageous features. If you’re making a portable MP3 player, try adding features like “heats coffee”, “cracks concrete” or “conditions dog hair”. If you’re making a system that manages payroll, try adding features like “plans family reunions” or “refinishes wooden floors”. If you’re building an office building, add a hot tub in the lobby. Observe what happens with a customer uncovers one of these outrageous features.

20/20 Vision

Goal: Prioritize features.

Activity: When you’re getting fitted for glasses, your optometrist will often ask you to compare between two potential lenses by alternately showing each of them.

Start by writing one feature each on large index cards. Shuffle the pile and put them face down. Take the first one form the top and put it on the wall. Take the next one and ask your customers if it is more or less important than the one on the wall. Place it above or below, depending on its relative importance. Repeat this with all of your feature cards.

The Apprentice

Goal: Create empathy for the customer experience.

Activity: Ask your engineers and product developers to perform the “work” of the system that they are building. If they’re building a new data entry system, have them do the work of the current data entry operators. If they’re building workflow management software for furniture delivery people, have them deliver furniture. If they’re building a system to analyze vehicle performance data, ask them to change the oil in the car. They gain knowledge of the customer experience and some degree of empathy for the real problem that your customer is trying to solve.

Agile Estimations

Consensus based estimations techniques.

Wideband Delphi

• The Wideband Delphi estimation method is a consensus-based technique for estimating effort.
• Wideband Delphi is a process that a team can use to generate an estimate.
• The project manager chooses an estimation team, and gains consensus among that team on the results.
• Wideband Delphi is a repeatable estimation process because it consists of a straightforward set of steps that can be performed the same way each time.

PROBE / Proxy Based Estimating

• PROBE is based on the idea that if an engineer is building a component similar to one he built previously, and then it will take about the same effort as it did in the past.
• Individual engineers use a database to maintain a history of the effort they have put into their past projects.
• A formula based on linear regression is used to calculate the estimate for each task from this history.

COCOMO (Constructive Cost Estimation Model)

In Constructive Cost Model, or COCOMO, projects are summarized using a set of variables that must be provided as input for a model that is based on the results of a large number of projects across the industry.

The output of the model is a set of size and effort estimates that can be developed into a project schedule.

Planning Poker / Scrum Poker

Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators.

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

Planning poker is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular in Scrum and Extreme Programming.

Relative Sizing / Story Points

Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty.

Relative estimation is the basis of several closely related variants, such as "silent grouping" or "affinity estimating".

Story point is an arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story.

In simple terms it’s a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

• Don’t Equate Story Points to Hours
• Used as relative measure of complexity
• Not a direct measure of effort estimate, but instead, it is about the size of a story, feature or a piece of work
• Assign point values to each item, which are relative to each other
• Does not directly co-relate to actual hours
• Unit less
• Estimation in story points completely separates the estimation of effort from estimation of duration
• Cannot compare story points across different teams

In most cases a story point uses one of the following scales:

• Doubling of Numbers - 1, 2, 4, 8, 16…
• T-Shirt Sizing - X-Small (XS), Small (S), Medium (M), Large (L), Extra-Large (XL)…
• Fibonacci Sequence - 1, 2, 3, 5, 8, 13, 21…

Doubling of Numbers - 1, 2, 4, 8, 16…

A sequence of numbers in which the next number is derived by doubling the previous number (e.g. 1, 2, 4, 8, 16…). The sequence is used to size stories in Agile estimation techniques such as Planning Poker.

T-Shirt Size

T-Shirt sizing is a way to practice relative sizing. By comparing stories you can break them out into buckets of Extra-small, Small, Medium, Large, and Extra-large.

Fibonacci Sequence

A sequence of numbers in which the next number is derived by adding together the previous two (e.g. 1, 2, 3, 5, 8, 13, 21, 34…). The sequence is used to size stories in Agile estimation techniques such as Planning Poker.

Ideal Time

• The time required to do a task uninterrupted
• Not the same as actual time
• Excludes
• Meeting time
• Phone calls
• Emails
• Peer reviews
• Task switching
• Administrative work, etc.

Actual Time

• The time elapsed in doing a particular task
• Includes normal work interruptions

Story Points vs. Ideal Time

Story Points

• Helps drive cross-functional behavior – since the estimates have to be a single number representing the work for the whole team
• Are a pure measure of size. Ideal days are not
• Estimating is faster
• Neutral, since each one’s ideal days can be different

Ideal Time

• These are easier to explain outside the team
• Easier to estimate at first

Affinity Estimation

Affinity estimation is just a technique by which story points are assigned to user stories. It’s not an agile methodology like Scrum, XP or Kanban but it can help improve the planning and estimation elements of agile methodologies like these.

Parkinson’s Law

States that “work expands to fill the time available”

Student Syndrome

Symptom of starting work as late as possible (procrastination).

Planning Balance

Corollary Risk of Doing Too Much Upfront Planning

Agile Project Charter

An Agile project charter is a document that outlines the rules of team engagement and high level expectations around scope. It is one of the most critical communication components in an entire project.

• Create the Agile project charter as a team.
• The objective is to retain flexibility to adapt throughout the project.

Cycle Time

• Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer.
• Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
• Cycle time is closely related to WIP (Work in Progress)

Escaped Defects

An escape is a defect that was not found by, or one that escaped from, the test team. Implementing the escape analysis method for test improvement can increase the quality of software by lessening the occurrence of software defects.

Trend Analysis / Variations

Common and special causes are the two distinct origins of variation in a process.

Common Cause variation is fluctuation caused by unknown factors resulting in a steady but random distribution of output around the average of the data. It is a measure of the process potential, or how well the process can perform when special cause variation removed.

Special Cause variation is caused by known factors that result in a non-random distribution of output. Special cause variation is a shift in output caused by a specific factor such as environmental conditions or process input parameters. It can be accounted for directly and potentially removed and is a measure of process control.

Continuous Integration (CI)

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

• Minimize the duration and effort required by "each" integration episode
• Be able to deliver "at any moment" a product version suitable for release

Risk Based Spike

Spikes are a really good way for teams to figure out stuff that they don't know and need to know in order to understand the complexity so that it can be properly estimated, or quoted on or simply to find out if something is technically possible or not.

Frequent Verification & Validation on Agile Projects

Test-Driven Development (TDD) / Test-First Development (TFD)

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refractors the new code to acceptable standards.

 

Acceptance Test-Driven Development (ATDD)

Acceptance Test Driven Development is about people, communication, collaboration and delivering business value. ATDD is a software development methodology based on enhanced communication among its actors.

Problem Solving / Structure of Retrospective

1. Set the Stage

• Check-In
• Focus-on/Focus-off
• ESVP (Explore, Shoppers, Vacationers, Prisoners)
• Working Agreements

Check-In

Purpose

Help people put aside other concerns and focus on the retrospective. Help people articulate what they want from the retrospective.

Time Needed

Five to ten minutes, depending on the size of the group.

Description

After welcoming the participants and reviewing the goal and agenda, the retrospective leader asks one brief question. Each person answers in round-robin fashion.

Focus On/Focus Off

Purpose

Help establish a mind-set for productive communication. Help participants set aside blaming and judgment—and fear of blaming and judgment.

Time Needed

Eight to twelve minutes, depending on the size of the group.

Description

After welcoming the participants and reviewing the goal and agenda, the retrospective leader describes productive and unproductive communication patterns. After describing those patterns, the participants discuss what they mean for the retrospective.

ESVP

Use this to set the stage in a longer iteration, release, or project retrospective.

Purpose

Focus people on the work of the retrospective. Understand people’s attitudes to the retrospective.

Time Needed

Ten to fifteen minutes.

Description

Each participant reports (anonymously) his or her attitude toward the retrospective as an Explorer, Shopper, Vacationer, or Prisoner (ESVP). The retrospective leader collects the results and creates a histogram to show the data, and then guides a discussion about what the results mean for the group.

Working Agreements

Use this to set the stage in an iteration, release, or project retrospective.

Purpose

Establish a set of behaviors that will support the team in having productive discussions. Establish that team members are responsible for monitoring their interactions. Provide candidates for day-to-day working agreements if the team doesn’t already have them.

Time Needed

Ten to thirty minutes, depending on the size of the group.

Description

Team members work together to generate ideas for effective behaviors at work then choose five to seven agreements to guide team interactions or processes.

2. Gather Data

• Timeline
• Triple Nickels
• Color Code Dots
• Mad, Sad, Glad
• Locate Strength
• Satisfaction Histogram
• Team Radar
• Like to Like

Timeline

Use this to gather data in a longer iteration, release, or project retrospective.

Purpose

Stimulate memories of what happened during the increment of work. Create a picture of the work from many perspectives. Examine assumptions about who did what when. See patterns or when energy levels changed. Use this for “just the facts” or facts and feelings.

Time Needed

Thirty to ninety minutes, depending on the size of the group and the length of the increment of work.

Description

Group members write cards to represent memorable, personally meaningful, or otherwise significant events during the iteration, release, or project and then post them in (roughly) chronological order. The retrospective leader supports the team to discuss.

Triple Nickels

Use this to gather data or as part of the Decide What to Do phase in an iteration, release, or project retrospective.

Purpose

Generate ideas for actions or recommendations. Uncover important topics about the project history.

Time Needed

Thirty to sixty minutes, depending on the size of the group.

Description

Form small groups. In the groups, each person has five minutes to brainstorm and write down ideas individually. At the end of five minutes, each person passes the paper to the person on his or her right. That person has five minutes to write down ideas that build on the ideas already written on the paper. Repeat until the paper returns to the original writer.

Color Code Dots

Use this in conjunction with a timeline to gather data about feelings in a longer iteration, release, or project retrospective.

Purpose

Show how people experienced events on the timeline.

Time Needed

Five to twenty minutes.

Description

Team members use sticky dots to show events on the timeline where emotions ran high or low.

Mad, Sad, Glad

Use this to gather data about feelings in an iteration, release, or project retrospective.

Purpose

Get the feeling facts out on the table.

Time Needed

Twenty to thirty minutes, depending on the size of the group.

Description

Individuals use colored cards or sticky notes to describe times during the project where they were mad, sad, or glad.

Locate Strength

Use this to gather data about facts and feelings on longer iteration, release, and project retrospectives. Follow with the Identify Themes activity to generate insights.

Purpose

Identify strengths so the team can build on them in the next iteration. Provide balance when an iteration, release, or project hasn’t gone well.

Time Needed

Fifteen to forty minutes for the Locate Strengths activity, depending on the number of questions in the interview. Allow twenty to forty more to identify themes. The total for the two activities is thirty to ninety minutes.

Description

Team members interview each other about high points on the project. The goal is to understand the sources and circumstances that created those high point.

Satisfaction Histogram

Use this activity to set the stage and/or gather data in iteration retrospective.

Purpose

Highlight how satisfied team members are with a focus area. Provide a visual picture of current status in a particular area to help the team have deeper discussions and analysis. Acknowledge differences in perspective among team members.

Time Needed

Five to ten minutes.

Description

Team members use a histogram to gauge individual and group satisfaction with practices and process.

Team Radar

Use this to gather data in an iteration, release, or project retrospective.

Purpose

Help the team gauge how well they are doing on a variety of measures, such as, engineering practices, team values, or other processes.

Time Needed

Fifteen to twenty minutes.

Description

Team members track individual and group ratings for specific factors about process or development practices they want to examine.

Like to Like

Use to gather data during an iteration, release, or project retrospective.

Purpose

Help team members recall their experiences during the iteration (release or project), and hear that others may have perceived it differently.

Time Needed

Thirty to forty minutes.

Description

Team members take turns judging which events or factors about their iteration are the best fits for quality cards. As the cards are evaluated, team members learn about each other’s perspective on the same events or conditions.

3. Generate Insights

• Brainstorming (Free-For-All, Round Robin, Quiet Time)
• Force Field Analysis
• Five Whys
• Fishbone
• Patterns and Shifts
• Prioritize with Dots
• Report Out with Synthesis
• Identify Themes
• Learning Matrix

Brainstorming/Filtering (Free-For-All, Round Robin, Quiet Time)

Use this to generate insights in an iteration, release, or project retrospective.

Purpose

Generate a large number of ideas and filter them against a defined set of criteria.

Time Needed

Forty to sixty minutes.

Description

Team members generate ideas using traditional brainstorming, then test whether each idea is applicable to the current situation.

Force Field Analysis

Use this in conjunction with an activity that suggests possible changes while generating insights for a release or project retrospective. Use this as part of a planning exercise while deciding what to do.

Purpose

To examine what factors in the organization will support a proposed change and which will inhibit the change.

Time Needed

Forty-five to sixty minutes depending on the complexity of the issue and the size of the group.

Description

The team defines a desired state they want to achieve. Small groups work to identify the factors that could either restrain or drive the change they want. The factors are listed on a poster; then the group assesses the strength of each supporting factor relative to the other

Five Whys

Use this to generate insights in an iteration, release, or project retrospective.

Purpose

Discover underlying conditions that contribute to an issue.

Time Needed

Fifteen to twenty minutes.

Description

Team members work in pairs or small groups to look at issues. They ask “Why?” times to get beyond habitual thinking.

Fishbone

Use this activity to generate insights in a longer iteration, release, or project retrospective.

Purpose

Look past symptoms to identify root causes related to an issue. Look for reasons behind problems and breakdowns.

Time Needed

Thirty to sixty minutes.

Description

The team identifies factors that are causing or affecting a problem situation and then looks for the most likely causes. After they’ve identified the most likely causes, they look for ways they can make changes or influence those factors.

Patterns and Shifts

Use this in conjunction with a visual data-gathering activity (e.g., Timeline or Mad, Sad, Glad) to generate insights in an iteration, release, or project retrospective.

Purpose

Look for links and connection between facts and feelings. Analyze the data about the iteration/release/project. Guide the group in recognizing and naming patterns that contribute to current issues.

Time Needed

Fifteen to sixty minutes, depending on the size of the group and the amount of data.

Description

After gathering data, facilitate a discussion to analyze the data, looking for patterns of events, behaviors, or feelings. Also look for times when there has been a shift; for example, everything was going smoothly, and then the energy.

Prioritize with Dots

Use this in the Generate Insights or decide what to do phase in an iteration release or project retrospective.

Purpose

To gauge how the group prioritizes a long list of candidate changes, proposals, and so forth.

Time Needed

Five to twenty minutes depending on the number of options and the size of the group.

Description

Team members prioritize the top issues, ideas, or proposals.

Report Out with Synthesis

Purpose

Share thinking and ideas from small groups with the whole group. Find common threads, and look for ideas that energize the whole group.

Time Needed

Twenty to sixty minutes, depending on the number of small groups and the amount of time allowed for reports.

Description

Each small group shares the result of their work with the whole group. The retrospective leader keeps a progress bar to help the reporter stay within time. After the final report, the group looks for common threads and themes and identifies those they want to work on.

Identify Themes

Purpose

Find common threads from Locate Strengths interviews. Discern compelling ideas for experiments, changes, and recommendations.

Time Needed

One to two hours.

Description

After Locate Strengths interviews, the interview pairs form groups and report what each learned as they interviewed the other person. As they report the high points, team members listen for common themes and compelling ideas. After the identifying themes, the group clusters all the cards. Small groups self-select to further define the ideas contained in the cluster.

Learning Matrix

Use this to generate insights in iteration retrospective.

Purpose

Help team members find what’s significant in their data.

Time Needed

Twenty to twenty-five minutes.

Description

Team members look at four perspectives on their data to brainstorm a list of issues quickly.

4. Decide What to Do

• Retrospective Planning Game
• SMART Goals
• Circle of Questions
• Short Subjects

Retrospective Planning Game

Use this to develop action plans in deciding what to do in a release, or project retrospective.

Purpose

Develop detailed plans for experiments or proposals.

Time Needed

Forty to seventy-five minutes depending on the number of experiments and the size of the group.

Description

Team members work individually or in pairs to brainstorm all the tasks necessary to complete an experiment, improvement, or recommendation. After brainstorming, team members eliminate redundant tasks and fill in gaps. The task is arranged in order, and team member’s sign up for tasks they will complete.

SMART Goals

Use this activity to decide what to do in an iteration, release, or project retrospective.

Purpose

Translate ideas into priorities and action plans. Develop specific measurable actions.

Time Needed

Twenty to sixty minutes depending on the size of the group.

Description

Focus the team’s attention on developing goals that are Specific, Measurable, Attainable, Relevant, and Timely. Goals that have these characteristics are more likely to reach fruition.

Circle of Questions

Use this activity to decide what to do in an iteration, release or end of project retrospective.

Purpose

Help team choose an experiment or action steps for the next iteration, particularly when team members need to listen to one another.

Time Needed

Thirty+ minutes, depending on team size.

Description

Team members engage in a question asking and answering process to reach consensus on next steps.

Short Subjects

Use to decide what to do in iteration retrospective.

Purpose

Help to discover differing perspectives on how the team is doing and provide variety in very short retrospectives.

Time Needed

Twenty to thirty minutes.

Description

The team brainstorms lists of ideas for action, in response to prompts on the 2--3 flip charts. Titles may include:

• What Worked Well/Do Differently Next Time, a.k.a. as WWWDD
• Keep/Drop/Add
• Stop Doing/Start Doing/Keep Doing (a.k.a. StoStaKee)
• Start/Stop/Stay
• Smiley/Frowny
• Mads/Sads/Glads
• Prouds/Sorries
• Plus/Delta (on the iteration)

5. Close the Retrospective

• Plus/Delta
• Appreciations
• Temperature Reading
• Helped, Hindered, Hypothesis
• Return on Time Invested (ROTI)

Plus/Delta

Use this to close an iteration, release, or project retrospective.

Purpose

To retrospect on the retrospective and identify strengths and improvements.

Time Needed

Ten to twenty minutes, depending on the size of the group.

Description

The team identifies strengths (do more of) and changes for the next retrospective.

Appreciations

Use this to close an iteration, release, or project retrospective.

Purpose

To allow team members to notice and appreciate each other. End the retrospective on a positive note.

Time Needed

Five to thirty minutes, depending on the size of the group.

Description

Team members appreciate other team members for helping them, contributing, to the team, solving a problem, etc. Offering an appreciation is optional.

Temperature Reading

Use this while setting the stage or closing an iteration retrospective.

Purpose

Check on “where we’re at.” A practical way to process what is happening for the group (A Resource Handbook for Satir Concepts [Sch90]).

Time Needed

Ten to thirty minutes, depending on the size of the group.

Description

Team members report on what’s happening for them and what they want.

Helped, Hindered, Hypothesis

Use when closing iteration or release retrospectives.

Purpose

Help the retrospective leader get feedback to improve skills and processes.

Time Needed

Five to ten minutes.

Description

Retrospective leader gathers feedback from team members to discover what helped team members work and learn together during the session, find out what hindered them, and get ideas about what else to try in future retrospectives.

Return on Time Invested (ROTI)

Use in the closing retrospective phase for iteration or release retrospectives (or at the end of any meeting you’d like to improve).

Purpose

Help generate feedback on the retrospective process and gauge the effectiveness of the session from the team members’ perspectives.

Time Needed

Ten minutes.

Description

At the end of retrospective, ask team members to give feedback on whether they spent their time well.

Principals of System Thinking (Complex, Adaptive, Chaos)

Continuous Improvement / Continuous Process Improvement

Continuous Improvement is a method for identifying opportunities for streamlining work and reducing waste. The practice was formalized by the popularity of Lean / Agile / Kaizen in manufacturing and business, and it is now being used by thousands of companies all over the world to identify savings opportunities.

The PDCA Method or Deming Wheel for Improvement

Kaizen

Kaizen, also known as continuous improvement, is a long-term approach to work that systematically seeks to achieve small, incremental changes in processes in order to improve efficiency and quality. Kaizen can be applied to any kind of work, but it is perhaps best known for being used in lean manufacturing and lean programming. If a work environment practices kaizen, continuous improvement is the responsibility of every worker, not just a selected few.

Kaizen is strongly aligned with Agile in the way it encourages changes from the workers rather than asking management what should be changed. Therefore, it's strongly aligned with Retrospective Meeting in Scrum.

Self Assessment Scoring Model (Thinking, Collaboration, Releasing, Planning, Developing)

5 Levels of Agile Planning

Technical Debt

Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a code base. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

The Agile Triangle

Virginia Satir’s

Change models like Virginia Satir’s show that once you start a change initiative, a drop in productivity is highly probable due to the period of resistance and chaos. Objective is to shorten this phase by completing all preparation efforts before the transition starts, not during the transition.

Sashimi Technique (Slice of Cake)

Scrum uses the sashimi technique to require that every slice of functionality created by the developers be complete. All of the requirements gathering and analysis, design work, coding, testing, and documentation that constitute a complete product are required to be completed in every Sprint and demonstrated in the Sprint increment of functionality. Sprints are kept short enough that the stakeholders don’t lose interest in the project before the Sprints are completed. And stakeholders can see that they have an opportunity to redirect the project at the start of every Sprint to optimize the value they derive from the project. At the end of every Sprint, stakeholders see new functionality. Models, requirements, and internal artifacts might be of use to the developers, but they are never shown to the stakeholders.

CRACK

An effective Product Owner is:

§  Committed

§  Responsible

§  Authorized

§  Collaborative

§  Knowledgeable

Agile Coach SUCCESS Modes (Healthy Coaching)

1.       The Magician

2.       The Child

3.       The Ear

4.       The Heckler                        (Someone who tries to embarrass you with gibes, questions & objections)

5.       The Wise Fool

6.       The Creeping Vine           (Kind of Plant)

7.       The Dreamer

8.       The Megaphone               (Loudspeaker)

Agile Coach FAILURE Modes (Unhealthy Coaching)

1.       The Spy                                (Watch, observe, or inquire secretly)

2.       The Seagull                         (Bird)

3.       The Opinionator               (Who gives opinion)

4.       The Admin

5.       The Hub                               (Centre)

6.       The Butterfly

7.       The Expert

8.       The Nag                                (Reminder)

Theme/Feature

A set of related user stories may be combined together (usually by a paper clip if working with note cards) and treated as a single entity for either estimating or release planning.

3 C (User Story Characteristics)

§  Card                       – Written description of the story used for planning and as a reminder (3’’ X 5’’)

§  Conversation     – Details of the story come out during conversations with the product owner

§  Confirmation     – Acceptance tests confirm the story was coded correctly

Tracer Bullet (Slice of Cake)

§  A special bullet that lights up the path of firing.

§  User stories should be delivered as a cohesive subset of all layers of a feature, than delivering all of only one layer.

• Example: Deliver partial user interface, partial middle tier and partial database functionality

ARCS

J. M. Keller, an expert in motivation and learning, developed criteria for evaluating instructional designs (Activities).

§  Attention - Choose activities that help people stay engaged so they don’t drift off.

§  Relevance - Those are relevant to the goal.

§  Confident/Competence - You want activities that people can accomplish successfully.

§  Satisfaction - Finally, make sure activities fit into the overall design so people think the retrospective is a good use of their time.

Agile Project Management (Delivery) Framework (APMF)

Envision Phase

§  Product vision, project objectives and its constraints

§  Identifying the stakeholders

§  Identifying how team members will work together

§  Includes iteration 0

Speculate Phase

§  Creating the backlog

§  Creating an iterative feature-based release plan

§  Accounting for risks, costs and other information

Explore Phase

§  Implementing features and stories iteratively

§  Creating a collaborative and self-organizing project community

§  Managing the stakeholder interaction including the customers and product management

Adapt Phase

§  Where the product is subjected to review from customer, people and process perspectives

§  Actual vs. planned analysis is done to feed into the re-planning effort

Close Phase

§  Lessons learned are captured and incorporated for future iterations

Feeding Buffer

The Feeding buffer protects the start date on story items against delays in the completion of another dependent story items.

Throughput

Throughput is the number of features the team can develop in a particular amount of time.

Shu Ha Ri

One good model for mastering anything (if that’s possible) comes from martial arts, a martial arts student progresses through three stages of proficiency called Shu Ha Ri.

Shu        : Follow the rule.

Ha          : Break the rule.

Ri            : Be the rule.

Normative Methodologies

Normative methodologies are based on solutions or sequences of steps known to work for the discipline. Electrical and other building codes in house wiring is examples. In software development, one would include state diagram verification in this category.

Fragmented Knowledge Workers

According to DeMarco, Fragmented knowledge workers may look busy but a lot of their business is just thrashing. The minimum cost penalty is: 15%

Three Coach Styles (CAT)

§  Coaching

§  Advising

§  Teaching

Error-Feedback Ratio

Error-feedback ratio is the number of new defects injected when fixing existing defects (e.g., 20 new defects generated in fixing 100 defects would be an error-feedback ratio of 20%).

Health Checks

Health checks, often in the form of a questionnaire, lists required elements and qualities that jog our minds to help us remember the basic ingredients of agile. Help us determine how well the team is adhering to agile methods.

Adaptability - Three Components

1.       Product

2.       Process

3.       People

Agile Product Lifecycle - The Five Agile Plans

1.       Product Vision                   : Yearly By Product Owner

2.       Product Roadmap            : Bi-Yearly By The Product Owner

3.       Release Plan                       : Quarterly By The Product Owner And Teams

4.       Iteration Plan                     : Bi-Weekly By The Teams

5.       Daily Plan (Scrum)           : Daily By Individual

JBGE Artifacts

Just Barely Good Enough (JBGE) artifacts

Burn-down Bar Charts

The typical Scrum release burn-down chart shows a single value - the net change in the amount of work remaining.

D

B

4

C

A

2

3

1

1.       As tasks are completed, the top of the bar is lowered.

2.       When tasks are added to the original set, the bottom of the bar is lowered.

3.       When tasks are removed from the original set, the bottom of the bar is raised.

4.       When the amount of work involved in a task changes, the top of the bar moves up or down.

There are four simple rules to keep in mind when drawing this type of burn-down chart:

A.      Any time work is completed, the top is lowered.

B.      When work is re-estimated, the top moves up or down.

C.      When new work is added, the bottom is lowered.

D.      When work is removed, the bottom is raised

Agile Chartering

Vision: The vision defines the “Why” of the project. This is the higher purpose, or the reason for the project’s existence.

Mission: This is the “What” of the project and it states what will be done in the project to achieve its higher purpose.

Success Criteria: The success criteria are management tests that describe effects outside of the solution itself.

Customer-Valued Prioritization

1.       High-value, high-risk stories.

2.       High-value, low-risk stories.

3.       Lower-value, low-risk stories.

4.       Low-value, high-risk stories.

DRY

Don't Repeat Yourself

Process - Defined

A process that will produce acceptable quality results repeatedly.

Useful when the underlying mechanisms by which a process operates are reasonably well understood.

Process - Empirical

A process that cannot be repeated due to the inherent complexity needs to adopt this mechanism.

There are three legs that hold up every implementation of empirical process control:

1.       Transparency/Visibility

2.       Inspection

3.       Adaptation

Feature Breakdown Structure (FBS)

§  They allow communication between the customer and the development team in terms both can understand.

§  They allow the customer to prioritize the team's work based on business value.

§  They allow tracking of work against the actual business value produced.

Parking Lot Charts

Parking Lot Charts summarize the top-level project status. It contains a large rectangular box for each theme (or grouping of user stories) in a release.

Shows summary status information in the following format:

§  Theme name

§  Total number of stories in that theme

§  Total number of story points or ideal days for those stories

§  Percent complete for the story points

Scrum Ceremonies/Events

There are four ceremonies:

Sprint Planning                 : Team meets with PO to choose a set of work to deliver during a sprint

Daily Scrum                        : Team meets each day to share struggles and progress

Sprint Reviews                 : Team demonstrates to the PO what has completed during the sprint

Sprint Retrospectives    : Team looks for ways to improve the product and the process

Scrum Time-boxes

Sprint Planning                : 2 sessions of 4 hrs (Selecting Product Backlog & Preparing Sprint Backlog) = 8 hours / 30 days

Sprint Duration                : 1-4 weeks

Daily Scrums                      : 15 minutes / day

Sprint Review                   : (1 hour preparation + 1 hour review)/ 2 weeks = 4 hours / 30 days

Sprint Retrospective      : 3 hours / 30 days

Scrum Artifacts

Product Backlog

§  Product Owner maintains and orders list of requirements

§  Is dynamic and may constantly evolve

§  Has features, functions, fixes, enhancements

§  Attributes - description, order and estimate

§  Ordered by value, risk, priority and necessity

§  Development team and Product Owner collaborate

Sprint Backlog

§  Contains work committed for the upcoming sprint

§  Provides enough detail for tracking during daily scrum

§  Only development team can update and make changes

§  Highly visible; shows real time picture of work

Product Increment

§  Sum of all product backlog items completed to date

§  Must always be in a readily releasable “done” state

Burn-down/up Charts

§  The sprint burn-down chart is a publicly displayed chart showing remaining work in the sprint backlog.

§  Updated every day, it gives a simple view of the sprint progress.

§  It also provides quick visualizations for reference.            

Scaling Projects Using SCRUM

§  Start with a core team

§  Run a few iterations

§  Seed new teams with core team to scale up project

SCRUM of SCRUM’S

§  This is a mechanism used to coordinate multiple teams working on a single project

§  Conduct daily scrum within each teams

§  Then, representatives from each team conduct a daily scrum to help coordination across many teams

Signal Card

English translation of Kanban

Tail

The tail is the time period from “code slush” (true code freezes are rare) or “feature freeze” to actual deployment. This is the time period when companies do some or all of the following: beta testing, regression testing, product integration, integration testing, documentation, defect fixing.

Transition Indicator

A transition indicator is a notification that a risk (i.e., something that will have a negative impact on the cost/schedule of the project if it occurs) has materialized and is in need of attention.

Earned Value Management (EVM)

§  Method of measuring project performance and is a widely recognized project management tool.

§  EVM integrates the areas of scope, schedule and cost to provide metrics for current work done as well as for future work.

SCRUM Roles

Product Owner

The product owner decides what will be built and in which order:

§  Defines the features of the product or desired outcomes of the project

§  Chooses release date and content

§  Ensures profitability (ROI)

§  Prioritizes features/outcomes according to market value

§  Adjusts features/outcomes and priority as needed

§  Accepts or rejects work results

§  Facilitates scrum planning ceremony

Scrum Master

Facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues:

§  Ensures that the team is fully functional and productive

§  Enables close cooperation across all roles and functions

§  Removes barriers

§  Shields the team from external interferences

§  Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning

§  Facilitates the daily scrums

Development Team/Team

Is cross-functional

§  Is right-sized (the ideal size is 7 +- 2, i.e. 5-9 members)

§  Selects the sprint goal and specifies work results

§  Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal

§  Organizes itself and its work

§  Demos work results to the product owner and any other interested parties.

Extreme Programming (XP) Roles

XP Coach

§  The XP Coach role helps a team stay on process and helps the team to learn.

§  A coach brings an outside perspective to help a team see themselves more clearly.

§  The coach will help balance the needs of delivering the project while improving the use of the practices.

§  A coach or team of coaches supports the Customer Team, the Developer Team, and the Organization.

XP Customer

§  The XP Customer role has the responsibility of defining what the right product to build is, determining the order in which features will be built and making sure the product actually works.

§  The XP Customer writes system features in the form of user stories that have business value.

§  Using the planning game, he chooses the order in which the stories will be done by the development team.

§  He also defines acceptance tests that will be run against the system to prove that the system is reliable and does what is required.

§  The customer prioritizes user stories, the team estimates them.

XP Programmer

§  XP Programmer is responsible for implementing the code to support the user stories

XP Programmer (Administrator)

§  The XP Programmer (Administrator) role includes most of the traditional software development technical roles, such as designer, implementer, integrator, and administrator.

XP Tracker

§  The three basic things the XP Tracker will track are the release plan (user stories), the iteration plan (tasks) and the acceptance tests.

§  The tracker can also keep track of other metrics, which may help in solving problems the team is having.

§  A good XP Tracker has the ability to collect the information without disturbing the process significantly.

XP Tester

§  The primary responsibility of the XP Tester is to help the customer define and implement acceptance tests for user stories.

§  The XP Tester is also responsible for running the tests frequently and posting the results for the whole team to see.

§  As the number of tests grows, the XP Tester will likely need to create and maintain some kind of tool to make it easier to define them, run them, and gather the results quickly.

Chickens

People that are not committed to the project and are not accountable for deliveries

I.e. level of involvement (not accountable) rather than commitment.

Pigs

People who are accountable for the project’s success

Single/One Wring-able Neck

This is the Product Owner

Story Splitting Methods

§  Splitting across the CRUD operations (Create, Read, Update and Delete).

§  By separating out any cross-cutting concerns such as security, logging, error handling etc.

§  By removing the performance attributes and put them in a separate story.

DEEP

DEEP criteria are useful for determining if a Product Backlog has been structured in a good way.

§  Detailed appropriately

§  Emergent

§  Estimated

§  Prioritized

Cone of Uncertainty

§  Project risk is high in the initial stages, and hence estimates given early in a project are less accurate

§  Progressive elaboration along with managing uncertainties improves estimation accuracy later in the project

§  Frequent planning and building for what is known reduces overall risk

§  To account for unknowns, estimates should be a range of values

Buffering of Uncertainty

A buffer is a margin for error around an estimate

Feature Buffers

E.g.: Targeting 40 stories for the agreed release date ± 5 features based on the team's velocity

Schedule Buffers

E.g.: Website to complete in 4 months ± 2 weeks depending on team's velocity

Budget Buffers

E.g.: For the given stories, the project will cost $200,000 ± $15,000

LEAN 5 S

1.       Sort

2.       Set-in-Order / Straighten

3.       Shine

4.       Standardize

5.       Sustain

Customer Valued Prioritization

Analytical Hierarchical Process (AHP)

Here the customers give relative ranking to each requirement comparing it pair-wise; this is to reduce any bias.

Forced Ranking Technique (FRT)

Stakeholders rank all requirements in order of importance, while assigning a unique number to each.

Weight Based Prioritization Technique

By weighting each feature based on their importance.

100 Point Method

Stakeholders have to value and ‘buy’ features based on how important the feature is.

Value Proposition

Statement of features with unique value, utility and tangible results for a customer to consider buying based on their perception.

Estimating Techniques

Expert opinion   - Knowledge of Subject Matter Experts

Analogy                - Comparing with other stories. Relative sizing better than absolute sizing

Triangulation     - Where a story being estimated is compared against a set of other stories

Disaggregation  - Splitting a story into smaller pieces for better estimating

Planning Poker  - Combination of various methods, product owner clarifies, but doesn’t estimate

Planning Horizon (Onion)

Scaling Scrum

Scrum scales by adding more scrum teams. When more than one Scrum Team works simultaneously on a project, it is referred to as a scaled project, and the mechanisms employed to coordinate the work of these teams are called scaling mechanisms.

Requirements for Scaling

§  Appropriate infrastructure

§  Detailed product and technical architecture must be constructed

§  Distributed, high-bandwidth technology for source code sharing, synchronized builds, and alternative communications such as instant messaging must be employed.

Non-Functional Requirements for Scaling

The non-functional requirements to build the scaling infrastructure are given high priority in the Product Backlog and are mixed with top-priority business functionality, and sometimes even outrank that functionality and are developed prior to or in parallel with the business functionality.

Staging

The process of defining and prioritizing the non-functional requirements for scaling is called staging. Staging occurs prior to the start of the first Sprint and takes just one day.

Technical Debt (Gaps)

Technical debt is anything that should have been done as part of a development process but wasn’t. This includes test cases, bugs that were not resolved, un-refactored code, missing documentation, and even process debt (gaps). This debt is like any other debt—you keep paying on it. By incurring this debt, the team and systems are mortgaging your future in the following ways:

§  Technical debt slows down our velocity.

§  Technical debt causes more issues in the long run due to ‘‘workarounds’’.

§  Technical debt breaks processes and creates instability in releases.

§  Technical debt causes uncertainty.

§  Technical debt is a progress killer.

Categorize Requirements with FURPS

§  Functionality      - User features your customer wants.

§  Usability               - Product effectiveness, aesthetics, documentation, etc.

§  Reliability            - Failover, downtime, recovery, system accuracy, etc.

§  Performance      - Max response time, throughput, memory consumption, etc.

§  Supportability    - Testability, serviceability, monitor-ability, extensibility, etc.

7 Types of LEAN Waste

“LEAN” is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. LEAN manufacturing is a management philosophy derived mostly from the Toyota Production System (TPS) and the original main 7 types of Production & software wastes respectively are:

1.       Transportation

2.       Inventory

3.       Motion

4.       Waiting

5.       Over-production

6.       Over-processing

7.       Defects

1.       Partially Done Work

2.       Paperwork

3.       Extra Features

4.       Task Switching

5.       Handoffs

6.       Delays

7.       Defects

Extra Motion

If excessive or unnecessary emails and document get forwarded multiple times sometimes with large attachments due to multiple distribution groups, it constitutes waste of type motion.

Extra Transportationon

It refers to unnecessary motion or movement of raw materials or goods such, as work-in-process (WIP) is being transported from one operation to another.

Jidoka (Autonomation)

Jidoka is a Japanese term used for autonomation means “intelligent automation” or “humanized automation.” In practice, it means that an automated process is sufficiently “aware” of itself so that it will detect when the desired quality is produced, detect process malfunctions, detect product defects, stop itself and alert the operator. A future goal of autonomation is self-correction.

Taiichi Ohno - Kanban

Taiichi Ohno was inspired by the American supermarket’s working and applied to auto industry. The technique is called Kanban that means Signboard.

Sidky Agile Measurement Index (SAMI)

Provides a framework for moving your enterprise to an agile mentality.

YAGNI

“You Arent Gonna Need It” a general refrain in Agile XP when someone suggests building functionality for the system that isn't required by any current user story.

Actual Percent Complete (APC)

Total number of story points completed divided by the total number of story points planned

Reciprocal Commitment

In Scrum, the notion of a reciprocal commitment refers to the team's commitment to delivering some specified amount of functionality and the business's commitment to not changing priorities during the sprint.

Project Data Sheet (PDS)

Is a single-page summary of key business objective, product specification, and project management information. Document to help focus the project team, management and customers

Typical sections of the project data sheet include:

§  Clients/Customers: a list of the key clients or customers

§  Project Leader/Manager

§  Product Manager

§  Executive Sponsor

§  Project Objective Statement (POS): a specific, short (25 or fewer words) statement that includes important scope, schedule, and resource information from the trade-off matrix

§  Trade-Off Matrix (TOM): a table that establishes the relative priorities of project scope, resources, schedule, and defects—with one and only one of these established as the highest priority

§  Exploration Factor: a measure (1 to 10) of the risk and uncertainty of the project

§  Delay Cost: the daily, weekly, or monthly cost of project delay (particularly useful when schedule is the highest priority)

§  Capabilities

§  Features: a list of the key features

§  Client Benefits: the key benefits and/or selling points of the product

§  Quality Objectives

§  Performance/Quality Attributes: a list of the key performance and quality attributes of the product

§  Architecture Guidelines: key architectural components of the product (platform, component, interface, module)

§  Issues/Risks: factors that could adversely impact this project

T-Shaped Skills

Release Train

A release train is an approach to aligning the vision, planning, and interdependencies of many teams by providing cross-team synchronization based on a common cadence (rhythm). A release train focuses on fast, flexible flow at the level of a larger product.

Hardening

Many agile teams will set aside iteration at the end of the project to use for "hardening", which refers to the preparation for final roll-out of the product. As team skills mature, the need for a hardening

Sprint should diminish.

Last Responsible Moment (LRM)

A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision. Always remember principle of last responsible moment; in agile we do things at last responsible moment.

Minimum Viable Product (MVP)

A product that has just those features that allows the product to be deployed, and no more.

Minimum Releasable Features (MRF) / Must Have Features

§  The minimum set of features that must be present in a release to make it viable (useful enough) to end customers such that they want it and would be willing to pay for it.

§  Features composed from a collection of minimum marketable features.

Minimum Marketable Features (MMF)

The smallest or minimum set of functionality related to a feature that must be delivered for the customer to perceive value (for it to be marketable). Contrast with minimum releasable features.

Musketeer (Foot Soldier) Attitude

Attitude among members of a team that they are all in the same boat and that they will win or lose together as a team.

WaterScrum / Scrummerfall

Overlaying waterfall-style development on the Scrum framework. An example would be performing an analysis sprint, followed by a design sprint, followed by a coding sprint, followed by a testing sprint.

Mindfulness

Agility—the ability to respond effectively to change—requires that everyone pay attention to the process and practices of development, this is mindfulness.

Exploratory Testing

Exploratory testing is an approach to testing that emphasizes the freedom and responsibility of each tester to continually optimize the value of his work by treating learning, test design, and test execution as mutually supportive activities that run in parallel throughout the project. (Generally via scripts).

Exploratory testers use the following four tools to explore the software:

·         Tool #1: Charters

·         Tool #2: Observation

·         Tool #3: Note-Taking

·         Tool #4: Heuristics (using experience to learn and improve)

In XP all testing are automated, the only manual testing, an XP team may perform is the Exploratory testing.

Ruthless Testing

Ruthless testing is all about developers doing absolutely everything in their power to ensure that their software is as heavily tested as it can be before the software reaches people, both QA and customers.

One of the most crucial practices of sustainable development. It is primarily about automated testing.

Lean/Agile Testing

In lean agile the testing is done to improve the process and quality. The testing activity should discover the causes of errors and eliminate them. Root-cause analysis is part of the testing’s portfolio of work. In lean we work with a principle-build quality so that the process should ensure we develop quality products, testing alone cannot ensure that we deliver good quality products to the user.

Product Champion

Someone who makes the decisions about which products to create or enhance. Product companies may use the term “program manager” or “product manager.” IT organizations may call this role the “sponsor.” Practical experience from the field suggests that the Product Champion role comprises a team of product managers, business stakeholders, business analysts, and client-facing personnel who are committed to providing the required service levels of feedback and validation so that the development organization can move quickly.

Fast-Flexible-Flow

A primary goal of Lean is to optimize the whole with speed and sustainability. This can be summarized as “Fast-Flexible-Flow,” which is the fundamental phrase used in Womack & Jones.

Pull System

Showing dependencies of one task on others is not a characteristic of an agile plan. Since in agile we focus on creating a pull system rather than push system and we start with a top level plan first. Pull System implementation in scrum is done using/creating sprint backlog, task board and daily stand-up.

Slack

XP recommends that in any plan it is better to include some minor tasks that can be dropped if you get behind. You can always add more stories later and deliver more than you promised.

Carl Larson & Frank LaFasto

In high-performance teams, “The leaders managed the principles, and the principles managed the team.”

Qualitative Risk Analysis

Agile team follows Qualitative Risk Analysis which usually involves calculation of risk impact in monetary terms like Expected Monitory Value (EMV)

Trim Tabs

Trim tabs are those things that require little effort to produce a large effect.

Extreme Character Persona

They are exaggerated personalities; their system needs are extremely different from the mass.

Closed Story

A closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished something.

Compound Story/Component Story

An epic that comprises multiple shorter stories

Complex Story

User story that is inherently large and cannot easily be disaggregated into a set of constituent stories.

Five Core Risk Areas Common To All Projects

Tom DeMarco and Tim Lister identified five core risk areas common to all projects in their book, Waltzing with Bears:

1.       Intrinsic/Inherent Schedule Flaw - Estimates that are wrong and undoable from day one, often based on wishful thinking

2.       Specification Breakdown - Failure to achieve stakeholder consensus on what to build

3.       Scope Creep - Additional requirements that inflate the initially accepted set

4.       Personnel Loss / Employee Turnover

5.       Productivity Variation - Difference between assumed and actual performance

Agile Coach/ ScrumMaster Roles

Bulldozer                            : Helps team bulldoze impediments out of the team’s way

Shepherd                            : Guiding the team back to agile practices and principles when they stray

Guardian                             : Of quality and performance

Servant Leader                 : Serving the team rather than the team serving you

Elevations

It’s a release which is not quite real, mean it is not meant for the customers.

Karl Wiegers Approach for Relative Weighting

Relative Penalty of the absence of the feature(s)

Lean / Kanban / Agile

Lean is the theory à Kanban is an approach à Agile is the result

Decision Making Styles

§  Command

§  Consensus

§  Consultative

Conflict Resolution: The Thomas-Kilmann Model

Whole-Team and Individual Coaching Interventions during the Sprint

Buffer Sprint

Sprint in the last release of a project that allows the agile team to address any final finishing features.

ROAM

Few Additional Tips:

§  If SCRUM team is > 9, then break/divide the team for daily stand-ups or any SCRUM ceremonies

§  If SCRUM then Product Owner, if written user stories it means XP then Customer

§  In Lean there is one chart called Business Value Delivered chart, made by using Release & Feature Burn-Up Charts together, and is also a best tool for tracking the progress of the project and evaluating the ROI

§  The Product Owner must prepare the Product Backlog prior to the meeting. In the absence of either the Product Owner or the Product Backlog, the Scrum Master is required to construct an adequate Product Backlog prior to the meeting and to stand in for the Product Owner

§  The best time to measure EVM in Agile projects is During Iteration

§  As per SCRUM 10% of sprint time team can spend on backlog refinement or Grooming Product Backlog

§  Erratic Requirements depict a situation in which the product vision is understood, but the business or product requirements are fuzzy

§  Five Scrum Values

§  Openness           (Replaced With Simplicity from XP)

§  Commitment

§  Focus                    (Replaced With Feedback from XP)

§  Courage

§  Respect

§  Length of the XP iteration is 1-3 Weeks

§  Complex rules and regulations give rise to Simple, stupid behaviour

§  Evolution is an emergent process fuelled by experimentation

§  An agile release can be internal, external or a forecast

§  SCRUM - Release planning is optional but highly encouraged; iteration planning is required

§  A list of the risks your project faces that focuses on your project's unique risks is a risk census

§  Agile treats quality as non-negotiable

§  A Scrum Master is often compared to a sheepdog, responsible for keeping the flock together and the wolves away

§  Product owner ensures work is aligned with leadership's direction and product vision

§  One of the best ways to visually display risks in a succinct manner is to use a Risk Map. On the vertical (Y) axis you have the probability of a given risk occurring, that is, the likelihood that the risk will materialize and become an Issue. On the horizontal (X) axis we have the impact that the risk will have on the project or program should it materialize.

§  The Product Owner is responsible for:

o   Managing the release scope and date

o   Managing the budget

o   Communicating progress

o   Managing the stakeholders

§  A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master

§  Component Tests verify that units and combinations of units work together to perform the desired operations

§  Quantity of function is scope measured in terms of user stories, use cases, requirements, or features

§  Wave is the Product Planning structure with Medium range time frame (3 months) or intermediate points, with Story level capability and Capability commitment

§  Surprise Retrospective is conducted when an unexpected event changes your situation

§  A team's average velocity and the burn-down chart are two of the most important measurements of progress against the release backlog

§  Agile processes do not track duration, because the duration is always the same—it's the length of the iteration. Only work effort is tracked, at the task level

§  Quality in the product is monitored by automated tests and confirmed by customer acceptance; quality in the process is monitored by metrics and confirmed by the review and retrospective "audit."

§  Burn-down charts and root cause analysis are standard quality control tools used in agile

§  Risk management can be both organic (intrinsic in the process framework) and overt (addressed by specific activities)

§  Seven components/elements of Emotional Intelligence by Higgs & Dulewicz:

o   Self Awareness

o   Emotional Resilience

o   Interpersonal Sensitivity

o   Motivation

o   Influence

o   Intuitiveness

o   Conscientiousness

§  Swarm Intelligence (SI) is the collective behaviour of decentralized, self-organized systems, natural or artificial. (Swarm = Group)

§  Sources of Return/Revenue:

o   New Revenue                                                   (coming out of new customer)

o   Incremental Revenue                                    (comes from already existing customer)

o   Operational Efficiency Revenue                 (obtained by improving operational process)

o   Retained Revenue                                           (org. will lose if the project is not developed)

§  The Unified Process divides the project into four phases:

o   Inception

o   Elaboration

o   Construction

o   Transition

§  Reducing the risks of agile adoption using assessments:

o   Management Style - Whether a collaborative or a command-control relation exists between managers and subordinates. The management style indicates whether management trusts the developers and vice versa.

o   Manager Buy-In - Whether management supports or resists having a collaborative environment.

o   Power Distance - Whether people are intimidated by / afraid to participate and be honest in the presence of their managers.

o   Developer Buy-In - Whether the developers are willing to plan in a collaborative environment.

§  The Primary Differences between a Release Plan and an Iteration Plan:

§  Five Core Metrics used by the SLIM Model:

§  Productivity                       (Functionality produced for the time and effort)

§  Time                                      (Duration of the project in calendar months)

§  Effort                                    (Amount of effort expended in person months)

§  Reliability                           (Defect rate)

§  Quality of Function         (Scope measured in terms of user stories, use cases, requirements, features)

§  Gold Plating is a type of scope creep that can be a significant problem

§  Creating a Self-Organizing Team entails (involves):

o   Getting the right people

o   Articulating the product vision, boundaries, and team roles

o   Encouraging collaboration

o   Insisting on accountability

o   Fostering self-discipline - steering rather than control

§  Agile Project Management is an execution-biased model