Methodologies

- A set of processes and practices performed on a specific way in order to accomplish a project.

- A way of working within the rules to achieve results and goals, and it needs to provide focus for
planning for result while being flexible and adaptable to the present situation.

Traditional waterfall projects…Anticipation

- Much of waterfall came into being with the Deming Cycle of Plan-Do-Check-Act.

- Rely on a heavy up-front analysis and documentation.

- System Development Life Cycle SDLC: Phases; analysis, design, implementation, testing, and
evaluation carried out in each phase.

- Projects became rigid and resistant to change, even if that change is good for the project.

- Become more interested in how something is done rather than why or what results.

- Requires sign off on documents by customers at early stages of the project.

The Agile way ….Adaptation fast moving and time constrained projects

- Teams are no longer organized hierarchically with directions coming from the top to down.

- Self organized team with no formal project manager.

- Work is distributed by consensus rather than by authority.

- Project makes decisions as a team with a continued focus on delivering value to customer.

- Daily stand up meeting held each morning (what did team member work yesterday, what will
work today, what obstacles they are encountering).

- Poor performance and other problems are solved internally instead of escalating.

- Welcome change any time even late in the project or affect the architecture.

- Team will meet, evaluate the change, and look at the impact and ways to incorporate the
change to the project.

- Customer involvement (participate meetings – communicate priorities).

- Work is delivered in small, frequent releases (team focus- allow rapid feedback – fast
integration).

- Retrospective meeting after each release or iteration or sprint to discuss what went well and
what did not to improve in the next sprint (iteration).

- The retrospective meeting on previous iteration should be maximum of one hour.

- Sequence: set the stage, gather data, generate Insights, decide on what to do, and close the
retrospective.
Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work, we have come to value:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Individuals and interactions over processes and tools

- Individuals who choose the appropriate processes & tools for given project, follow these
processes and make right use of these tools.

- If processes are too heavy to follow or individuals are not engaged enough to follow these,
processes would simply fail to work.

- Without much of processes and tools, there is a good possibility that a group of skilled and
motivated individuals will deliver the successful project. However, vice-versa is not true. For e.g.
we may have a robust review process but imagine what would happen to the quality, if one
novice is reviewing the work of other novice. Or reviewer is not motivated to do a critical review
and doing it casually just for the sake of process compliance.

Working software over comprehensive documentation

- Software without good documentation is problematic from maintenance & support point of
view. However, comprehensive documentation without software has no business value. [Given
a choice, would you pick a primitive video game or a detailed user guide for an advance video
game?]

- User would be in much better position to provide feedback on working software even with less
number of features, than with large document detailing all the features & usage scenarios.

- Documentation is to help driving common understanding and assist in the process of

developing working software. However, primary goal is still to develop working software.

- Progress on an agile project is tracked and reported by how much working software is
developed over time.

- A document expressed what is intended but as the saying goes, “Nothing speaks louder than
the code”.

Customer collaboration over contract negotiation

- Our sole purpose of doing the project is customer can realize business value. Only customer
can tell what they want, then isn’t it fair to listen to them and be flexible about their needs.
- It is difficult for customer to define an upfront and unchanging view of what should be built.

- Successful developers work closely with their customers, they invest the effort to discover
what their customers need, and they educate their customers along the way.

- The closer you are to your customer, the better.

- Agile has you and your customer at the same side of the table.

Responding to change over following a plan

- Changes can come from various factors. Customer priorities may change or customer may just
get a better idea to improve ROI. Market/Business may change. Technology can change. It
could just be a result of improved understanding of problem domain.

- Rather than sticking to the original plan, we should respond to the inevitable changes.
Moreover, we should be flexible about changes, which help in reducing the risk and maximizing
ROI.

- This doesn’t mean we should not have a plan. Instead of suppressing changes and sticking to a
static plan, we need to acknowledge that things will change. We need to accommodate the
changes, which help in meeting key project & business objectives.

The Twelve Principles of Agile Manifesto

1- Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.

- Valuable software here means working product or prototype - something that customer can
easily understand & appreciate. Deliverables such as design document or software code have no
meaning for customer. The focus is on the end goal, which is working product.

- Early and continuous delivery of valuable software not only gives confidence to the customer
but also provides opportunity to receive customer feedback so that we build what is right for
the customer rather than what was specified initially.

2- Welcome changing requirements, even late in development. Agile processes harness

change for the customer's competitive advantage.
- Let’s take an example. We are building a product and then realize competitors have launched a
product with similar features. Unless we add some other exciting features in the product,
launching that product would be just waste of time and money.

- Traditional change management processes were designed to prevent/reduce scope creep.

However, nowadays these processes are generally so rigid that these actually tend to suppress
changes.

- Agile processes acknowledge the fact that change will happen and provides an effective way to
deal with them by using a value driven iterative development approach.

3- Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter time scale.
- More frequent delivery of working software so that there are more opportunities for
stakeholders to provide feedback, which reduces the risk of going too far down the wrong track.

- More frequent delivery improves customer’s confidence. Often in a demo meeting, team
learns of new requirements or changes in business priorities, which are important for improved
ROI.

4- Business people and developers must work together daily throughout the project.
- When team works closing with business, team understands the business in a way that is far
beyond the typical requirement collection mechanisms. Scope creep due to missing
requirements and incorrect interpretation of requirement reduces drastically.

- Frequent demos to business people are another example of close working together.

- In some cases it’s not really feasible to have business people literally available daily. But agile
methods try to get as close collaboration as possible.

- Some teams use an experienced business domain expert as “proxy customer”. While this can
help development but this should not be a replacement of customer interaction.

5- Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
- Too many organizations just hire people and think that these would make build successful
software with help of heavy process framework. This doesn't seem to work all that well in
practice.

- A team of motivated individuals doesn’t require micro-management and project manager can
focus on removing impediments rather than doing day to day task management.

- Agile teams, realize that you need to build teams from people who are willing to work together
collaboratively and learn from each other. In these kinds of teams, continuous improvement
never stops.

6- The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
- Exchange of information through e-mails or by sharing information is slow and effort
consuming mechanism. Still the interpretation may go wrong. A quick talk over the phone can
achieve results much faster and better.

