2. • Agile trainer and coach
• Member of PMI, Scrum Alliance,
Agile Alliance, Agile Leadership
Network
• CST, CSM, CSPO, CSP, PMI-ACP,
PMP
• Founder & executive committee
member of Agile Delivery for
Agencies, Programs, and Teams
(ADAPT)
• Experience in Federal and
commercial Agile transformations
Richard Cheng
richard.cheng@excella.com
@RichardKCheng
3. “Traditional” IT Project Management
◊ Process and tools
◊ Comprehensive documentation
◊ Contract negotiations
◊ Following a plan
This is how we control projects….
5. IT Industry average success rate?
Success rate ~ 33%
IT Industry average success rate?
Success rate ~ __%
Industry Success Rate
From 2010 report from The Standish Group
7. Agile Manifesto
Individuals and interactions over Process and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
We are uncovering better ways of developing software by doing
it and helping others do it. Through this work we have come to
value:
That is, while there is value in the items on the right, we value
the items on the left more.
http://agilemanifesto.org/
8. 1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
Agile Principles
9. Scrum vs. Waterfall
◊ Waterfall is based on
Predictability
– Feedback is usually not attained
until late in the project
– Works best when all details are
known up front
– Change is expensive
◊ Scrum is based on Adaptability
– Constant feedback
– Allows for discovery throughout
the lifecycle
– Provides infrastructure to
support and implement change
10. The Stacey Diagram
◊ Simple projects don’t need
Scrum
◊ The Complicated projects
benefits from Scrum to
increase certainty and
agreement
◊ Scrum returns the biggest
process gains in the Complex
space
◊ In the Anarchy space, there is
high risk regardless of method
Ralph Stacey, Strategic Management and Organizational Dynamics
Technology
Requirements
11. Agile Methodologies
Agile
Scrum – Iterative method used by most teams
XP – The software engineering practices
Kanban – Often used in operations
Lean – Concepts used for organizational Agile
16. Limit Work In Progress
In
Queue
(5)
Development (3)
In
Progress
Done
QA Tests (4)
In
Progress
Done
Release (5)
In
Progress
Done
Item
Item
Item
Item
Item
Item Item Item Item
Item
Item
Item
Item
17. Measure Workflow
◊ Average Time In Queue – 3 days
◊ Average Time In Development – 2 days
◊ Average Time Waiting for QA Test – 2 days
◊ Average Time In QA Test – 5 days
◊ Average Time Waiting for Release – 9 days
◊ Average Time in Release – 3 days
◊ Average throughput - 24 days
18. Optimize Workflow
◊ Average Time In Queue – 3 days
◊ Average Time In Development – 2 days
◊ Average Time Waiting for QA Test – 2 days
◊ Average Time In QA Test – 5 days
◊ Average Time Waiting for Release – 9 days
◊ Average Time in Release – 3 days
◊ Average throughput - 24 days
20. When to use Kanban
◊ Operational Work
– Networking
– Help Desk
– Pure Operation and Maintenance
◊ When 1 weeks Scrum Sprints are too long
◊ Visualizing and measuring across multiple workflows or
teams
◊ If Scrum is not working for you, transitioning to Kanban
will usually make things worse (other than the cases
above)
◊ Kanban concepts can be applied to Scrum and Waterfall
26. Excella Consulting
Experience and Expertise in Agile Solutions
– Coaching
– Training
– Assessments
– Agile Adoption
– Agile Development Teams
– Agile PMO
Training Courses
– Certified ScrumMaster (CSM)
– Certified Scrum Product Owner (CSPO): The Agile Business Analyst
– Advanced Certified Scrum Product Owner (CSPO)
– Certified Scrum Developer (CSD)
– Agile Testing
– Agile Business Intelligence and Data Warehousing
– Automated Acceptance Testing – Great for Analysts and Testers!!
See http://www.excella.com/training for more information
27. Contact Information
Richard K Cheng
richard.cheng@excella.com
703-967-8620
http://www.excella.com
Twitter: @RichardKCheng
Hinweis der Redaktion
This is what we do today
Everyone standup
>90% sit
>80% 50% 30% 20% 10%
Stand up on your hands
If I’m a baseball player, this is a good stat
Download paper from wikipedia. Easy ready
Iterate through it and get your feedback from customer
Story of Agile Manifesto:
Small steps
Synchronize
Timeboxes
Collocation
Technical debt
Self organize
Track stories/feature completion not tasks
Information radiator – Available info, office with pictures
Refrigerator – Open door, dig around
Information radiator – Available info, office with pictures
Refrigerator – Open door, dig around
Information radiator – Available info, office with pictures
Refrigerator – Open door, dig around
The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum. We felt that the first step was to identify how to successfully develop a solution from end-to-end. Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together. This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.
The DAD framework provides a better foundation for scaling agile:
Risk and value driven lifecycle. Scrum has what is called a value driven lifecycle. Work is prioritized by value to the business and is performed in priority order. This is a pretty good approach, but it’s possible to do better. Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk. Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of succeeding early. A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success.
Self organization with effective governance. There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy. But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem. Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams.
Delivery of consumable solutions over construction of working software. There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus. First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project. DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project. The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach. Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle. Second, agile teams do far more than produce software. We create supporting documentation. The software runs on hardware that may need to be upgraded and/or redeployed. We potentially change the business process around the usage of the system we’re producing. We may even affect changes to the organization structure of the people using the system. In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”. Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want. What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals. The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal.
Enterprise awareness over team awareness. We alluded to this in point #2. Disciplined agile teams recognize that they work in a larger organizational ecosystem. This enterprise awareness motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization. Done right this increases a team’s ability to deliver.
Context-sensitive and goal driven over prescriptive. One process size does not fit all. A strategy that works for a small co-located team will put a large geographically distributed team at risk. A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship). So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in. DAD describes a straightforward, easy to consume strategy that is goal driven