• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Mike Cottmeyer - How to Get Started with Agile
 

Mike Cottmeyer - How to Get Started with Agile

on

  • 788 views

presented at Southern Fried Agile 2010.

presented at Southern Fried Agile 2010.
southernfriedagile.com

Statistics

Views

Total Views
788
Views on SlideShare
788
Embed Views
0

Actions

Likes
2
Downloads
40
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.

Mike Cottmeyer - How to Get Started with Agile Mike Cottmeyer - How to Get Started with Agile Presentation Transcript

  • Getting Started with Agile
    Mike Cottmeyer
  • mike cottmeyerenterprise agile coach
    mike@cottmeyer.com404.312.1471www.leadingagile.comtwitter.com/mcottmeyer
  • “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
  • Culture & Structure
    People, Process & Tools
  • Traditional Enterprise
    Team
    Team
    Team
    Agile Teams
  • Agile Team
  • Agile Team
  • 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
  • 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
  • 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
  • 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
  • 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
  • Focusing on Value Creation
  • What Do We Deliver?
    Project focused organizations
    Product focused organizations
    Operations focused organizations
  • What Do We Deliver?
    • Investments across products not level
    • Investments across multiple products
    • Business case made for each investment
    • People vary project to project
    • Teams tend to form and re-form as projects spin up
    Project focused organizations
    Product focused organizations
    Operations focused organizations
  • What Do We Deliver?
    • Incremental ongoing investment in a single product
    • Investment is pre-approved and scope is negotiated release to release
    • Team members tend to be stable across releases
    • Teams better able to stay together
    Project focused organizations
    Product focused organizations
    Operations focused organizations
  • What Do We Deliver?
    • Similar in form to product focused
    • Teams can stay together
    • Investments are level over time
    • Characterized by rapid changes to the product backlog based on immediate customer demand
    Project focused organizations
    Product focused organizations
    Operations focused organizations
  • What Do We Value?
    Emergent outcomes
    Predictive outcomes
    Managing flow
  • What Do We Value?
    • Change is encouraged
    • Focused on optimizing business outcomes
    • Features vary based on customer input
    • Agile is primarily a mechanism for fast feedback from customers on what to build
    Emergent outcomes
    Predictive outcomes
    Managing flow
  • What Do We Value?
    • Change is not as desirable
    • Convergence over emergence
    • Customer has a clear idea of what they expect
    • Agile is primarily a mechanism for rapid risk reduction, and learning
    Emergent outcomes
    Predictive outcomes
    Managing flow
  • What Do We Value?
    • Constantly changing backlog
    • Need a way to understand capacity
    • Need a way to make and meet short term commitments
    • Agile is primarily a scheduling mechanism
    Emergent outcomes
    Predictive outcomes
    Managing flow
  • Choosing The Agile Pilot
    Value
    Constraint
    Risk
  • Choosing The Agile Pilot
    Value
    Constraint
    Risk
    Value
    Creation
  • Choosing The Agile Pilot
    Value
    Constraint
    Risk
    Value
    Creation
    Improvement
    Opportunity
  • Choosing The Agile Pilot
    Value
    Constraint
    Risk
    Agile Pilot Team
  • Setting Up the Team and Getting Started
  • Building Your Team
  • Developers
  • Testers
    Developers
  • Analyst
    Testers
    Developers
  • Analyst
    PM
    Testers
    Developers
  • Analyst
    CSM
    Testers
    Developers
  • Product Owner
    Analyst
    CSM
    Testers
    Developers
  • http://www.situational.com/
  • Forming
    http://www.situational.com/
  • Storming
    Forming
    http://www.situational.com/
  • Storming
    Norming
    Forming
    http://www.situational.com/
  • Storming
    Norming
    Forming
    Performing
    http://www.situational.com/
  • Team
  • Feature
    Feature
    Feature
    Feature
    Feature
    Feature
  • Feature
    Feature
    Screen
    Feature
    Report
    Feature
    Database
    Feature
    Feature
  • Choosing Your Methodology
  • Team
  • Team
    Scrum
  • Team
    Scrum
    XP
  • Team
    Scrum
    XP
    AUP
  • Team
    Scrum
    DSDM
    XP
    AUP
  • Team
    Scrum
    DSDM
    XP
    AUP
    Lean
  • Team
    Kanban
    Scrum
    DSDM
    XP
    AUP
    Lean
  • Linking to the Enterprise
  • I1-N
  • I1-N
    I0
  • I1-N
    I0
    IH
  • Construction
    Elab.
    Inc.
    Trans.
    I1-N
    I0
    IH
  • Initiate
    Plan
    Execute
    Monitor & Control
    Close
    Construction
    Elab.
    Inc.
    Trans.
    I1-N
    I0
    IH
  • Establishing a Delivery Cadence and Building Trust
  • Cadence and Trust
    Deal with breadth first, then depth
    Focus on good technical practices
    Build trust through delivery
    Communicating status to the business
  • Cadence and Trust
    Deal with breadth first, then depth
    Focus on good technical practices
    Build trust through delivery
    Communicating status to the business
  • http://www.methodsandtools.com/
  • Epic
    Epic
    Epic
    Epic
  • Feature
    Epic
    Feature
    Feature
    Feature
    Epic
    Feature
    Epic
    Feature
    Epic
  • Feature
    Epic
    User Story
    User Story
    Feature
    User Story
    User Story
    Feature
    User Story
    User Story
    Feature
    Epic
    User Story
    Feature
    Epic
    Feature
    Epic
  • User Story
    Screen
    User Story
    User Story
    Report
    User Story
    User Story
    Database
    User Story
    User Story
  • User Story
    Screen
    User Story
    User Story
    Report
    User Story
    User Story
    Database
    User Story
    User Story
  • Cadence and Trust
    Deal with breadth first, then depth
    Focus on good technical practices
    Build trust through delivery
    Communicating status to the business
    • Test Driven Development
    • Continuous Integration
    • Pair Programming
    • Refactoring
    Screen
    Report
    Database
    • Test Driven Development
    • Continuous Integration
    • Pair Programming
    • Refactoring
    Screen
    Report
    Database
    • Test Driven Development
    • Continuous Integration
    • Pair Programming
    • Refactoring
    Screen
    Report
    Database
    • Test Driven Development
    • Continuous Integration
    • Pair Programming
    • Refactoring
    Screen
    Report
    Database
    • Test Driven Development
    • Continuous Integration
    • Pair Programming
    • Refactoring
    Screen
    Report
    Database
  • Cadence and Trust
    Deal with breadth first, then depth
    Focus on good technical practices
    Build trust through delivery
    Communicating status to the business
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Organizational Roadmap
    Release
    Release
    Release
    I1
    I2
    I3
    I4
    I5
    I6
    I7
    I8
    I9
  • Cadence and Trust
    Deal with breadth first, then depth
    Focus on good technical practices
    Build trust through delivery
    Communicating status to the business
  • Burndown
    Graphs
  • Burndown
    Graphs
  • Burndown
    Graphs
  • Agile Team
  • RYG
    Status
    EVM
    Agile Team
    Gantt Charts
    Risk Burndown
  • Removing Common Impediments
  • Clearing Impediments
    Matrixing
    Power & Politics
    Mixed mode teams
    Unclear expectations
    High velocity, low value
    • Specializing generalists
    • Safety
    • Product Ownership
    • Well communicated expectations
    • Create real value
  • Clearing Impediments
    Matrixing
    Power & Politics
    Mixed mode teams
    Unclear expectations
    High velocity, low value
    • Specializing generalists
    • Safety
    • Product Ownership
    • Well communicated expectations
    • Create real value
  • Clearing Impediments
    Matrixing
    Power & Politics
    Mixed mode teams
    Unclear expectations
    High velocity, low value
    • Specializing generalists
    • Safety
    • Product Ownership
    • Well communicated expectations
    • Create real value
  • Clearing Impediments
    Matrixing
    Power & Politics
    Mixed mode teams
    Unclear expectations
    High velocity, low value
    • Specializing generalists
    • Safety
    • Product Ownership
    • Well communicated expectations
    • Create real value
  • Clearing Impediments
    Matrixing
    Power & Politics
    Mixed mode teams
    Unclear expectations
    High velocity, low value
    • Specializing generalists
    • Safety
    • Product Ownership
    • Well communicated expectations
    • Create real value
  • Clearing Impediments
    Matrixing
    Power & Politics
    Mixed mode teams
    Unclear expectations
    High velocity, low value
    • Specializing generalists
    • Safety
    • Product Ownership
    • Well communicated expectations
    • Create real value
  • The Approach
    Baseline agility assessments
    Enterprise value modeling
    Current reality diagrams
    Coaching and training
    Control teams
  • The Approach
    Baseline agility assessments
    Enterprise value modeling
    Current reality diagrams
    Coaching and training
    Control teams
  • The Approach
    Baseline agility assessments
    Enterprise value modeling
    Current reality diagrams
    Coaching and training
    Control teams
  • The Approach
    Baseline agility assessments
    Enterprise value modeling
    Current reality diagrams
    Coaching and training
    Control teams
  • The Approach
    Baseline agility assessments
    Enterprise value modeling
    Current reality diagrams
    Coaching and training
    Control teams
  • The Approach
    Baseline agility assessments
    Enterprise value modeling
    Current reality diagrams
    Coaching and training
    Control teams
  • Learning Outcomes
    Focus on measurable value
    Build organizations around agile teams
    Working, valuable software builds trust
    Inspect and adapt and get better
  • Learning Outcomes
    Focus on measurable value
    Build organizations around agile teams
    Working, valuable software builds trust
    Inspect and adapt and get better
  • Learning Outcomes
    Focus on measurable value
    Build organizations around agile teams
    Working, valuable software builds trust
    Inspect and adapt and get better
  • Learning Outcomes
    Focus on measurable value
    Build organizations around agile teams
    Working, valuable software builds trust
    Inspect and adapt and get better
  • Learning Outcomes
    Focus on measurable value
    Build organizations around agile teams
    Working, valuable software builds trust
    Inspect and adapt and get better
  • Replicate your success!
  • mike cottmeyerenterprise agile coach
    mike@cottmeyer.com404.312.1471www.leadingagile.comtwitter.com/mcottmeyer
  • Getting Started with Agile
    Mike Cottmeyer
    www.leadingagile.com