- Face to face talk is even better as along with information, emotions, body language can also be
conveyed, which not only makes the information exchange even quicker & better but also helps
in reducing conflicts.

- In face-to-face conversation, you can quickly draw diagrams and have wide range of
techniques to express complex ideas.
7- Working software is the primary measure of progress.
Traditional approaches use documents or other forms of intermediate deliverables as measure
of progress. There are following issues with that:-

- Focus gets shifted from working software which is ultimate goal, to these intermediate
deliverables.

- We might show percentage completion or Earned value by measuring progress in terms of

intermediate deliverables but until we show the working software to business and confirm that
it meets the customer requirement, there are chances that we are just going on wrong track.

- What if project has to be stopped in the middle, we might have a high earned value and x% of
work completion but without any working product, is there any value for customer? In case of
working software, customer may still make some use of features delivered till then.

8- Agile processes promote sustainable development.

- Agile believes in a sustainable work pace rather working long hours just before key milestones.
XP recommends 40-hours work week.

- A sustainable work pace is better for team members for their work-life balance. It also benefits
the business because un-necessary stretch reduces the motivation levels and increases the risk
of people resigning. Hiring and training the people is a very costly affair.

- 8 hours work with full focus and attention is better than 12 hours of mediocre work. There are
chances of poor quality and rework later on, which will actually reduce the overall output.

9- Continuous attention to technical excellence and good design enhances agility.

- It's much easier to understand, maintain, and evolve high-quality source code and a good
scalable design, than it is to work with rigid design & low-quality code.

- Agilest recommend a range of design & code development principles & practices for technical
excellence.

10- Simplicity – the art of maximizing the amount of work not done – is essential.
- Agile developers ask themselves “what is the simplest thing that could possibly work”.

- Rather than anticipating changes and adding numerous additional features or extensibility
hooks, agile developers create a simple and clean design. Un-intuitively, this results in designs
that are ready for any change, anticipated or not.

- Agile developers have strong focus on automation and reusability.

11- The best architectures, requirements, and designs emerge from self-organizing teams.
- A self-organizing team is naturally motivated to continuously find better solutions and improve
ways of working.

- We may get number of ideas from experts outside the team but unless ideas are well
understood and well implemented by the team, purpose is defeated. Team is closed to technical
details and can choose which idea would actually work in project.
12- At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
- Gathering lesson learnt at the end of project might add to organization’s lesson learnt / best
practices repository but it’s too late for the project. In fact, these lessons learnt are rarely being
used much in practice – one because every project is different and second because people tend
to learn more from their own experiences than someone else’s experiences.

- Agile projects often conducts sessions (called as retrospectives), typically after every iteration
to learn from past and adapt.

- The beauty of iterative development is there are ample opportunities to learn from previous
experiences and continuously improve. The key is to have that focus on reflection and taking
concrete actions from learning.

- Also the daily stand up meeting (15m) helps to assess and improve performance.

---------------------------------------------------------------------

Declaration of Interdependence
The Declaration of Interdependence, to guide software project management according to agile
development methods. The principles of declaration of Interdependence are:

- Increase return on investment by making continuous flow of value our focus.

- Deliver reliable results by engaging customers in frequent interactions and shared ownership.

- Expect uncertainty and manage for it through iterations, anticipation and adaptation.

- Unleash creativity and innovation by recognizing that individuals are the ultimate source of
value and creating an environment where they can make a difference.

- Boost performance through group accountability for results and shared responsibility for team
effectiveness.

- Improve effectiveness and reliability through situationally specific strategies, processes and
practices.
Project justification

Value based prioritization

- Project value for customer is given a financial number.

- Which project makes sense (opportunities).

Present value PV

- Time value of money.

- An amount of money today, or the current value of a future cash flow.

- Bigger is better.

Future Value: An amount of money at some future time period.

Net Present value NPV

- factored in the cost of a project.

- The expected net monetary gain or loss from a project by discounting all the expected future
cash inflows and outflows to the present point in time.

Interest Rate: The compensation paid to a lender (or saver) for the use of funds, expressed as a
percentage for a period (normally expressed as an annual rate).

Internal Rate of return RRI

- The interest rate at which the Net Present Value becomes zero.

- The minimum threshold a project must exceed to be considered viable.

- Bigger is better.

Return on Investment ROI

- A percentage that shows what return you make by investing in something.

- Performance measure used to evaluate the efficiency of an investment or to compare the

efficiency of a number of different investments.

- (benefit – cost) / cost

- Bigger is better.

Payback period: is the amount of time it will take to recoup, in the form of net cash inflows, the
net amount invested in a project.

- Retained revenue refers to the revenue an organization will lose if the project is not
performed.

- New Revenue is the revenue from a new opportunity after a project is completed.
Compliance

- With regulations and it is not optional.

Chartering

- A charter is very important document to Agile team (Exception).

- Used in both traditionally and Agile projects.

- Formally starts the project, name the PM, and gives him Authority to apply resources.

- Should be written as a part of Iteration Zero if it doesn’t already exist.

- Should explain the need of the project.

- Signed by senior management.

- High level project requirements, success factors, and milestones.

- intended to be lightweight and is not intended to be based on a standard template.

Teams & Team Space

Self-Organization of Teams

- Self-organization is central to an agile project.

- Aided by the Coach or the Scrum Master.

- Roles must move from directing and controlling the team to coaching and facilitating.

- A skilled Coach might ask questions to introduce some conflicts in order to help the team learn
this skill.

- Requires mature team members who can compromise, resolve conflicts, and work toward a
common goal.

- Extends to every part of the project; communications, team meetings, reporting, testing,
bringing on new team members, and how to determine when work is “Done”.

- All team members are collectively responsible for everything.

- Provide a way for the team to succeed, fail, adjust, and improve together.

Optimal Team Size

- Large projects has to be broken up into sup-projects, and the team has to be divided.

- Scrum: the team size should be 7+- 2.

Colocation

- Bringing all the team members (members who actually contribute to the project) together in
one place, also remove barriers in the room.

- Allowing people to freely see, hear, and interact with each other.

- Discourage using headphones or anything that might isolate them from the rest of the group.

- Information radiators; features list, backlogs and task lists, user stories, and white boards.

