Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Transcript of Agile Tools
And which ones?
The Stacey Matrix
First - What is Agile?
Agile is a process for developing products that is iterative and incremental.
That is, it has many small steps.
What's so special about that?
Many small steps means that you can have a lot more control, and can respond to change very quickly
After each step, or iteration, in Agile, the team will "Inspect and Adapt". In other words, review what just happened, find things that can be improved, and then improve them.
Surface problems quickly
Short iterations also means that any problem or obstacle is a lot easier to see. That is, Agile 'Surfaces problems'.
And once identified, a solution can be tried out. If it doesn't work, another solution can be tried next iteration. This "Inspect and Adapt" approach allows rapid evolution.
It also allows us to adapt to change
After each iteration, there is the opportunity to reassess the work done so far, and change priorities, details, or the entire direction of the product.
Regular review of the project's direction allows teams to react to change quickly, but also in a reasoned way. Projects always change, and Agile is ready for it.
Iterations and 'Inspect and Adapt' are only two tools in the Agile Toolbox
Like a hammer and a screwdriver, these tools are heavily used. But it's a sorry toolbox that has only a hammer and a screwdriver - you need to have other tools if you want a truly useful toolbox.
Individuals and Interactions
Responding to change
over processes and tools
over comprehensive documentation
over contract negotiation
over following a plan
While there is value in the items on the right
We value the items on the left more.
12 Principles of Agile
Our highest priority is to satisfy the customer through early and continuous delivery of valuable products.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Business people and developers must work together daily throughout the project
Build projects around motivated individuals. Give them the environment and the support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
Working product is the primary measure of progress
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility.
Simplicity - the art of maximizing the amount of work done - is essential.
The best architectures, requirements, and designs emerge from self-organizing teams
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it's behavior accordingly.
Agile is a "Measure Twice, Cut Once" Philosophy
There are a number of planning stages, at different levels and stages, all of which can be used together.
What tools to use?
"Measure twice, cut once" means "Plan and prepare in a careful, thorough manner before taking action". It comes from carpentry - once you cut a piece of wood, you cannot un-cut it. It is far cheaper to avoid problems early and cheaply than to fix them later and more expensively.
High-level Design has two parts. First, Design the product.
This often changes, so when traditional projects are complete, more work is often needed.
Second, break the product into several working sub-components. That way the customer can update the design as development progresses.
This way, the customer has usable pieces early, and can
be assured they will receive what they need, not merely
what they asked for.
A Product Backlog is a prioritized list of tasks. All tasks should be small enough that a Scrum Team can complete the work in a single Sprint
The Product Backlog should should support the release plan for the product, and have all major dependencies worked out.
Tasks are often referred to as 'Stories', since they are usually described in terms of who will need the feature or function, and how they will use it, for context.
The plan for what the team
will do in the next
When planning a Sprint, the Sprint Team needs to determine several things:
What the team will deliver at the end of the Sprint
Exactly how to deliver the concrete result
The task breakdown to do so.
The team decides who will do what and how - not
managers or product owners
There is a basic assumption that Team Members are competent, motivated, and capable of doing the work. That the best way to do something is to let the people who actually know how to do the work decide how best to do it.
This way high-value portions can be used long before the entire project is complete.
Traditionally, projects are scheduled so that all parts complete at about the same time
Agile planning is focused on delivering working subsets to the customer, before the entire project is completed
The act of repeating a process with the aim of approaching a desired goal, target, or result.
Each repetition of the process is also called an 'Iteration'.
The results of one iteration are used as the starting point for the next iteration.
Each project uses many iterations
Also, each iteration is an opportunity to review the overall course of the project, and change it if needed.
Sprint? Scrum Team?
These are Agile and Scrum terms, used in software project management.
A Sprint is another term for 'Iteration'. It is used because it implies a lot of focused work done quickly.
A Scrum Team is the team of people that do the focused work during the sprint. Scrum refers to a Rugby scrum, and is a metaphor for people with many different skills working together in a barely-controlled way.
The main measurement of interest to most project managers is how fast the project is being done. In Agile, this is called the 'Velocity".
There are many ways to measure velocity, but they all depend on how much work the team can complete over time.
The best way to measure that is to see how much work the team has completed in the past, and use that to estimate how much they will do in the future.
We want estimations to become more accurate over time, not less. To do this, we estimate the work for each Sprint, and then compare it to the actual work done over the Sprint.
As Iterations proceed, the estimations should become more accurate.
To track estimations, follow the progress in the Sprint, and to identify problems, we use two tools.
The Scrum Board
Notes and reminders
It is an easy way to track progress in the Sprint
Team members can see at a glance what tasks still need to be done
It is quickly apparent when a task is either blocked or no-one wants to do it
The effort of each task is reviewed every day
Benefits of a Scrum Board
The Burndown Chart
Used every day by the Sprint Team
Tracked by the Scrum Master
Uses of the Burndown Chart
Velocity can be tracked within and between Sprints
Stability of estimates within and between Sprints can be tracked
Can surface problems, such as 'why is daily effort on Thursdays always 40% less than other days?'
(Answer: "Donut Thursdays" induces sugar-shock)
Owns the Product Backlog
Makes the Release Plan
Prioritized the Backlog, to support the release plan
Acts as the customer representative to the Scrum Team
Makes sure the changes to the plans, priorities, and work items are made to the Product Backlog
Acts as a buffer between the Scrum Team and everyone else
Runs the Scrum meetings
Keeps track of the team's progress
Solves problems and removes roadblocks so the Scrum Team can focus on their work
Usually 5 - 9 people, with a range of skills
Plan and execute work in time-boxed 'Sprints'
Are responsible for producing customer-ready work
Decide as a team what work they will do, and how to do it
Succeed or fail as a team
Each review allows the team to identify and fix problems and obstacles, so as the iterations progress, the effectiveness of the team increases.
Each Iteration follows the same process (Planning, execution, and review)
As each iteration builds on the next, the product takes shape.
Meetings are needed
They are the nails that hold projects together:
Communication within and between groups
Coordination within and between groups
Makes sure everyone is on the right path
Meetings can also be major problems
Meetings can be a huge waste of time, effort and goodwill.
We want few, but effective, meetings
Agile uses three meetings:
Sprint Planning Meetings
Daily Stand-up Meetings
Sprint review/Retrospective Meetings
Sprint Planning Meetings
The goal is to plan the work for the next Sprint
Scrum Team selects the tasks it wants to work on
The tasks are examined in detail
Exactly how the work will be done is decided
The effort estimate is made
The team commits to completing all the tasks it takes on.
Daily Stand-up Meetings
The goal is a fast status update/coordination
Meeting should be less than 15 minutes. Everyone answers three questions:
What I did yesterday
What I plan to do tomorrow
What obstacles do I face
Any other topic should be discussed informally later, with only the people actually needed.
Review / Retrospective
The goal is to let everyone know what has been accomplished, and to do the retrospective
Customers should see the completed work
Everyone sees what has been done, so all understand the progress of the project
This is where the retrospective happens
All other meetings should be ad-hoc
Informal meetings with only needed people can - and should - happen at any time. Meetings for meeting's sake is a waste of everyone's time.
Looking back on or dealing with past events or situations.
"Inspect and Adapt"
In the Agile world, it means to review the just-completed sprint, and analyze for improvements.
There are many ways to run Retrospective meetings
The way I do it has three steps
Everyone puts at least one thing that they thought went well, and at least one thing that could be improved onto sticky notes. These stickies are then put onto a board with 'Good' and 'Can be Improved' labels.
2. Review and Group
Review all of the sticky notes, so that everyone understands what each one means. Then group the stickies by similar topics - items that may be addressed together.
Discuss the items or groups of items, and propose an action that can be taken to improve things. Work on improving 'Good' items as well. Make sure the actions are concrete, have a person assigned to it, have a well defined due date, and a clear definition of done.
3. Select actions
Retrospectives allow us to alter our processes so we become more effective.
If a solution doesn't solve a problem, we can try a different solution next Sprint. If a new problem is surfaced, we can address that next Sprint.
In this way, Agile processes into something more effective and efficient.
Ralph Douglas Stacey
A professor of Management in the UK, he worked in the area of strategic planning. His main area of interest was why corporate leaders are so bad at forecasting, and why do they keep using the same methods that have already failed them?
He developed the chart to describe the problem space that these forecasts are made in.
Dr. Stacey later argued that his chart incorrectly simplifies the complexity of the problem space, since it does not include the human factor.
Fixed Effort, Variable Times
Delivery Team Based
Agile is most effective in the 'Complex' problem space.
Agile Methods are focused mainly on the people actually delivering product. It is not a purely managerial process.
Agile methods can encompass several layers of management, but they always start at the Delivery Team level.
In order to be Agile, the delivery team members must have ownership of what they do. To do this, tasks are not assigned to them, but instead they choose the tasks they will do.
This is called 'Pull' tasks, as opposed to 'Push', or assigned tasks.
So why do we ask 110% of our people all the time, to meet deadlines based on rough, quick estimations?
An engine running at 60% will run forever. An Engine running at 100% will last a few months. An Engine running at 200% won't last a week.
Agile methods do not use fixed completion dates. Rather, they use fixed effort to make estimations about completion dates. Estimations that are expected to change.
Different Situations need different tools
It is common for people to want to bring Agile tools to situations where there are fixed deadlines. In these cases, there is usually a lot of time pressure as well.
It needs to be noted that Agile is not a good way to reduce time pressure.
If the tasks are management level only - coordinating work among several teams, for example - then most Agile techniques are not applicable.
If the project is only a few weeks long, then the evolutionary benefit of many tools will not help. Using short iterations with retrospectives in the first several iterations will probably help identify and fix some obvious problems.
There are many who believe that not using all of the tools are not properly doing Agile, and are asking for disappointment. This is not my experience. The full benefit may not be seen, but I have always seen enough benefit to justify the effort.
Long term projects are the bread and butter of Agile, and can use all of the tools.
Useful tools: Scrum Team, Iterations, Product Backlogs, Scrum Backlogs, Daily Stand-ups, Scrum Boards, Planning Meetings, and Retrospectives
Useful Tools: Release plan and Retrospective meetings
Useful Tools: Iterations, prioritized product backlog, Scrum Team, Review/Retrospective meetings, Scrum Board, Stand-up Meetings.
The basic philosophy of all Agile comes from the Agile Manifesto and the 12 Principles of Agile.
These tools can help with project control.
The 'Anarchy' space is for processes that cannot be controlled. Research, or creating art, for example.
The 'Simple' space is for tasks that are well defined, well understood, and/or require little skill.
The 'Complex' problem space is quite large, and encompasses most large projects. Projects that cannot be detailed to a very high degree of specificity before starting work are complex.
'Complicated' projects are those that are typically limited in scale, and have either a well-known technology or process, or a high level of agreement and understanding among the customers and the project staff.