2. Why Agile
Agile is a widely adopted methodology used in the development of
products, and it has achieved success rapidly bringing many
products to market. Understanding core Agile concepts is
fundamental to understand the “why” behind following this
methodology.
Change happens. We want to
minimize risk and guarantee
successful delivery of products
that constantly add value.
3. There are concepts I will discuss in this talk that are only referred to in slides. This is
because Google.
Why use a methodology?
● A common language saves time
● It is a code base of ideas and patterns
● A common practice means evolution
Why Agile?
4. The Manifesto for Agile Software Development is based on twelve principles:[16]
1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly
But Agile also incorporates LEAN principles, Six Sigma controls and a whole lot of
user-centered and design thinking.
Where did it come from? February, 2001:
Why Agile?
5. ● We do this stuff in sprints.
● There is a scrum master who runs things.
● We write these things called epics and user stories.
● Waterfall is old and bad.
● We can change stuff whenever we want because it is, you know, agile.
What we talk about when we talk about Agile...
Why Agile?
6. ● Waterfall in shorter cycles, but it is still waterfall, just with less planning up front (!)
● Change + committee ownership = broken promises
● Velocity used as a performance measure
● User stories for non-functional or other requirements (shoehorning)
● Work constantly pushed out (snowplowing)
● Human nature. Software is hard work.
Agile + other methodologies = frAgile.
What can go wrong.
Why Agile?
7. House Odds
66% of IT projects fail. On average, IT projects run
45% over budget and 7% over time, while delivering
56% less value than predicted.*
44% fail due to misunderstanding of Agile.**
The Project Management Institute’s 2017 Pulse of the Profession report found that 28% of strategic initiatives
overseen by survey respondents were deemed outright failures. Some 37 percent of the more than 3,000
project management professionals who responded cited a lack of clearly defined and/or achievable milestones
and objectives to measure progress as the cause of failure, followed by poor communication (19%), lack of
communication by senior management (18%), employee resistance (14%) and insufficient funding (9%).
https://www-cio-com.cdn.ampproject.org/c/www.cio.com/article/3211485/project-management/why-it-projects-still-fail.amp.html
8. We are stubborn on vision. We are flexible on details. - Jeff Bezos.
Innovation comes from people who take joy in their work. - W. Edwards Deming.
How does it work?
9. ● Agile Project Charter (the rules of engagement)
● The Mission (Vision)
● Business Stakeholders
● Project/Program Manager
● Development Manager
Most important for any project: who has skin in the game? That is your best friend.
The vision as well as the people, process and tools to meet that vision must be agreed
upon and widely socialized.
Governance
How does it work?
10. ● Product Owner
● Scrum Master
● Team
(notice: Team, not BA-Dev-QA)
Roles (SCRUM)
How does it work?
11. ● Roadmap definition - epics and themes
● Backlog refinement and prioritization
● Poker planning (estimate stories in points or sizes)
● Release planning - complex stories first to avoid “snowplow” effect
● Release retrospective
● Sprint planning
● Daily stand-up
● Sprint demonstration
● Sprint retrospective
Ceremonies
How does it work?
3,363,840,00
12. ● Roadmap (3 to 6 months)
● Epics (or features)
● Themes, delivered in releases
● User Stories (who, what and why), delivered in sprints
● Tasks (how)
● Non-Functional Requirements
● Definition of Done
● Output: fully functioning products
Reference:
https://www.scrumalliance.org/community/articles/2014/march/stories-versus-themes-versus-epics
Components
How does it work?
13. ● Release planning and estimation in story points, with one poker planning, stories
assigned to sprints
● Sprint planning and estimation in tasks/hours, with one sprint planning, adjust sizing
if necessary.
Remember: sizing is to understand throughput and team capacity. Velocity is not
productivity!
And always remember: we do this to deliver incremental value, decrease time to market
and reduce risk. If any of this Agile stuff does not do that, time to rethink!
Release vs sprints
How does it work?
14. ● Burndown for remaining work (expressed in points), burnups for completed work
● Ideal, realistic and pessimistic lines - prepare for scenarios with prioritization
Metrics
How does it work?
15. Agile is about creating a software factory.
A factory has machines that must function predictably.
All metrics have a purpose: to measure something that will lead us to make decisions.
If the metrics we capture 1) do not lead to decisions that 2) allow us to increase
predictability, then something is wrong.
Define
Measure
Analyze
Implement
Control
Metrics
How does it work?
16. How does it work?
Roadmap Release Sprint
What is the
product?
Vision.
What are the
features?
What is the
theme?
What is the
value to
users?
● Iterate
● Fail
● Learn
● Repeat
Inception
Customer wants to customer gets as fast as possible.
17. ● Keep pushing validation up the value chain. Ask stakeholders for KPIs and metrics to
define product success and align with core business strategies.
○ Good example: ROI based on new market, efficient use
○ Bad example: number of defects, performance metrics
● Look for friction points beyond the product development and get them on board. An
organization that does Agile development but not marketing creates bottlenecks.
● Make sure every meeting you attend has an objective. If you have meetings beyond
Agile ceremonies, ask yourself why?
● If it can be done now, do it now. Do not log a bug - fix it. Do not write an email - have
a conversation. Handoffs are the enemy of Agile.
● Agile is a means to an end, not an end in and of itself. Always reduce process
footprint where possible.
Beyond Agile...
Where now?