- Virtual team can use software that simulates a live presence.

Team Selection

- Seasoned, skilled, and highly self-directed people, who are willing to work as a part of a team,
and preferably have agile environment experience.

- Team members should be involved in interviewing and selecting new team members.

Team Participation

- Each team member expected to make a positive, measurable contribution to overall success of
the project.

- Each team member’s contribution is visible to the entire team.

Organizational Support

- Support is coming from within and outside the team.

- Support is created when the right people are involved early in the project.

- The customer or Product owner is another source of support.

Agile Tooling

- High-tech or low-tech to increase communication and to encourage participation and

motivation among team members.

- Web cameras, daily stand up meetings, and other activities designed to create a sense of team
and community.

Building Empowered Teams

- The team makes decisions, sets the priority of work, the time frames, and even the makeup of
the team itself.

- In order to build empowered team, it is important to have the customer or product owner be
located with the team.

- Lean management; the best person to make the decision is the one whose hands are actually
doing the work.
- In order to create empowered team, the following are needed:

- Organizational buy-in.

- Alignment with corporate goals.

- A shared vision.

- Clear communication.

- Customer involvement.

- Team accountability to the goals they have set.

Ground Rules

- Unwritten rules about expectations on the project and should be communicated clearly so that
everyone knows what is expected of them.

- For example; what time everyone shows up for work.

Agile Planning

Identifying the right stakeholders

- Anyone with an interest in the project.

- Agile treats team members as a different group.

- The customer often collocated with the team members, so stakeholders influence is high.

- The customer or Product owner acts as the single voice of the users and communicates with
other stakeholders.

Analysis

- Understanding the problem and the underlying need before starting coding.

- Go straight to the customer to get the information first hand (Individual & Customer
collaboration).

- Traditional techniques still exists beside face-to-face communications (high bandwidth comm.)

Brainstorming

- A tool to generate ideas in a rapid-fire and inclusive environment.

- Ideas are evaluated and discussed after they have all been gathered.

- Fosters creativity, and involves the entire team in the process.

Innovation games
1- 20/20 Vision

- Features are posted as cards on the wall in no order, and the facilitator begins with one card
and proceed randomly through other cards until all of them are put into order.

2- The Apprentice

- An engineer or product developer uses the product as an end-user. For example, if the system
is used for data entry, the developer enters data for a couple of days.

- Observers record the engineer’s actions, expressions, comments, and suggestions.

3- Buy a feature

- Stakeholders are shown features and estimated prices for their development.

- The stakeholders have a finite sum of imaginary cash to buy some (but not all) of the features.

- This will help the product owner and the team to understand the importance of these features.

4- Product Box

- Stakeholders are asked to design a retail box that would entice others to buy this product.

- Highlight the features they believe are most important to consumers.

5- Prune the product tree

- Draw a tree on a large poster board or flip chart.

- Gather a group of no more than 5 to 10 people for this exercise – internal team members or
customers.
- Create leaves representing each of your product’s existing features or attributes and arrange
them near the trunk of the tree, one feature per leaf.

- Provide a supply of blank leaves that participants can use to write down new product ideas.

- Existing features should therefore go near the trunk, as they are the oldest. The next closest
leaves represent features to add in the near term. Leaves on the outer edges of the tree, at the
edge of the canopy, are considered to be longer-term ideas.

- Invite your coworkers or customers to add new ideas to the tree, using the blank leaves. You
may also want to invite participants to remove one or more existing leaves from the tree,
representing features that they think should be eliminated from the current product.

- Encourage participants to discuss the placement of leaves, both for existing features and new
ones. This debate will help the team to reach consensus on the desirability and timing of
product features and attributes.

- You may want to display the tree in a common area of your office for a while after the
brainstorming session, because it is very likely that team members will think of additional ideas
days or weeks after the session.

6 - 100-Point Method

- The 100-Point Method is a voting scheme where each stakeholder is given 100 points to use
for voting in favor of the most important requirements and can distribute the 100 points in any
way desired.

Root Cause Analysis

- Looks beyond the symptoms to get the core issue that is causing the problem.

- Cause and effect diagram also known as Ishikawa diagram or Fishbone diagram.

- There is a practice of asking 5 WHYs to find the root cause (Toyota systems).
Force field Analysis

- Analyze the change and understand the forces for and against it.

- Once the primary forces on both sides are identified a ranking from 1 to 4 is assigned.

Parking Lot Chart

- used during requirements gathering to keep discussion focused and productive.

- A piece of paper posted on wall.

- Useful when a stakeholder during gathering requirements came with a point may be important
but off topic.

- The team decide to “Park” it and revisit after the exercise.

Planning & Estimating with Agile

Accuracy of estimates

- Cone of uncertainty: estimates should get sharper over time.

Customer Value

- making decisions based on customer value is a highly favored concept in Agile.

Product vision statement

- Product owner develop it early.

- Describe what is the project, who would need it, the key reasons someone would pay for it,
and what differentiates it in the marketplace.

Product Roadmap

- An overview that shows each planned release and the relevant features associated with those
releases (Communication tool).

- Often publicly posted in the team space or in common, highly visible area.

- Some stakeholders may want more detail than the vision statement provides, but not the
overwhelming detail of the release and iteration plans. For these stakeholders, consider
maintaining a document or slide deck that summarizes planned releases and the significant
features in each one.

Personas and extreme Personas

- Not all users have the same needs or use the product in the same way.

- Personas help to understand end users and stakeholders need.

- Agile creating a fictional persona for each role.

- make user story more applicable, for example small clerk need easy system while seniors need
shortcuts.

- Some agile practitioners maintain that it is best to imagine extreme characters when creating
personas to ensure that as many user stories are imagined and captured as possible. These
“Extreme personas” can help capture requirements that might otherwise be missed.

Wireframes

- Agile projects don’t produce a lot of project-related documentation.

- Wireframe may be hand-drawn or computer-rendered illustration showing how the user will
interact with the system.

- Wireframes is a low fidelity prototype that shows a skeleton of a screen representing its
structure and basic layout.

- Each item is numbered, and all related details are commented on according to the numbers.

- The purpose is to give both the user and the developer a starting point to create a useful
system as efficiently as possible.

