Michael Toppa gave a presentation on the promise and perils of Agile and Lean practices. He discussed how adopting these practices can help address common project problems like unrealistic expectations that compromise quality, multitasking that reduces productivity, and lack of feedback that leads to building the wrong products. However, going all-in with Agile through methods like Scrum requires major changes all at once, while adopting Lean through Kanban allows for more incremental evolution. Successful implementations inspect and adapt processes, rather than relying on superficial or misapplied changes.
2. www.toppa.com
@mtoppa
Mike Toppa
web engineer
610-322-7034
mike@toppa.com
www.toppa.com
Ruby, Rails, PHP, Wordpress, JS, HTML, CSS
SQL, NoSQL, AWS, TDD, Scrum, Kanban
20 years of experience in web development, project management, and functional management
* Currently working freelance
* Previously:
* Director of Development, WebDevStudios
* Director of Web Applications, U Penn School of Medicine
* Web developer at: Georgetown University, Stanford University, E*Trade, Ask Jeeves, and the 7 person start-up, ElectNext
3. My challenge in this talkâŠ
Teach you about Agile & LeanâŠ
Without actually teaching you Agile & Lean
I want to teach you about why you may to consider them, how they differ from each other, what beneïŹts you can expect, and what obstacles you may face
5. Features
Cost Schedule
1.The iron triangle
Client can
pick two
Quality
Iâve explained the triangle to dozens of clients over the years.
Programming is not magic. If the client tries to squeeze all 3 sides of the triangle, quality suffers.
6. Misalignment of authority and
responsibility
Cartoon by Mike Lynch
Used with permission
- Following this advise lets you cover yourself politically, and is a great way to make everyone who works for you miserable
- I've found that misalignment of authority and responsibility can explain a lot of dysfunction that happens in organizations
- When you have responsibility for your work but not enough authority over it, you will feel like a cog in machine
7. âIf you go to the store with a huge shopping list and twenty
dollars, you need the authority to go to the money machine
for more cash, or the authority to make changes to the list.â
Ron Jeffries, Making the Date
Whatâs happening is that the client is trying to retain authority on the project while giving you the responsibility. But ultimately, for the project to be successful and for both
you and the client to be happy, responsibility and authority need to be brought into alignment.
8. 2. Multiple projects and multitasking
Source
Context switching between two projects eats about 20% of a full-time workerâs schedule. The sense of progress with multitasking is an illusion, compared
to not multitasking
10. A consequence: too much work
SWAG chart
9 developers, 2 product owners, and me supporting
- 22 clients with 124 applications
3 designers and 1 product owner supporting
- about 200 static content web sites
Taking inventory itself was a huge undertaking
11. Source
To have any chance of success in the long run, you have to claim authority you may not have had previously. You may have to ïŹght for itâŠ
12. Source
âŠbut you have to always be professional. Think of how doctors behave in an ER. When the pressure is on is when you want them to be at their most
professional.
14. Tell me what you wantâŠ
For yourself, and for your customers
15. What makes a job enjoyable?
†Autonomy
†Reward for effort
†Challenging/complex work
âWork that fulfills these three criteria is meaningful.â
â Malcolm Gladwell, âOutliers: The Story of Successâ
16. âNovices believe that quality and velocity are inverse.
They think that hacking is fast.
They havenât yet recognized what
professional developers know all to well:
âŠthe higher the quality, the faster you goâ
Bob Martin, Vehement Mediocrity
18. Add more people?
Brooksâ law:
âAdding manpower to a late software project makes it laterâ
- Fred Brooks, The Mythical Man-Month
19. Add more pressure?
Source
Hold the developersâ feet to the fire. This is the death march. Analogy that software development is like a washing machine.
20. âThe main thing that pushed Agile and Scrum
was that the success rate on traditional projects
was terrible; it was 45%. If that was a car-
manufacturing place, that would mean youâd
throw out every other car you built.â
Ken Schwaber, co-creator of Scrum,
6/21/2011
Source
22. Agile solution: flip the triangle
Source
The traditional approach also does not take into account the âcone of uncertaintyâ - things will change
23. Agile: frequent feedback is key
Source
Rather than ïŹght the âcone of uncertaintyâ we embrace it. We are always checking in to make sure what weâre delivering is what the client wants, and weâre
ready to adjust priorities based on feedback. At some point we will run out of time or money, and when that time comes, we want to make sure we have
delivered the most important features.
25. Agile, Lean: whatâs the difference?
inspect
& adapt
incremental
& iterative;
roles & rituals
limit WIP;
eliminate waste
Agile Lean
Both originate from management ideas in Japan, but Agile was created in the US software industry in the late 1990s, and Lean comes specifically from
Toyota in Japan
29. Scrum is a holistic project
management system
Source
30. Scrum has clearly defined roles
and responsibilities
Source
If you adopt Scrum, peopleâs jobs will change, at least to some extent
31. Kanban can be applied to any
project management system
Itâs about achieving the right amount of âwork in progress.â
32. Kanban takes you from thisâŠ
Too much WIP can feel like a traffic jam. Covering every inch of a highway with cars is not how we achieve the capacity of the highway
33. âŠto this
We achieve capacity when the cars ïŹow smoothly on the road. They get to go reasonably fast, operating their engines at a good fuel efficiency. They donât
need to slam on their brakes. They donât need to change lanes often, and thereâs a safe distance between them. This is what we want our work to feel like.
35. The Scrum Promise
âIn my Scrum classes I warn attendees of what I call
the Scrum Promise: If you adopt Scrum, there will be
a day you come into the office nearly in tears over how
hard the change can be. This is because Scrum
doesnât solve problems, it uncovers them and puts
them in our face. Then, through hard work we address
them.â
â Mike Cohn, Agile Trainer
I didnât know this when I led the scrum adoption at Penn, but itâs deïŹnitely true
37. Kanban foundational principles
†Start with what you do now
†Agree to pursue incremental, evolutionary change
†Respect the current process, roles, responsibilities & titles
38. All-in vs. evolutionary change
†All-in pros:
†Gets everyone working in the
same system quickly
†Get good at a complete system
with clear rules first, then learn
where to make changes
†All-in cons:
†Near term productivity loss,
confusion, resistance
†Can surface too many pre-existing
problems at once
†Evolutionary pros:
†Minimal disruption
†Make changes only as needed
†Evolutionary cons:
†Easy for change process to stall
and not address deeper underlying
issues
44. 3. Consulting environment challenges
†Traditional contracts require detailed plans
†See my Agile Contracting WordCamp talk from last year!
†Who is the product owner?
†Clients arenât good at it (but think they are) and probably
donât want to pay you to do it
†Hard to work in teams when you typically have projects that
are small and simultaneous
45. Key to success: inspect and adapt
Source
Single loop learning is âhow can we do betterâ?
Double loop learning is âWhy do we believe that?â
Double loop learning means challenging fundamental assumptions
46. Additional references
†âSucceeding with Agile: Software Development Using Scrumâ and
âAgile Estimating and Planningâ by Mike Cohn
†âKanban: Successful Evolutionary Change for Your Technology
Businessâ by David J. Anderson
†Angry Dinosaurs: Accelerating Change and Institutional
Incompetence presentation by Cory Ondrejka, Wharton Web
Conference, 2010
†âThe Lean Startupâ by Eric Ries
†âThe Nature of Software Developmentâ by Ron Jeffries
†âSpecification by Exampleâ and âImpact Mappingâ by Gojko Adzic