Mike Cottmeyer - How to Get Started with Agile
•Download as PPTX, PDF•
3 likes•802 views
presented at Southern Fried Agile 2010. southernfriedagile.com
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Mike Cottmeyer - How to Get Started with Agile
Similar to Mike Cottmeyer - How to Get Started with Agile (20)
More from SFA
More from SFA (6)
Recently uploaded
Recently uploaded (20)
Mike Cottmeyer - How to Get Started with Agile
- 1. Getting Started with Agile Mike Cottmeyer
- 2. mike cottmeyerenterprise agile coach mike@cottmeyer.com404.312.1471www.leadingagile.comtwitter.com/mcottmeyer
- 3. “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”Ken SchwaberFebruary 2008
- 4. Culture & Structure People, Process & Tools
- 5. Traditional Enterprise Team Team Team Agile Teams
- 6. Agile Team
- 7. Agile Team
- 8. Agenda How to focus on value creation Setting up the team and getting started Establishing a delivery cadence and building trust Clearing the way and replicating success
- 9. Agenda How to focus on value creation Setting up the team and getting started Establishing a delivery cadence and building trust Clearing the way and replicating success
- 10. Agenda How to focus on value creation Setting up the team and getting started Establishing a delivery cadence and building trust Clearing the way and replicating success
- 11. Agenda How to focus on value creation Setting up the team and getting started Establishing a delivery cadence and building trust Clearing the way and replicating success
- 12. Agenda How to focus on value creation Setting up the team and getting started Establishing a delivery cadence and building trust Clearing the way and replicating success
- 13. Focusing on Value Creation
- 14. What Do We Deliver? Project focused organizations Product focused organizations Operations focused organizations
- 16. Investments across multiple products
- 17. Business case made for each investment
- 18. People vary project to project
- 19. Teams tend to form and re-form as projects spin upProject focused organizations Product focused organizations Operations focused organizations
- 21. Investment is pre-approved and scope is negotiated release to release
- 22. Team members tend to be stable across releases
- 23. Teams better able to stay togetherProject focused organizations Product focused organizations Operations focused organizations
- 25. Teams can stay together
- 26. Investments are level over time
- 27. Characterized by rapid changes to the product backlog based on immediate customer demandProject focused organizations Product focused organizations Operations focused organizations
- 28. What Do We Value? Emergent outcomes Predictive outcomes Managing flow
- 30. Focused on optimizing business outcomes
- 31. Features vary based on customer input
- 32. Agile is primarily a mechanism for fast feedback from customers on what to buildEmergent outcomes Predictive outcomes Managing flow
- 35. Customer has a clear idea of what they expect
- 36. Agile is primarily a mechanism for rapid risk reduction, and learningEmergent outcomes Predictive outcomes Managing flow
- 38. Need a way to understand capacity
- 39. Need a way to make and meet short term commitments
- 40. Agile is primarily a scheduling mechanismEmergent outcomes Predictive outcomes Managing flow
- 41. Choosing The Agile Pilot Value Constraint Risk
- 42. Choosing The Agile Pilot Value Constraint Risk Value Creation
- 43. Choosing The Agile Pilot Value Constraint Risk Value Creation Improvement Opportunity
- 44. Choosing The Agile Pilot Value Constraint Risk Agile Pilot Team
- 45. Setting Up the Team and Getting Started
- 47. Developers
- 50. Analyst PM Testers Developers
- 51. Analyst CSM Testers Developers
- 52. Product Owner Analyst CSM Testers Developers
- 56. Storming Norming Forming http://www.situational.com/
- 57. Storming Norming Forming Performing http://www.situational.com/
- 58. Team
- 59. Feature Feature Feature Feature Feature Feature
- 60. Feature Feature Screen Feature Report Feature Database Feature Feature
- 62. Team
- 63. Team Scrum
- 64. Team Scrum XP
- 65. Team Scrum XP AUP
- 66. Team Scrum DSDM XP AUP
- 67. Team Scrum DSDM XP AUP Lean
- 68. Team Kanban Scrum DSDM XP AUP Lean
- 69. Linking to the Enterprise
- 70. I1-N
- 71. I1-N I0
- 72. I1-N I0 IH
- 73. Construction Elab. Inc. Trans. I1-N I0 IH
- 74. Initiate Plan Execute Monitor & Control Close Construction Elab. Inc. Trans. I1-N I0 IH
- 75. Establishing a Delivery Cadence and Building Trust
- 76. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
- 77. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
- 79. Epic Epic Epic Epic
- 80. Feature Epic Feature Feature Feature Epic Feature Epic Feature Epic
- 81. Feature Epic User Story User Story Feature User Story User Story Feature User Story User Story Feature Epic User Story Feature Epic Feature Epic
- 82. User Story Screen User Story User Story Report User Story User Story Database User Story User Story
- 83. User Story Screen User Story User Story Report User Story User Story Database User Story User Story
- 84. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
- 87. Pair Programming
- 91. Pair Programming
- 95. Pair Programming
- 99. Pair Programming
- 103. Pair Programming
- 105. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
- 106. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 107. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 108. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 109. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 110. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 111. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 112. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 113. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 114. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 115. Organizational Roadmap Release Release Release I1 I2 I3 I4 I5 I6 I7 I8 I9
- 116. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
- 117. Burndown Graphs
- 118. Burndown Graphs
- 119. Burndown Graphs
- 120. Agile Team
- 121. RYG Status EVM Agile Team Gantt Charts Risk Burndown
- 124. Safety
- 125. Product Ownership
- 128. Safety
- 129. Product Ownership
- 132. Safety
- 133. Product Ownership
- 136. Safety
- 137. Product Ownership
- 140. Safety
- 141. Product Ownership
- 144. Safety
- 145. Product Ownership
- 148. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 149. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 150. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 151. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 152. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 153. Learning Outcomes Focus on measurable value Build organizations around agile teams Working, valuable software builds trust Inspect and adapt and get better
- 154. Learning Outcomes Focus on measurable value Build organizations around agile teams Working, valuable software builds trust Inspect and adapt and get better
- 155. Learning Outcomes Focus on measurable value Build organizations around agile teams Working, valuable software builds trust Inspect and adapt and get better
- 156. Learning Outcomes Focus on measurable value Build organizations around agile teams Working, valuable software builds trust Inspect and adapt and get better
- 157. Learning Outcomes Focus on measurable value Build organizations around agile teams Working, valuable software builds trust Inspect and adapt and get better
- 159. mike cottmeyerenterprise agile coach mike@cottmeyer.com404.312.1471www.leadingagile.comtwitter.com/mcottmeyer
- 160. Getting Started with Agile Mike Cottmeyer www.leadingagile.com
Editor's Notes
- Hello everyone. Welcome to my talk, ‘Getting Started With Agile’. When Leeann asked me if I was interested in doing something, I was like ‘sure’… let me pull out one of my agile transformation decks… I wanted to do something on scaling in the enterprise. Maybe something on Lean Enterprise Portfolio Management. She was like “no”. For this one, we want to start with more of an intro talk. I don’t know about you, but I’m assuming that if taken then time to spend your lunch break with me, you probably have a decent understanding of at least the basics of agile. I didn’t want to do a ‘This is Scrum’ talk. So, my goal here isn’t to tell you anything about what agile is or, even how to do it.. What I want you to leave with is how to get started… where to start…the decisions you need to make to spin up a pilot team… and how to avoid some of the mistakes that cause new agile initiatives to fail. The whole goal is to get you started down the right path. Cool? Cool?
- Last year I was at the Scrum Gathering in Orland and heard Ken Schwaber make the folllowing comment…“I estimate…”That was pretty shocking… when I went to look for the quote… I found out that he made the original statement back in February of 2008. “I estimate…”Why do you think that is. Some people might tell you it is because people don’t properly implement Scrum. They bend the rules to make Scrum conform to their environment. What’s our answer… more Scrum training. Read more books. I suspect that the problem is more fundamental than merely just a lack of knowledge.
- Over the past few years, I have worked with dozens of companies that are just not fundamentally structured to take advantage of Scrum. They don’t have the management structures right and they do not have a culture that supports the openness and transparency that agile requires to help you be successful. At the end of the day, your culture and structure will trump any work that you do around people, processes, and even tools. You can have great people, but if the weight of the organization is working against them every day, it is a slow uphill climb. Agile, for the most part, does not address enterprise processes. Unless our agile teams are aware, and can function, in the environment around them… they are likely to fail. Tooling can help reinforce the discipline and structure of agile, but at the end of the day… tooling can do a re-org for you or do anything to get past your corporate politics.
- Most of the time I write about enterprise transformation… how to take a big complicated organization and incrementally adopt agile using a mix of top-down and bottom up approaches. The problem is that, for the most part… I have to be talking to someone pretty high up the food chain for that kind of a message to resonate. Most people, probably many of you… don’t have the ability to boil the ocean. You might have some local influence and can probably make a real difference at the team level. What this talk is trying to address is how you can spin up agile teams within in a more traditional organization, and give them every opportunity to be successful.
- A bunch of what we talk about in agile is how to make the team high performing. How to build culture within the team. Bow the team delivers valuable working software. That is great but it is very inwardly focused… it is focused on software development. It is focused on team level best practices. The challenge is that for everything we do to keep teams together and make them high performing….
- There are even more forces poised to pull them apart. I mentioned in my intro that I used to run a pretty large portfolio of agile projects. We had about 100 people working in the organization. We were using a mix of XP and Scrum… we wrapped our XP and Scrum within an enterprise language that was RUP and PMI and we were totally kicking butt. We were delivering potentially shippable code every two weeks across a pretty complex overall systems architecture. I would have considered us a high-performing team. If we were so good then… why did our group get broken up in the last corporate re-org. Why didn’t the larger organization see that value we were delivering week in and week out. A couple of years removed from that experience, I would say that it was because our definition of value was different from how the larger organization defined value.
- So that is how I want to get this talk started….
- I want to talk about how we understand value from the point of view of our business. How we can choose a pilot project… or a pilot product… or a pilot team… to start getting value out the door as fast as possible. Real business value… not something the dev team thinks is valuable. If we aren’t doing a pilot, and our effort is more grass roots, we already have a team in place, we can talk about how to make sure our team is fully connected to the enterprise value stream. I really believe that the reason for Schwaber’s 75% comment is because most Scrum teams… especially those in larger organizations… are not synced up with the rest of the delivery organization
- Next I want to talk about some fundamentals of agile teams, how to set them up, and why they work. We’ll talk about how to choose an agile methodology that suits your team and works well within your organization. Scrum might be the most popular agile methodology, but it is not the only agile methodology. Next we’ll talk about how to link your agile methodology with everything else that is going on in your business. We’ll talk briefly about how agile fits into the larger enterprise context. This section is really about building teams and linking their value our to the rest of the organization.
- Deal with breadth first, then depthFocus on good technical practicesBuild trust through deliveryCommunicating status to the business
- MatrixingPower & PoliticsMixed mode teamsUnclear expectationsHigh velocity, low valueClose with how Pillar helps solve some of these problems
- Okay… so let’s get started talking about value creation…
- I follow over 400 blogs and periodically I’ll see debates flare up about what agile is and what it’s for. I hear people argue that agile has nothing to do with project management…. That agile is a product development framework. Coming from a project management background, I tend to look at it just the opposite… I see agile as a project management framework that is really good at delivering products. Some folks don’t seem to be focused on product or projects and look at agile as a way to manage operations. The reality is that agile can be all three… it just depends on your perspective. Blind men and the elephant. The reason this is important…. Is that your organization values something. There is some increment of production that is important. When we are spinning up agile teams, we need to be aware of that increment of production. We can get dogmatic about what the organization ‘should’ value, but we need to be brutally clear about what it ‘does’ value. One of the first things we want to do is understand how to link our agile team to how the business defines and creates value. So I want to talk briefly about the three primary value models and how they are different and how they might impact your agile team.
- When I think of a project based organization… I think of one where Investments across products not levelInvestments across multiple productsBusiness case made for each investmentPeople vary project to projectTeams tend to form and re-form as projects spin up
- A product based organization, on the other hand means one where we have:Incremental ongoing investment in a single productInvestment is pre-approved and scope is negotiated release to releaseTeam members tend to be stable across releasesTeams better able to stay togetherThis tends to be where we find most agile thinking, very product focused. Either is okay… either can be agile… it’s just that we have to tailor our expectations to the real nature of our business
- From an agile perspective, I would say that an operationally focused business is more focused on responding to customers immediate needs. They are:Similar in form to product focusedTeams can stay togetherInvestments are level over timeCharacterized by rapid changes to the product backlog based on immediate customer demandWhat’s interesting about these organizations is that some of the typical Scrum and XP language around sprints and iterations doesn’t make sense. What is a sprint commitment look like when I KNOW I am going to have to make changes mid-stream. Again… another valid business model… we just want to make sure we are intention about how we proceed.
- The other discussion I see quite frequently is around the level to which we define our work. How and when are requirements defined? How and when is architecture and design done? One of the things that really turns people off from agile is this idea of emergent requirements and emergent design. The typical objection is ‘how can I know what to invest if I don’t know what I am going to get for that investment’. I think that is a fair question. Not every organization has the same tolerance for ambiguity and uncertainty. We want to make sure that we are aware of our organizations tolerance for uncertainty before we get started. What does our organization ‘think’ it needs to know before we get started. Again… we can ‘want’ our organization to be good with uncertainty, that doesn’t mean it ‘is’ good with uncertainty. We want to tailor our approach so we can be successful.
- There are some environments where emergent outcomes are desirable. I always think of Google in this context. Google sells advertising. There is a bunch of stuff they can build to sell advertising. I mean… they can do anything from search engines to handset hardware to maps. That is a great environment for inspection and adaptation… they can put thin slices in market, get feedback, and learn with minimal risk and minimal investment. Change is encouragedFocused on optimizing business outcomesFeatures vary based on customer inputAgile is primarily a mechanism for fast feedback from customers on what to build
- The are some companies that just don’t operate that way. I came out of the financial services industry where we worked a lot with banks… very little emergence in the requirements. What about medical devices or the software that helps run fighter jets. There might be some ability to work with an emerging set of requirements, some ability to emerge the architecture… but I think of these environments as more goal directed. Change is not as desirableConvergence over emergenceCustomer has a clear idea of what they expectAgile is primarily a mechanism for rapid risk reduction, and learning
- Our more operationally focused environments just need to be able predict when they’ll be finished with one thing so they can start on the next. They need to know things like queue depth and how long it takes the average item to get finished. Constantly changing backlogNeed a way to understand capacityNeed a way to make and meet short term commitmentsAgile is primarily a scheduling mechanis… a way to manage flowSo all of these needs are different and they are all valid. The cool thing is that our community has developed approaches to help with them all. Again, we just want to be intention about what we are choosing to do.
- So now we have some idea of what we want our team to build (projects, products, or operations) and a little about what that is going to mean to our agile teams. Now we want to think about where to focus our pilot team. There are three variables we want to consider: value, constraint, and risk
- This is the set of possible value creating in the organizations:ProjectsProduct FeaturesOperationsHere we are making sure to link to something that is clearly mapped to some market opportunity… some improved business process… something that the business will care about.
- Next, we want to find where that value is constrained. In most larger organizations, it takes more than just the development team to deliver a product. More often than not, it takes more than one *development* team to build a product. If our goal is optimize value… to optimize business outcomes… it doesn’t do us any good to get better at things that are not constraining value. I want to look for the critical path and find ways to make it go faster.
- In general, you’ll want to spin up your team around an opportunity that will create value and focus your investment on improving the areas of the business that are most likely to get the value delivered faster. You also want to take into consideration risk. There is risk if we do something and there is risk if we don’t. You’ll have to take into consideration
- Key Points:Teams have all the skills they need to deliver an increment of working softwareWe rely on specializing generalists to level out some of the ebb and flow of skillset demandEveryone doesn’t have to know how to do everything, but people on agile teams need to be able to do more than one thing.
- 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.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- We want teams to stay together. One of the important aspects of agile… one of the things that makes it so powerful is that we rely on the teams to be self-organizing, and to some degree.. self-managing. That requires a really different leadership style, and it requires a really mature team. We can see from the Situatonal Leadership model, that as teams move through the various quadrants, leaders can move from more directing behavior to more developing behavior, but it is all based on the maturity of the team. We are all familiar with the forming, storming, norming, performing model. Most organizations keep their teams is a continuous state of forming and storming and therefore require a heavier management style. Light-touch leadership requires a mature team, mature teams get mature by working together of longer periods of time.
- The idea is that we have these relatively persistent, very mature teams, within the organization, these teams work from a prioritized product backlog, and develop working software in a very reliable and predictable manner. Projectized organizations are often build teams around projects… if that happens, we will take a greater hit on the front side having to be more directive. If we can keep teams together, and bring projects to teams, we are better positioned to get the benefits of self-organization. You just have to know how your organization thinks about this and mitigate the risk. Product and Operationally focused organizations tend to have less problem with this.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Now it’s a matter of figuring out an approach that works for you and your business. Most small teams find themselves with a mixture of scrum and XP. That is a good blend of inspect and adapt project management framework, empirical process control, and the technical practices. Back in my portfolio management days, we put a AUP wrapper around our Scrum and XP because it better enabled us to extend agile into the enterprise. DSDM is good at this as well. Some folks, especially in more operationally focused organizations are starting to look at Kanban to do away with some of the overhead associated with sprint planning and to help managers have a few more hooks to help the teams become more successful. We are starting to hear a bunch about using lean and TOC to help manage enterprise portfolios. The book I am writing is all about understanding your value drivers… understanding your constraints… and choosing practices from the various methodologies that will best position you to be successful.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- One of the biggest challenges with many new agile teams, is that they get focused on what they are doing and forget about the rest of the business and delivery processes. Scrum and XP tend to live here in iterations 1 –NWe are starting to acknowledge that in some environments, we need to have an iteration 0 to deal with backlog and setup and architectural spikes. Sometimes we need to have a hardening iteration to do final packaging, maybe some UAT, and get the product ready for deployment. I mentioned that we were putting a AUP wrapper around Scrum and XP. We were dealing with solving the business problem in Inception and then integrating our systems into the customers environment during transition. Furthermore, there were processes for getting work started and closed down that lived even further outside my development processes. You might be dealing with Audit and Governance, CMMi and ITIL. If we want our agile pilot to be successful, we have to be aware of everything that goes on around it. We have to have hooks into the rest of the business. That is not to say that we don’t want to leverage our success to influence these teams to be more lightweight and adaptive, but we can’t pretend these groups don’t exist or they will ultimately crush our agile pilot. We have to figure out how to play nice.
- So now we have defined the business problem we are going to solve. We understand our constraint and how to best leverage our resources. We have formed our teamWe have decided the approach that best suits them and the businessAnd we have some idea the constraints the rest of the organization is going to put on usWe have done this in a way that is respectful of how the business defines valueIn a way that is respectful of what the business’ tolerance for uncertaintyThe idea is that now… when our team is successful… we are hooked to a real business problem and playing nice with the rest of the organization. Our success isn’t buried in the bowels of a larger organization… we are not an underground movement… we are visible and really performing. So how do we get down to the business of building software?
- This section is about starting with breadth (both from a requirements perspective and an architectural perspective) and then dealing with depth. Talk about the cone of uncertainty… what we can know when.Organizations expectations about uncertainty….Emergence or convergence or BUFD and rapid discovery
- Dealing with requirements uncertainty
- Dealing with architectural uncertainty
- We want to build in thin slices, validate the architecture… learn as we goNo matter the organizational constraints… we can operate this way.We use the information for emergence, convergence, or flow
- Technical practices are often overlooked, scrum doesn’t cover them, but solid technical practices are what enable the team to build in thin slices and do the whole emergence or convergence or flow thing.
- Test driven developmentCIPairingRefactoringShared code ownershipAutomated regression testingEmergent design
- The point is that we make small commitments, small commitments roll up in larger commitments. As we deliver sprint over sprint, we establish a velocity, we get predictable, we build trust with the organization. Tell the story about how my metrics were better than the PMO. I could pull a report for my portfolio in 2 hours that took the other PMs 2 days. Build trust through delivery.
- Explain burn downPast performance is a predictor of future performance.
- Often our metrics are inwardly focused, especially when we are only one team within a larger enterprise. Having an executive stakeholder come down to check out the burndown, while interesting, doesn’t give much context around the end-business value they create.
- Pretty often we find that we are having the translate our agile metrics into formats that are comfortable for the rest of the business. That might mean a RYG status report or even a high level Gantt chart. It is pretty easy to convert velocity to earned value, schedule variance, cost variance.