Agile Themes

- Theme is a set of related user stories that can be combined and treated as a single entity for
either estimating or release planning.

- Assign a theme to an iteration.

- for example, the theme for third iteration might be “Reporting” or “connectivity” indicating
that most of the functionality will center around those items.

- Forecasting the financial value of a theme is the responsibility of the product owner.

Epic Stories (Capabilities)

- Epics are large user stories with lower priority. They are too big to implement in a single
iteration and therefore they need to be disaggregated into smaller user stories at some point.
- Epic stories are lower down in the product backlog.

User Stories and Story cards

- A user story should be sized that it can be completed by one person and be completed in less
than one to two days.

- A feature is something the product can do or help do.

- 3 components : Card – Conversation – Confirmation CCC.

- Feature might be complex and contain many user stories.

- A common agile practice is to write down stories on note cards (story card).

- Cards may be passed around, ranked, put into order, stuck on wall,…

- eXtreme programming XP describes 6 attributes of a user story (INVEST).

(I)ndependent : Stand on their own and don’t overlap with other user stories.

(N)egotiable : expected to change and grow through collaboration between the customer and
the team.

(V)alubale: need to be viewed from the perspective of the value it will deliver to the customer.

(E)stimable: should have adequate information for the team to be able to estimate the efforts.

(S)mall: small enough to be useful and easily grasped, estimated, and able to be consumed by
the team.

(T)estable: have clearly-defined acceptance criteria.

Story maps

- Traditional project management use WBS to break down large and complex user stories
(Decomposition).

- Agile use Agile story map to break down user stories through (Disaggregation).
- Agile project management puts less of an emphasis on up-front estimating and planning and
more energy toward creating and responding to change.

- The vertical axis shows the priority of the stories and the horizontal axis shows the stories
needed by the business.

Features

- A feature is something that adds value to the customer.

- Expressed in “Verb Noun”:

Change Sale quantity, Apply discount, Calculate Sale tax,…

- The priority of the feature is determined by dividing the priority % by the cost %. Feature X has
a value of 12 and the total value of all features is 35. If the feature is estimated to cost 56%
Hence the answer = (12/35)/(0.56) = 0.61.

Minimal Marketable Feature (MMF)

- The smallest grouping of functionality that can add value to the user.

- Larger than a user story but it should be as small as possible.

- Gold plating occurs when more than the MMF is completed.

- Example: MMF may allow user to generate, view, and print a report. Without any of these
functions, the MMF may lack value, but when the 3 are put together they create value.

- It is the customer or product owner to define MMFs.

- Determine the MMF, Introduce Slack, Manage Change, Increase the MMF, and Accommodate
the New Feature.

Tasks

- “Engineering tasks”: the specific activities the team will undertake in order to add value to a
system.

- A user story could break down into a handful of actual tasks.

- Team of work responsible for tasks distribution, not like PM in traditional.

Value Stream mapping

- Value stream map is a sophisticated flow charting method that uses symbols, metrics, and
arrows to help visualize processes and track performance. This method helps determine which
steps add value and which do not.

- A way to analyze an entire chain of processes with the goal of eliminating waste.

- Give the analyst a deeper understanding of the system by mapping out it.
- A lean technique used to analyze the flow of materials and information through the system
and to identify and eliminate waste.

- Spaghetti diagrams show the flow of materials through various areas, departments, or physical
spaces.

- A SIPOC diagram is a high level process map that provides an overview the entire process,
from supplier to customer.

- Swimlane diagrams are more useful for demonstrating roles and responsibilities

- Process Cycle Efficiency = Total Value Add Time/ Total Cycle Time

Progressive Elaboration

- You don’t know all characteristics about a product when you begin the project, iteration,
sprint, or story map.

- The characteristics may be revisited often and refined. (Gather some requirements, design,
feedback, then gather more)

Rolling Wave planning

- Plan in stages.

- Details will emerge, as the team gets closer to the functionality.

Test-First Development

- The philosophy is that you should have some idea of how a particular software module or
feature will be used and that you should begin creating that module with that in mind.

- Create test cases before writing any code.

- The customer or Product owner responsibility to define the acceptance criteria that will
translate into the test cases.

The Definition of Done

- When checking a feature as “Done” the meaning needs to be clear for the entire team.

- Almost done may not be represented as Done.

- The definition of Done may be tied to certain acceptance tests, to coding standards, to
customer sign-off, or any number or combination of other things.
Agile Estimation Story Points - Ideal days
Relative sizing

- A technique used to ranks stories by their sizing relative to each other and eventually to
estimate based on those ranking.

- Post a card on the wall then arrange other cards to right or left according to their difficulties.

- Not precise, but move quickly through the stack of stories.

- Easy to team to decide how many of stories can fit to an iteration.

- Wave is the Product Planning structure with Medium range time frame (3 months) with Story
level capability and Capability commitment.

Wideband Delphi estimating

- Traditional Delphi technique: used to get experts estimates without knowing each other.

- Wideband Delphi is a consensus based method of estimating developed from a group of

experts. It’s name comes from the Oracle of Delphi.

- Wideband Delphi technique: the team is given estimation forms or cards and is brought
together to discuss functionality or user stories.

- estimating issues are discussed, but particular estimates or levels of effort are not.

- After discussion: individuals prepare their estimates away from the group.

- Can use story points for estimates (15-story point will take more than 11 story point (in same
project) but can’t be directly translated to time without additional work).

- Next: the manager gather all estimates and lists them or plots them on a graph, showing the
distribution of values but with no names.

- Finally: the team discuss the range and tries to reach a consensus.

- Advantage: No pressure in estimates from others and the entire group experience to reach
consensus.

- Bug reports and user interface changes are common examples of stories that are too small for
an individual story.

- A complex story is a user story that is large by nature and cannot easily be dissected into
smaller stories.

Planning poker

- Estimating techniques used to reach consensus (can begin early after user stories have been
written).

- Groups of technical are brought together (developers- analysts- testers…).(10 estimators).

- A facilitator reads the user story and every member ask questions and select a card that
represents relative level of effort for this story. (No one show his cards).

- After estimating all stories, members show their cards at once, and the team discuss the
estimates and pay attention to the outliers (the highs and lows).

