Adopting Agile in the Enterprise - Pillar Technology
•Download as PPTX, PDF•
6 likes•2,539 views
This is my talk on adopting agile in the enterprise in a new Pillar template
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Adopting Agile in the Enterprise - Pillar Technology
Similar to Adopting Agile in the Enterprise - Pillar Technology (20)
More from Mike Cottmeyer
More from Mike Cottmeyer (20)
Recently uploaded
Recently uploaded (20)
Adopting Agile in the Enterprise - Pillar Technology
- 1. Adopting Agile in the Enterprise Presented by: Mike Cottmeyer
- 2. mike cottmeyervice-president, pillar technology semcottmeyer@pillartechnology.com404.312.1471www.pillartechnology.comwww.leadingagile.com
- 3. Agile teams are foundational to building agile organizations
- 4. Agile teams are foundational to building agile organizations Coordinating multiple teams working on shared objectives is the core challenge
- 5. Agile teams are foundational to building agile organizations Coordinating multiple teams working on shared objectives is the core challenge Adopting agile in the enterprise is a systematic and incremental learning process
- 7. Team Level Adoption Multiple Teams… Replicate Success
- 8. Team Level Adoption Multiple Teams… Replicate Success First Order Agile… Projects
- 9. Team Level Adoption Multiple Teams… Replicate Success First Order Agile… Projects Second Order Agile… Programs and Portfolios
- 10. Team Level Adoption Multiple Teams… Replicate Success First Order Agile… Projects Second Order Agile… Programs and Portfolios Third Order Agile… Enterprise
- 11. Ideal Agile Team
- 12. Ideal Agile Team
- 13. Developers Ideal Agile Team
- 14. Testers Developers Ideal Agile Team
- 15. Analyst Testers Developers Ideal Agile Team
- 16. Analyst PM Testers Developers Ideal Agile Team
- 17. Analyst CSM Testers Developers Ideal Agile Team
- 18. Product Owner Analyst CSM Testers Developers Ideal Agile Team
- 20. Dev. A Traditional Team
- 21. QA Dev. A Traditional Team
- 22. QA BA Dev. A Traditional Team
- 23. QA BA Dev. PM A Traditional Team
- 24. QA BA Dev. PM PO A Traditional Team
- 25. QA BA Dev. PM PO The Project Team A Traditional Team
- 26. Phase One Analysis Design Build Test Deploy Phase Two Analysis Design Build Test Deploy Phase Three Analysis Design Build Test Deploy
- 27. Phase One Analysis Design Build Test Deploy Phase Two Analysis Design Build Test Deploy Phase Three Analysis Design Build Test Deploy
- 28. Phase One Analysis Design Build Test Deploy Phase Two Analysis Design Build Test Deploy Phase Three Analysis Design Build Test Deploy
- 29. Phase One Analysis Design Build Test Deploy Phase Two Analysis Design Build Test Deploy Phase Three Analysis Design Build Test Deploy
- 30. Phase One Analysis Design Build Test Deploy Phase Two Analysis Design Build Test Deploy Phase Three Analysis Design Build Test Deploy
- 31. Phase One Analysis Design Build Test Deploy Phase Two Analysis Design Build Test Deploy Phase Three Analysis Design Build Test Deploy
- 33. Where do I start?
- 34. An Agile Team
- 35. An Agile Team
- 36. Team An Agile Team
- 37. Team Features An Agile Team
- 38. Team Components Features An Agile Team
- 39. Team Components Services Features An Agile Team
- 40. Team Capabilities An Agile Team
- 41. Team Capabilities An Agile Team
- 42. Team Backlog An Agile Team
- 43. Team Velocity Backlog An Agile Team
- 44. Team Predictable Velocity Backlog An Agile Team
- 45. Team Predictable Trust Velocity Backlog An Agile Team
- 46. Build organizations around teams
- 47. Build organizations around teams Build small features
- 48. Build organizations around teams Build small features Garbage in… garbage out
- 49. Build organizations around teams Build small features Garbage in… garbage out Measure progress and get better
- 50. Multiple Teams
- 51. Capability 1 Multiple Teams
- 52. Capability 2 Capability 1 Multiple Teams
- 53. Capability 3 Capability 2 Capability 1 Multiple Teams
- 54. Scrum of Scrums Capability 2 Capability 1 Capability 3 Multiple Teams
- 55. Product Owner Team Capability 2 Capability 1 Capability 3 Multiple Teams
- 56. Product Owner Team with Architects Capability 2 Capability 1 Capability 3 Multiple Teams
- 57. Integration Team Capability 2 Capability 1 Capability 3 Multiple Teams
- 58. Context Capability 2 Capability 1 Capability 3 Multiple Teams
- 59. Context Coordination Capability 2 Capability 1 Capability 3 Multiple Teams
- 60. Product Owner too big
- 61. Product Owner too big Dependencies increase costs
- 62. Product Owner too big Dependencies increase costs Feature teams break down
- 63. Product Owner too big Dependencies increase costs Feature teams break down Velocity across teams
- 65. Project A Capability 2 Capability 1 Capability 3 Multiple Projects
- 66. Capability 2 Capability 1 Capability 3 Project B Project A Multiple Projects
- 67. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Multiple Projects
- 68. C1 C2 C3 Project A Project A Project A Project A Project A Project B Project A Project A Project B Project A Project B Project B Project A Project A Project B Project A Project A Project B Multiple Projects
- 69. C1 C2 C3 Project A Project A Project A Project A Project A Project B Project A Project A Project B Project A Project B Project B Project A Project A Project B Project A Project A Project B Project B Project B Project B Project B Project B Project B Project B Project B Multiple Projects
- 70. C1 C2 C3 Project A Project A Project A Project A Project A Project B Project A Project A Project B Project A Project B Project B Project A Project A Project B Project A Project A Project B Project B Project B Project C Project B Project B Project C Project B Project C Project C Project B Project B Project B Multiple Projects
- 71. Project A Project A Project A 3 months Project B Project B Project B Project C Project C Project C Multiple Projects
- 72. Project A Project A Project A 3 months Project B Project B Project B 6 months Project C Project C Project C Multiple Projects
- 73. Project A Project A Project A 3 months Project B Project B Project B 6 months Project C Project C 9 months Project C Multiple Projects
- 74. Project A Project B Project C Project A Project B Project C Project A 7 months Project B Project C Multiple Projects
- 75. Project A Project B Project C Project A Project B Project C Project A 7 months Project B 8 months Project C Multiple Projects
- 76. Project A Project B Project C Project A Project B Project C Project A 7 months Project B 8 months 9 months Project C Multiple Projects
- 77. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Multiple Projects
- 78. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Multiple Projects
- 79. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Multiple Projects
- 80. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project B Project B Project B Project B Project B Project B Project B Multiple Projects
- 81. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project B Project B Project B Project B Project B Project B Project B Project C Project C Project C Project C Project C Project C Project C Project C Project C Multiple Projects
- 82. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project B Project B Project B Project B Project B Project B Project B Project C Project C Project C Project C Project C Project C Project C Project C Project C Multiple Projects
- 83. C1 C2 C3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Refactoring Training Project B Project B Project B Project B Project B Project B Project B Refactoring Training Project C Project C Project C Project C Project C Project C Project C Project C Project C Multiple Projects
- 84. Build organizations around capabilities
- 85. Build organizations around capabilities Optimize throughput across teams
- 86. Build organizations around capabilities Optimize throughput across teams Prioritize for finish…
- 87. Build organizations around capabilities Optimize throughput across teams Prioritize for finish… Smaller projects are better
- 88. Agile Enterprise
- 90. PO Team PMO Agile Enterprise
- 91. Team PO Team PMO Agile Enterprise
- 92. Team PO Team PMO Enterprise Architecture & Epics Agile Enterprise
- 93. Team PO Team PMO Enterprise Architecture & Epics Solutions Architecture & Features Agile Enterprise
- 94. Team PO Team PMO Enterprise Architecture & Epics Solutions Architecture & Features Detailed Design & Stories Agile Enterprise
- 95. Guidance Team PO Team PMO Agile Enterprise
- 96. Feedback Team PO Team PMO Agile Enterprise
- 97. Not the entire business Product Delivery Agile Enterprise
- 98. Product Delivery Strategy Agile Enterprise
- 99. Support Product Delivery Strategy Agile Enterprise
- 100. Establish direction… give feedback
- 101. Establish direction… give feedback Business is made up of capabilities
- 102. Establish direction… give feedback Business is made up of capabilities The goal is greater profitability
- 103. Establish direction… give feedback Business is made up of capabilities The goal is greater profitability Focus improvements on constraints
- 104. Capability Modeling
- 106. Teams Identify Capability Modeling
- 107. Teams Define Identify Capability Modeling
- 108. Teams Define Assign Identify Capability Modeling
- 109. Teams Define Optimize Assign Identify Capability Modeling
- 110. Thoughts?
- 111. mike cottmeyervice-president, pillar technology semcottmeyer@pillartechnology.com404.312.1471www.pillartechnology.comwww.leadingagile.com
- 112. Adopting Agile in the Enterprise Presented by: Mike Cottmeyer
Editor's Notes
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- Let me tell you why I put this talk together. One of the great things about working with VersionOne is that I get to work with a lot of companies. I am only onsite for a few days at a time and over the past year I have worked with somewhere between 30 and 40 companies… at various levels of agile adoption. I work with small companies… big companies… and even a few really BIG companies. That is a lot of people trying to adopt agile. That means I get to talk with a lot of people trying to lead change within their organizations.
- People are trying to figure out how to effectively run iteration planning meetings and daily standups… they are struggling to figure out the best way to run a retrospectives… They are trying to get predictable…Almost universally I find that these companies are really struggling to create teams. The team concept is so foundational to adopting agile that if you don’t get this right… you have pretty much failed before you even got started. The ideal agile team is also a pretty specific concept and often antithetical to how we are current running our organizations when we decide to adopt agile.
- Agile teams are cross functional units that have everything they need to deliver some increment of business value. In a software organization… the agile team is going to have one or more developers…
- They will have one or more QA testers. Sometimes teams have technical testers that are responsible for writing unit tests… sometimes this is left up to the developers. Sometimes teams have manual testers… possibly exercising the UI. Many teams will do both kinds of testing.
- Sometimes a team will someone playing the role of business analyst. This can be a dedicated position on the team… or it might be blended with some other role… maybe a lead developer. Often times teams will have a BA that is serving as a proxy product owner for the real customer or product owner. Dedicated or blended Custome proxy
- Small agile teams don’t typically have or need a project manager. I believe that there is a place for project management on an agile teams… but often project managers are coordinating the activities of several teams and doing some higher level planning activities and providing.
- Agile teams will usually have someone in the role of ScrumMaster or Agile process coordinator. This can be a dedicated position on the team or a role that is shared with another role on the team. Sometimes you have a dedicated ScrumMaster but they are working with more than one agile team at a time.
- This is such a tough concept because the ideal agile team is so different from how we typically build teams in our organizations. We tend to think of teams as groups of people that do similar work.
- We usually build teams of developers…. We have a team of folks that write the cobol code… another that does the .NET development… and yet another that build out the web services…and yet another to do the database work.
- We have a dedicated team of QA professionals that report to a VP of Quality…
- … and a team of BA’s that all report to their own manager.
- We put all our project managers under a director of project management and is tucked up nice and neatly under the PMO…
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- When it comes time to think about doing projects… we think through the requirements… and then we go out to each of the resource silos and build a “project team” from each of these various skillset groups. These teams don’t typically stay together… often they don’t really even work together. They write large specification documents and hand off large batches of work across these functional silos. Because each team is responsible for optimizing its particular function… we get really good at writing code… we get really good at writing test plans and documenting defects. We get really good at creating charter documents and Gannt charts. What we don’t usually get very good at is delivering projects… we don’t get good at building working software… or delivering value back to the business. Often the exact opposite happens. Project delivery becomes slow… we build walls between the functional silos… we create environments where we protect our own interests rather than those of the business or our customers. We build large specifications that protect ourselves from the very people that we need to be in partnership with.
- Because we are not focused on delivering value… and we are focused on optimizing our particular silos… we get better within our silos and not at overall delivery. We develop specialized skills… we want to be the best QA guy we can be… we want to make sure that everyone is busy and that we are utilizing our dedicated resources as efficiently as possible. We start thinking about time slicing people cross multiple projects which results in very complex project portfolios and necessitates very complex resource utilization models.
- We try to measure and track when people are going to be done with one project so we can move them off to the next project.
- There is very little focus on delivering the working software… we are thinking about getting our piece done and moving on to the next most important project.
- Change becomes very hard difficult because… if anything needs to change… be it requirements… or if we found a defect in the design… folks have moved onto the next project.
- If the team slips a schedule you have a cascading series of changes that ripple through the entire project portfolio. In any moderately complex environment, this quickly becomes unstable and very difficult to manage.
- We in effect create a complex network of dependencies that cripple our organization and prevent us from responding to new information… or new opportunities… in a timely manner. If we are able to respond… we end up throwing all that detailed planning out the door to pursue the new opportunity. I have worked for maybe 5-6 PMOs in my time… and I have never really seen any of them do this well. The cost of all that planning… tracking all those dependencies is very high. Our organziations tend to be more complex… more fluid that all that detailed planning implies.
- Where does a company like this start? How do they go from this siloed and complex project portfolio… one that is trying to manage a complex set of dependencies… to one made up of loosely coupled and independent small agile teams. I hope it goes without saying that this is not a trivial problem. The problem is very similar to the challenge a software architect faces when trying to move from a tightly coupled systems architecture with low cohesion to a loosely coupled modular software architecture with well defined responsibilities and interfaces. The general approach is to look for services that you can pull out… one at a time… and build a parallel system based on sound architectural principles. You have to define what services you are going to pull out… what they are going to do… and how they are going to work with the legacy system to support the operations of the business. You build this new team based system along side the old way of doing things until the entire organization has moved to a team based model.
- There are quite a few ways of doing this… but we have decided that our goal is to build an agile organization. We want to take advantage of the benefits provided by a self-organized, self-managed team. We want to empower people and build trust… we want to improve morale and get people working on the most important things. We want the softer side of agile that makes small teams so effective delivering for the organization…. So we are going to focus on building our organization around small agile teams. I like to say that agile teams are the building blocks of agile organizations.
- If you’ve ever checked out either of my blogs… Agile Chronicles or Leading Agile… I quite often like to draw a team as a small circle with a little dot on it. The yellow circle is the team… the small blue dot is the product owner. It could also be a product manager… or a team lead… or even a development manager. It is basically the person that coordinates and defines the work for the team. The blue dot is half in the team and half out… not because they are not part of the team… but because they are the external interface to the rest of the business.
- So here is our small agile team.
- The literature says that agile teams build features… features are thin vertical slices of system functionality that span the entire software architecture. Features are things like ‘login to the system’ or ‘make a payment’. They are not tasks… they are not requirements or specifications… they are written in language that is valuable to and end user. Writing requirements this way is great for small teams. The team has everything… they have every role… they need to build the solution. The team is made up of folks that are specializing generalists… there is shared code ownership… team members level the work… it solves many of the project portfolio problems we talked about earlier in the presentation. It eliminates all the dependenies with the rest of the organzation. The problem is that at some level of scale this guidance is not going to hold. The largest program I managed had 17 large scale architectural components. Aside from the organizational issues we were facing… and the degree of specialization amongst the teams… a cross functional feature team would have had over 20 people to deliver a single customer facing feature. That is a pretty big agile team… and just wasn’t conducive to how the organization did business. In effect we were building a large scale system of systems. Each system was a product in its own right. Organizations struggle when they try to build these feature teams when that model is not conducive to their organzations.
- In these kinds of large scale projects… when we have large scale system components that have to integrate to deliver some large or complex end user feature… sometimes it makes sense to organize your agile teams around components. When I say component… I am not talking about the architectural layers of a small software system… and I am definitely not talking about building teams around skillset. I am taking about building a dedicated design/build/test team that is responsible for a major sub-system within the overall solutions architecture. They define their value as being able to provide a service to the other parts of the busiess. That is the inrement of busienss value
- Closely related to the idea of a componet team is the idea of a service team. If you are building your organzation around the idea of a services oriented architecture… you might want to consider forming your agile teams around a service or a collection of services. Just like with the component team… the services are integrated to deliver some overall business value back to the end-consumer. Insisting on the agile team being a feature team… working on some unit of business value… led by a single product owner is somewhat limiting at enterprise scale. You don’t have to be Microsoft to have this problem… this is common in organizations with as few as 100 people. This is a rule that works with small teamsIt is the place that I startIt needs adaptation in larger organzations.
- You might find that you use a combination of all three of these approaches… you’ll have feature teams that consume components and services built by other teams within the organization. We are in effect building teams around the delivery capabilities of the organization.Teams are the elemental units that deliver business value back to the business regardless of how that business value might actually be defined.
- Determining what capabilities to start withCoordinating capabilities to deliver the complex product objectives of the enterprise.Defining how these capabilities interact with each other and the legacy organizationThis is really the problem that we are trying to solve when we look at adopting and scaling agile in a meaningful way across the organization.
- When we start thinking in terms of capabilitiesIt is the responsibility of the larger organization to provide teams with the right stuff to work on, in the right order, with the right level of specificity such that they can produce the valuable outcomes that the business is expecting. Scrum assigns this responsibility to the product owner… this is fine in a small environment… but what many midsized organzations are learning is that the PO role is too big for a single person and are assigning this role to a team of people. The point is that we don’t have to be constrained by the limitations imposed by scrum. What the team needs is well groomed product backlog… if that can come from a single person… great… what we really need to do is to make sure that the team is always working on the highest value backlog items in synchronization with the rest of the business.
- When a team has a well groomed backlog… and you allow that team to stay together over time… that teams begins to establish a stable velocity. Velocity is the rate of flow through the team. How fast the team can deliver value back to the business.
- When I have a well groomed backlog and a stable velocity… the team becomes predictable. It establishes a predictable throughput. I can begin to predict when things will be done so I can effectively coordinate the activities of several teams working together on larger initiatives.
- And when teams become predictable, they establish trust with the rest of the organization. The business knows and understands it capacity and knows what it can commit to. If we want to know what the organization is capable of delivering… we have to first establish what the team is capable of delivering.
- As we begin to form organizations around teams… we learn certain things about building out our agile organizations…We learn that to establish stable throughput at the organizational level… we need stable throughput at the team level. To get this, we build our organizations around small agile teams.. In other words, teams are the building blocks of agile organziations.
- We also learn that having teams build small features helps to normalize our velocity and increase predictability. Building smaller gives the team more frequent measurement points to assess overall team throughput and lowers risk.
- We also learn that for teams to establish a stable velocity, it is important to have a well groomed and stable backlog. This mean that we have to know what the team is going to work on… the order it needs to be worked on… and how their work will integrate with the other parts of the overall business.
- By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
- Now that we have a pretty