XPDays Benelux 2015 - 3M EUR later: Moving a team to become Agile in a Company with Too Much Money

How do you go from a ragtag of people having no idea what it means to be Agile, stuck in eternal maintenance and operational work, applying none of the basic software engineering practices to a team of DevOps delivering value for their customers in sprints of 2 weeks ?

Imagine a very profitable company with hardly no competition that made waterfall an institution.

This is the story of one team within that company. Imagine a team that is not really a team, but a bunch of people that happened to have the same manager. No-one knew what the other was doing. Each one was managing his application, or worse part of an application. A bunch of technologies was used. Automated tests, version control and process were totally inexistent. Internal customers were trained to wait forever for new functionality or worse received functionality the developer thought was good for them.

I would like to share with you how this team became in 3 years one of the most Agile teams of that company. What were the problems this team encountered and why.

Transcript

1. 3M EUR later Moving a team to become Agile in a Company with Too Much Money XPDays 2015 Thierry de Pauw, @tdpauw
2. Setting the Scene ! New Team ! 8 employees ! New Manager ! and a highly profitable company
3. ! Lots of software products ! Lots of programming languages ! No Collective Ownership ! No process for software delivery ! 70% operational work ! Very little communication ! which was visible in the design => Conway's Law
4. "Any organisation that designs a system will inevitably produce a design whose structure is a copy of the organisation's communication structure." Conway's Law
5. 2 contractors as technical coaches
6. How did this team transform itself into an Agile software development team ?
7. The easy part - Throw tools at it and Enforce Version Control => Collective Ownership Testing Continuous Integration Code Reviews => Quality Work Coding Standards => Communication
8. 2 parallel projects with some business value without real deadline Code Retreat Lots of book reading
9. Mixed results: one project took 3 months the other 1 year
10. Why ? ! involved the customer early ! good backlog preparation => defined release date ! empowered dev team (lots of innovation: CI => CD, automated acc tests) ! released every 2 weeks ! missing deadline
11. "Yes, deadlines are wonderful! They’re the tie-breaker on feature debates. They suck all the excess heat out of the prioritization joust: “Hey, I’d love to get your additional pet feature into the first release, but, you know: THE DEADLINE” " David Heinemeier Hansson, Signal vs Noise blog
12. Still no Collective Ownership
13. How did they improve Collective Ownership ?
14. Manager wants to execute too much projects in parallel
15. “The fastest way to complete two projects that use the same resources is to do them one at a time” Mary and Tom Poppendieck, Lean Software Development
16. Create one Scrum team execute projects one after the other 2 week sprints, Monday: demo, retrospective, planning and design
17. How has this team handled its Technical Debt ?
18. "Technical Debt ensures that the only work that gets done is unplanned work." The Phoenix Project
19. Automate the operational work
20. How did this team improve the flow of work from backlog to production ?
21. ! Visualise work: planned and unplanned
22. ! Internalise Testing ! Internalise Operations => you build it, you run it ! Continuous Delivery
23. How did this team improve ?
24. By keep doing Retrospectives (which can be difficult at times)
25. Too much change ?
26. "If a system is not improving, the result is not steady state. Instead, because of entropy, organisational performance declines" Mike Rother, Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
27. The case of the Product Owner
28. Tried 2 configurations: ! the customer is the PO ✕ ! PO is a team member ✓
29. What is the current situation ?
30. A Team of Software Engineers ! communicating with each other ! defining its own planning ! with a software delivery process ! using Continuous Delivery ! doing small experiments ! allocating 20% to improvements ! having REST-full applications and "micro services" => Other teams are now knocking on the door to learn
31. What made it difficult ? ! the team is isolated in the company in regard to Agility ! demotivated team members ! customers were used to long running projects ! highly profitable company ! heavy process for introducing new tools
32. What made it work ? ! active support of the manager and his manager ! motivation of some team members ! no customer facing applications ! customers saw the difference ! discard some team members that did not fit anymore
33. Hello, I am Thierry de Pauw Software Engineer, Jack of All Trades Agile Technical Coach http://thinkinglabs.io @tdpauw