- Continue until all estimates fall within acceptable range. (often after 3 rounds).

Affinity estimating

- A technique specially to address the issue of rapid estimating when the project has a large
feature backlog.

- First: the team decide on some kind of ranking or grouping technique, (sort, tall, grand,
venti,trenta)(S,M,L,XL,XXL)(Fibonacci no. ?,0,1,2,3,10,40,100).

- Finally, each use story is read loud and with little or no discussion, the team places the user
story within that group or around a sequence number.

- Affinity Estimating is intended to generate conversation as items are moved into affinity
groupings.

- When using affinity estimating, the minimum size for the number of items in the Product
Backlog is 20 items.

- Mute mapping is grouping items in silence.

Ideal time

- Ideal time is the amount of time it would take to complete something if there were no
interruptions, distractions, or meetings. (Zero interruptions).

- Football game that takes 60 m of ideal time but 3 Hrs of elapsed time.

- Ideal time estimate is advantage as it will be very difficult to factor in overhead.

Iteration & Release Planning

- Releases: are deliverables of features, benefits, and value to the customer. (Feature-oriented).

- Iteration: smaller than release (Technically oriented) (1 week – 1 month).

- Iteration 0 is for planning (charter), last iteration (H) hardening: no new features but tests and
reliability is ensured.

- Hardening iteration has empty backlog at the start of that iteration.

- Release plan is generally driven by the customer or product owner whose responsibility is to
group functionality in meaningful stages or release.

- Team can help the product owner to improve the release plan and be more realistic.
Agile Modeling

- A model is a representation of something else.

- Agile modeling is mapping out processes so that the team and stakeholders can review them
before implementing.

- Business modeling, requirements modeling, system analysis….

- JBGE: Just Barely Good Enough for the situation at hand and no more.

Time boxing

- PARKINSON’S law: an activity takes as much time as you allot to it.

- Timeboxing sets a fixed, hopefully reasonable, amount of time to work on features or user
stories, and the stories that are completed at the end of the time limit are included.

- Focus: help team to focus on most important features.

- Increase Productivity: helps to work smarter and harder and get more work done. It
helps to get away with ‘Parkinson’s Law’ and ‘Student Syndrome’.
- One downside: Team may look at what they can be done more than what customer need.
Some activities are difficult to rigidly timebox and may result a waste of effort (90% complete
with feature).

Continuous Integration

- All code changes are checked in and the entire system is built and tested at the end of each
day or even more often.

- Many development teams have hooked their integration server to lava lamps, with green lava
lamps for success and red for failure.

Working with Agile

Velocity

- A common way of measuring progress on Agile projects.

- Need a measure and a unit of time (interval).

- Y axis: no. of story pints or ideal days, or hours.

- X axis: iterations, or calendar weeks or any other measure.

- Shows a team is getting faster, slower, or is staying the same.

- Team performance issues.

- If it trends up too sharply in a short time, may original estimates have a problem or team
members working weekends to try to catch up.

- Can be useful tool for future release planning. (Benchmarking).

- Improving customer involvement will assist in improving the project velocity.

Cycle Time

- Time it takes from start (enter backlog) to complete (“Done”) a feature.

- Shorter time is desirable (with Quality also) as iterations are short in Agile. (MMF)

- When respond in an effective manner to customer need this will keep customer close.

Burn Rate

- Shows the amount of cost estimated over a given period of time.

- Can be used as a function of the team’s burn rate over time.

- team cost per day 5400 and the release consists of 3 iterations at 20 days, and a hardening
iteration of 22 days, then the cost of labor will be 450000.

Product Backlog

- Lists all functionality planned for the project, sorted by value to customer from highest to
lowest. (Completed functionality is moved off the list)

- Grooming: Product owner or customer is responsible to add new item coming from new user
stories and remove old ones.

- DEEP:

- Detailed Appropriately: should have enough details for the team to begin working to
deliver value (Customer will be involved).

- Estimable: user stories near to the top of the list should have enough details to be
estimated for story points or ideal days.

- Emergent: Not static. Backlog grows and change over time as user stories are
completed.

- Prioritized: User stories that have the most value should be at the top of the backlog.

Iteration Backlog

- Shows all functionality that the team will complete during the current iteration.

- Functionality is broken down to engineering tasks and team decides resources.

- Responsibly of the team and should be kept in a visible place to all stakeholders.

- Motivation: Right size and prioritize the iteration backlog so that the team can work toward a
sense of accomplishment.

Product Quality

- High quality is a motivator and if quality issues appear, make a root cause analysis to
understand them and correct the underlying factors that contribute to low quality.
Escaped Defects

- Errors that escaped testing by developer and quality control and made it to customer’s hand.

- A process should be their to detect and track errors before they are released to customer.

- Error-feedback ratio is the number of new defects created when fixing existing known defects.

Frequent Verification & validation

- To keep the project on track and quickly detect any deviation from value.

- Verifications: Functionality meets specifications.

- Validation: Does what it is intended to do.

- Frequent: Releases are frequent, Integration is continuous, Stand up meeting is daily.

Agile Smells

- Ways to describe and quickly recognize problems that affect the team or product.

- Documented with Scrum Master or Coach assessing the work.

- Bad practices, team silos, and people who dominate meetings and communications.

Embracing Change

- Traditional: Change with extreme caution.

- Agile: welcome change even late in development (manifesto).

- Give customer competitive advantage by enabling them to respond quickly to changing

conditions.

Refactoring

- Reorganize code that has been written from time to time more cleanly and straightforward.

- Team has collective responsibility to code.

- Performed because of a “Smell” or because team recognizes the need.

- After refactoring, a complete regression test is required to ensure that the streamlined code
behaves in the same way that it did.

Information Radiators

- A sort of dashboard posted publicly on a wall in a highly visible area to “radiate” important
information at a glance. (Task boards, big visible charts (burn charts), Continuous integration;
lava lamps and streetlights).

- Virtual teams: Post online

- A good information radiator will give stakeholders information needed without ask further
questions. (Completed, current, and planned iterations, progress on user stories, current work in
progress…).

Osmotic Communications

- “Diffusive communications” by spending enough time in an environment, team members will

pick up information.

