So you are considering going agile, huh? Your biggest question is probably "where do I start"? This session will help you answer that question and get you started down the road to agility . Mike will explore how to choose your first project and ensure that the pilot team is setup for success. He will talk through common organizational challenges and show you how to overcome them. You'll leave this talk with the knowledge necessary to get your first team going while laying the foundation to build on that success.
2. mike cottmeyervice-president, pillar technology semcottmeyer@pillartechnology.com+1.404.312.1471www.pillartechnology.comwww.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
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
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
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
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
105. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
116. Cadence and Trust Deal with breadth first, then depth Focus on good technical practices Build trust through delivery Communicating status to the business
148. The Pillar Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
149. The Pillar Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
150. The Pillar Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
151. The Pillar Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
152. The Pillar 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
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?
So, before we get started, a little about me. My name is Mike Cottmeyer, I am an agile transformation coach with Pillar technology. Before I joined Pillar I was a trainer and consultant with VersionOne. Before that I ran a pretty large agile portfolio of projects for CheckFree (now Fiserv). Pillar Technology has been around for about 13 years and is just about 100 people strong. Pillar specializes in agile transformation and project delivery. We can bring in agile coaches on the leadership and project management side. We can bring in coaches to help you with TDD. We can spin up teams and help you deliver projects.
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.