- Instead project manager tell people what is going on, information may be often distributed
through more informal networks.

- Useful technique for distributing culture, best practices, and helping acclimate members to the
project.

- Virtual teams: use technology (single chat room- messenger- group blog- video conference).

- On drawback: can be wasted time; irrelevant communications and frequent interruptions.

- Combat this by setting hours where no one is allowed to talk in the war room (Cone of silence).

Burn-Down Charts / Burn-Up Charts

- Posted graphs that represent the project’s status over time. (progressing against the plan).

- shows the work in the project.

- Burn-down charts: show the progress during each iteration (Completed and remaining work).

- Y axis: functionality X axis: Time

- Burn-up charts: shows functionality against the plan. (Opposite burn-down)

- Burnup charts show total work whereas burndown charts do not.

Kanban Board (Task Board) organizes work and communicates what work is left.

- Japanese term means “Signal”, originated with lean management to provide information to the
production line can be used to respond. (Type of Information radiators).

- Workflow is defined for stories (e.g. plan, do, check, done).

- help team members manage their work and respond to the project as it progresses.
- Posted in the war room or a highly visible area showing progressing at a glance.

- Team members update the board. (Note, coloring box, physical moving along they complete
tasks).

- WIP: help the team limit WIP and focus on doing few things correctly and not having too much
going at one time.

- Little’s Law: at a given WIP level, the ratio of WIP to cycle time (CT) equals throughput (T). T =
WIP/CT, we can then determine that WIP = T * CT

- Cycle time is the average time between delivery of

completed work items.

- Throughput is the number of features the team

can develop in a particular amount of time.

Earned Value Management

- A measurement of how work is progressing against the plan.

- In Top-Down projects can be a very useful measurement tool, the scope must be will defined
and all changes to it have to be estimated and tracked carefully. (Against Agile).

- Planned value PV is the amount of value the project should have earned at a point in the
schedule. (Difficult to calculate with accuracy on Agile projects).

- Using the velocity and team’s Burn rate to calculate.

- Earned value EV tracks the actual percent of work complete at this point in time for the total
schedule. (Total schedule is not known on Agile projects).

- velocity and how many user stories have completed will calculate that over the iteration and
release plans to come up with an approximate percentage complete.( At iteration level)

- Three criteria should be looked at when setting iteration length; delivering chunks (stories) of
user valued functionality, building and testing the stories (working software), and product team
acceptance of the stories. Additional factors are release timeframe, exploration factor,
overhead, and learning needs.
Cumulative Flow Diagrams

- WIP limits, Kanban seeks to improve focus, quality, and overall the project performance by
limiting the number of things being performed by the team at any given time.

- Representing work in a cumulative flow diagram CFD is a way to do this.

- The chart convey a strong sense of momentum toward completion that builds as the project
progresses.

Incremental Delivery

- Gets working software into the hands of the customer earlier, delivering value more quickly.

- Allows customer to work with the system before it is complete, allowing time for changes.

- Does not try to plan everything up front, instead the team can do some planning, deliver some
value, gain valuable feedback, and repeat the cycle.

- Prioritizes the most valuable pieces of functionality so that they get in customer’s hands more
quickly.

KAIZEN

- Japanese management philosophy of continuous improvement like plan-do-check-act.

- making very small changes, measuring the impact, and repeating.

- Aligned with Agile in the way that encourages workers to change rather than asking
management what should be changed.

Spikes Reduce risk

- An experiment, performed quickly, to help the team decide which fork in the road to pursue.

- The work is always considered “throw away” work, and it only helps the team determine the
next steps.

- Consider a development team that is wondering whether they should use commercially
available component for embedding video in an application (might be too slow) or whether they
should try to develop.
- 2 members will perform a spike, download a trail version and takes a day to benchmarking to
determine the performance.

- Result: In one-day calendar team, become able to determine action.

Risk-Adjusted Backlog

- The primary repository for the feature that need to be delivered.

- prioritized by value to the customer.

- Risk has to be considered as well. (Uncertainty: bad or good).

- By ensuring that risks are associated to user stories and completing these stories early in the
iteration schedule, Agile approach de-risk the projects.

- Risk profile graph shows the risk severity scores for each risk plotted one on top of the other
to give a cumulative severity profile of the project.

- High value is attractive but if it has, a high financial risk of loss or high risk of environmental
disaster, then the choice will be less attractive.

- When backlog is viewed and adjusted in the light of risk, it may take on very different
characteristics than one based on value alone.

- Risk-Based Spike: ( time-boxed), visible by creating a story for it in the product backlog.

- Risk Identification: is done using information gathering techniques such as checklists,

document reviews, and assumption analysis.

- Risk Assessment: Business risk, Technological risks, or Logistical risk.

- Risk Response: Avoid, Mitigate, Transfer, and Accept (Evade).

- Risk Review: Through the ‘daily scrum’. Actions and decision points are added to the risk board
and reviewed every day.

- Relative weighting techniques: considers both the benefits of presence of a feature and the
negative impact of its absence.
Coaching With Agile
The Role of Management

- Coach or scrumMaster help team to embrace Agile and remove any obstacles from their path.

- Team: to reach optimal must be Self-managed and Self-organized.

- Traditional projects: Managers monitor progress and takes corrective and preventive actions.

- Agile projects; managers manage customers and help team to be self-organized.

- Coaching at beginning focus on the team, in the middle on the individual, at end on the team,
at release on the team.

- Individual coaching is most effective during the middle of the sprint. Whole team coaching
occurs at the beginning and end of the sprint.

Daily Stand-Ups

- Stay standing for the entire meeting to encourage people not to get comfortable and to keep
the meeting as brief as possible. (15 minutes).

- held at the same place and time every day with the entire team.

- What did you do yesterday?

- What do you plan to work on today?

- Are there any obstacles or impediments in your way?

- Team communication and awareness of what everyone is doing. (Integration in SW projects).

- Keep discussion to minimum to make use of everyone’s time.

Iterations (Sprints)

- Manifesto: We deliver working software frequently from a couple of 2 weeks to a couple of 2

months, with a preference to a shorter time scale.

- This is the iteration or Sprint. (Iterations: because they repeat through the project).

- plan session, operate, daily stand up, deliverable, retrospective.

- Each agile release made up of one or more iterations.

- Iteration 0 …. Iteration H (hardening).

Iterations Retrospectives
- Held after each iteration, and feedback is immediately incorporated into the next iteration.

- The team evaluates what worked well (keep or enhance) and what did not (adapt or discard).

- Every team needs to constantly evaluate and make appropriate adaptations in the following
four areas: product value, product quality, team performance, and project status.
- Outcome: is feedback which will be put in action plan.

- should be conducted at regular intervals, spread throughout the life of a project.

- are not about apportioning blame; instead it is to learn from the experience.

- Thorns and Roses is a technique to ask each team member what went well (Roses) and what
didn’t (Thorns).

- Product owner or customer doesn’t attend.

WIP Limits

- Limiting Work-in-process

- Lean: more customer value using fewer resources.

- Kanban: focus on decreasing WIP.

- Easier for team to focus on small number of items, increase productivity and quality.

- When one item of WIP is completed, another is “pulled” of the iteration backlog.

Process Tailoring

- Not one process or method fits all projects.

- Process should be changed to fit the project.

Stakeholder Management

- Stakeholder analysis: identify stakeholders (Stakeholder register) and their interests.

- Optimize: identify groups and representative for each group can be involved with the team to
be more agile.

- Stakeholders management: Function of communication and involvement.

- educate stakeholders on agile principles to ensure more support.

Team Motivation

- Maifesto: “Build the team around motivated individuals; give them the support and
encouragement they need.”

- Support

- From outside or inside.

- created when right people are involved early in the project.

- Team participation

- Cross-functional: everyone can maintains everyone else’s code.

- Contribution is visible to entire the team.

- Ground Rules

- Unwritten rules about expectations on the project.

- Should be communicated early.

- Team Performance Visibility

- Use Kanban board or other way to communicate progress to motivate the team.

- Team members can see how their efforts contribute to an increase in overall
performance.

Soft Skills Negotiation

- Emotional Intelligence (EI or EQ)

- High self-awareness: knows his personal strengths and weakness.

- High social-awareness: aware of how he is perceived by others and ability to tailor

behavior as needed.

- Benefits: High EI can deal with issues and problems relate and negotiate abrasive and divisive
people.

- The 5 basic EI factors are perceiving, managing, decision making, achieving, and influencing.

- Collaboration

- Most decisions are made in an open, transparent, and collaborative environment.

- All agile environment should encourage collaboration

- Space: No or few barriers, shared ownership of the code, self-organization, decision

making, stand ups, and communications.

- Coordination is simply the act of sharing information among the team members.

- Negotiation

- Manifesto “Customer collaboration over contract negotiation” .

- Example of negotiation is: User stories.

- Scope is also negotiable and changes are always welcome. (Scope is verified by the
customer, not the product manager.).

- negotiation should not be adversarial instead it should be collaborative, where the

customer or end user is brought into the conversation and helps make the best decision.

- Agile Negotiation: Separate People from the Problem, Focus on Interests, not Positions,

Use Objective Criteria, and Invent Options for Mutual Gain.

- Active listening

- listening, understanding, retaining, actively response.

- can reduce confusion and conflict on teams and can improve performance and results.

- Conflict resolution

- Compromise is not favored in Agile “each part give up some”. (Loose- loose). (
find a middle ground).
- On Agile projects conflict is expected as there is no top down direction like traditional projects,
instead the team are expected to bring their own ideas.

- Leader should focus on communication to resolve and active listening, keep the focus on the
project rather than personalities.

- Levels of Conflict

- Level 1: A problem to solve

- Conflict is based on a problem and has not yet progressed to individuals or personalities.

- During critical problem solving, you can ask probing questions, use active and reflective
listening. Lead to an answer but one should avoid injecting their ideas.

- The conflict resolution strategy is Collaboration.

- Level 2: Disagreement

- Problem can’t be clearly defined as it starts to become personal.

- Trust begins to run low and participants feel the need to be guarded.

- The conflict resolution strategy is support.

- Level 3: Contest

- Win or lose. (Recruit allies to their cause).

- The conflict resolution strategy is Accommodate.

- Level 4: Fight or Flight (CRUSADE)

- Us or Them. (One winner).

- The language becomes all about principles rather than issues.

- Level 5: Intractable Situation (World war)

- Win at all costs.

- Coach should separate the warring team members to limit damage.

Three-step intervention

- When a team member approaches the Coach with a complaint about another team member,
the three-step intervention path is the conflict resolution technique that the Coach should use.

Servant Leadership (Listening- Foresight- Stewardship).

- Team leader needs to be hands on, focus on the need of their team.

- Deep listening, self-awareness, and commitment to others.

- It cuts against the grain of hierarchical, top-down management and creates a strong bond
between the team and the leader that can translate to greater loyalty.

- Adaptive Leadership

- identifies Quality, Doing Less, Engage/Inspire, Speed-to-Value as its 4 elements of Doing Agile.

- The leader adapt to the environment to lead most effectively.

- Focus on activities that add value instead of doing things the way they have always been done.

- Openness and transparency, communication and networking, job descriptions and project
policies. All of these should serve the project.

- People are paid to their contribution not to seniority, or position.

Agile methodologies
Scrum focus on prioritizing work and getting feedback

- Scrum is a highly iterative agile project management methodology built upon 3 pillars, both the
work and result, Visibility, Inspection, and Adaptation.

- Product owner present the overall vision of the product, prioritize the product requirements
(Product backlog).

- Product backlog divided into releases.

- Sprint: 30-day iteration begins with a Sprint planning meeting (max 8 Hrs) first half of
the meeting the product owner discussing the highest priority features with the team.
The second half, (estimating) the team maps out the sprint and defines things down to a
task level.
- Sprint Backlog: stories that the team plans to complete in this sprint.

- Daily stand up meeting: 15 minutes daily to ask the 3 questions…. .

- Sprint review: half day at the end of the sprint. (Team and Key stakeholders) show the new
product functionality and discuss features of the next sprint.

- Every sprint ends with a shippable functionality into the product.

- The product owner gets to decide whether this functionality will deploy right away or will be
rolled out in a future release.
- Sprint retrospective: before the next 30-days sprint the team meets to see what went well and
what did not (Scrum master).

Scrum Roles

- Product Owner vision, requirements, and priorities.

- Like XP customer.

- Stakeholder representative. (Liaison to the outside world).

- Work with stakeholder to ensure project is funded and create the initial features backlog.

- Writes user stories, grooming and prioritizing the backlog.

- Team meet the goals

- Self-organizing and Self-managing.

- Highly interchangeable (i.e., generalists rather than specialists).

- ScrumMaster impediments
- Help the team to follow the scrum process and how scrum is implemented in the project.

- Encourage team members to facilitate the daily stand up meetings rather than doing it himself.

- Guides the Product Owner how to maximize Return On Investment (ROI).

XP focus on good practices

- A highly focused disciplined agile methodology to respond to the high cost of changing
requirements and institute strong engineering practices to improve software quality.

Core values

- Simplicity: Reducing complexity, extra features, and waste.

- Communication: what is requested from each team member and what others doing.

- Feedback: Failing fast is useful. Feedback for improvement.

- Courage: need courage to allow our work to be visible to others (Pair programming).

- Respect: Respect differneces.

- Customers define the application feature and introduce user stories.

- Team members break down user stories into story points. (Same estimates in the same
project).

- Developers work in pairs; one writes the code, and the other observes with focus on the
higher-level issues such as integration and functionality. (Pilot and Navigator)

- Pairs velocity, total number of story points a pair complete in an iteration.

- Team velocity: Aggregation of pairs’ velocity.

- Iteration between 1 and 3 weeks. (Shorter than Scrum). (Subsequent iterations duration is
fixed throughout the project)

- At the start of each iteration, the team and the customer will meet to discuss the user stories
and features.

- The team will break down into tasks and who will work on the tasks.

- Developers will estimate the effort by assigning story points. (No more story points in current
iterations than a team member finishes in last iteration).

- Programmers work in pairs to write test cases. (Test-driven development).

- The four levels of completion are broken, build, ready for demo, and ready to release.

- The 12 practices of Extreme Programming

* Fine-scale feedback
7- Pair Programming

1- Planning Game

- A practice of writing user stories, estimating effort.

- Maximize value.

5- Testing

- Write test cases before programing to ensure the program will pass.

- Component tests verify that units and combinations of units work together to perform the
desired operations.

Whole team

* Continuous process
9- Continuous Integration

- Discover conflict quickly.

- Test the entire system after integrating a new feature.

6- Refactoring

- Optimizing the source code.

- Should not change the code behavior.

2- Small Releases

- Focus on Minimal marketable Feature MMF and rapid delivery.

- Keep customer engaged and response to change.

* Shared understanding
12- Coding Standards

- Such as file names, variable names,….

- Should be discussed and agreed within the same organization before developing.

8- Collective Code ownership

3- Metaphor

- Avoid closed thinking about a technical system that may constrain the solution.

- If the team is completely focused on a load-balancing server, they may not even consider
different technologies that might accomplish the same goal more effectively.

4- Simple Design

- Accommodates changing requirements.

- Most efficient.

* Programmer welfare
10- Sustainable Pace

- Intensity is greater as pairs work side by side.

11- On-Site Customer

- Write user stories and define acceptance tests.

- If the customer not available then a team member may acts as a stand-in for the customer.

- XP Roles

- XP Coach

- Make sure the team adhere to XP process and help team to get better.

- Supporting role Not a top-down leader.

- XP Customer

- Is the product expert and determine which feature would deliver greatest values.

- Participate in planning game, and determine acceptance criteria.

- XP Programmer

- Self-organizing and self-managing pull user stories off the iteration backlogs and turn them into
a working solution.
- Work in pairs. (Pilot and navigator).

- XP Tracker

- Evaluates and communicates progress against the plan.

- The release plan (User stories), the iteration plan (tasks), and the acceptance tests.

- XP Tester

- Help customer take the acceptance criteria and translate them to acceptance test.

- Execute tests and communicate results to the team.

Lean
- Production systems based on product aligned single-piece flow, pull production.

- The original main 7 types of waste from Toyota Production System (TPS) are Transportation,
Inventory, Motion, Waiting, Over-production, Over-processing, Defects.

- Adapted from Toyota and their revolutionary manufacturing program. (7 principle).

1- Eliminate Waste

- Like: Excessive meetings, planning, documentation, testing, or any function.

- Value Stream mapping: analyze each activity as part of identifying potential waste.

2- Amplify Learning

- Continuous learning and improvement.

- Shorter iterations and coupling immediate testing with the iteration.

3- Decide as late as possible

- Decisions commit us to paths, yet Agile embraces being adaptive to change.

4- Deliver as fast as possible

- getting feedback and implement it to the system as possible.

5- Empower the team

- To take decisions and the entire team is responsible.

6- Build integrity in

- Refactoring

7- See the whole

- Should like as a solution not like a ten separate solutions cobbled together.

- Judoka (Automation)
- Judoka is a Japanese term used for automation 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 automation is self-correction.

Crystal

- Crystal clear

- For small team (1-6), low risk projects.

- Crystal red

- Large projects, tools to manage communications, mission critical solutions.

Dynamic System Development Method DSDM

- To RAD, latest version called Atern.

- Use a prioritization technique called MoSCoW (Must, Should, Could, and Won’t) to determine
which requirements should be included in a release or iteration.

- Other prioritization technique

- Kano Model: Basic Needs (Threshold –Must have), Performance Needs (Linear), and
Excitement Needs (delighters).
- Relative weighting: Each feature is prioritized based on its relative weighting for Benefits,
Penalties, Costs, and Risk. Each feature uses a relative scale of 1–9 to determine its rating.
- priority = value% / (cost% + risk%)

- DSDM Phases

- Pre-project: identify the right project.

- Project life cycle

- Feasibility phase

- Foundation phase

- Exploration phase (iteratively & incrementally develop the solution)

- Engineering phase, nonfunctional requirements(Staging) (maintainability-security-

response time)

- Deployment phase, live

- Post-project: which business benefits are realized.

Note:

Speculate phase includes developing a capability and/or feature based release plan to deliver
the vision.