Adopting Agile in the Enterprise - Pillar Technology
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Adopting Agile in the Enterprise - Pillar Technology

on

  • 1,965 views

This is my talk on adopting agile in the enterprise in a new Pillar template

This is my talk on adopting agile in the enterprise in a new Pillar template

Statistics

Views

Total Views
1,965
Views on SlideShare
1,851
Embed Views
114

Actions

Likes
5
Downloads
49
Comments
0

6 Embeds 114

http://www.projekt-log.de 87
http://piiar.wordpress.com 10
http://ahmedyahia.posterous.com 9
http://ahmedyahia.tumblr.com 5
http://www.slideshare.net 2
http://posterous.com 1

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
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • Let me tell you why I put this talk together. One of the great things about working with VersionOne is that I get to work with a lot of companies. I am only onsite for a few days at a time and over the past year I have worked with somewhere between 30 and 40 companies… at various levels of agile adoption. I work with small companies… big companies… and even a few really BIG companies. That is a lot of people trying to adopt agile. That means I get to talk with a lot of people trying to lead change within their organizations.
  • People are trying to figure out how to effectively run iteration planning meetings and daily standups… they are struggling to figure out the best way to run a retrospectives… They are trying to get predictable…Almost universally I find that these companies are really struggling to create teams. The team concept is so foundational to adopting agile that if you don’t get this right… you have pretty much failed before you even got started. The ideal agile team is also a pretty specific concept and often antithetical to how we are current running our organizations when we decide to adopt agile.
  • Agile teams are cross functional units that have everything they need to deliver some increment of business value. In a software organization… the agile team is going to have one or more developers…
  • They will have one or more QA testers. Sometimes teams have technical testers that are responsible for writing unit tests… sometimes this is left up to the developers. Sometimes teams have manual testers… possibly exercising the UI. Many teams will do both kinds of testing.
  • Sometimes a team will someone playing the role of business analyst. This can be a dedicated position on the team… or it might be blended with some other role… maybe a lead developer. Often times teams will have a BA that is serving as a proxy product owner for the real customer or product owner. Dedicated or blended Custome proxy
  • Small agile teams don’t typically have or need a project manager. I believe that there is a place for project management on an agile teams… but often project managers are coordinating the activities of several teams and doing some higher level planning activities and providing.
  • Agile teams will usually have someone in the role of ScrumMaster or Agile process coordinator. This can be a dedicated position on the team or a role that is shared with another role on the team. Sometimes you have a dedicated ScrumMaster but they are working with more than one agile team at a time.
  • This is such a tough concept because the ideal agile team is so different from how we typically build teams in our organizations. We tend to think of teams as groups of people that do similar work.
  • We usually build teams of developers…. We have a team of folks that write the cobol code… another that does the .NET development… and yet another that build out the web services…and yet another to do the database work.
  • We have a dedicated team of QA professionals that report to a VP of Quality…
  • … and a team of BA’s that all report to their own manager.
  • We put all our project managers under a director of project management and is tucked up nice and neatly under the PMO…
  • Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
  • When it comes time to think about doing projects… we think through the requirements… and then we go out to each of the resource silos and build a “project team” from each of these various skillset groups. These teams don’t typically stay together… often they don’t really even work together. They write large specification documents and hand off large batches of work across these functional silos. Because each team is responsible for optimizing its particular function… we get really good at writing code… we get really good at writing test plans and documenting defects. We get really good at creating charter documents and Gannt charts. What we don’t usually get very good at is delivering projects… we don’t get good at building working software… or delivering value back to the business. Often the exact opposite happens. Project delivery becomes slow… we build walls between the functional silos… we create environments where we protect our own interests rather than those of the business or our customers. We build large specifications that protect ourselves from the very people that we need to be in partnership with.
  • Because we are not focused on delivering value… and we are focused on optimizing our particular silos… we get better within our silos and not at overall delivery. We develop specialized skills… we want to be the best QA guy we can be… we want to make sure that everyone is busy and that we are utilizing our dedicated resources as efficiently as possible. We start thinking about time slicing people cross multiple projects which results in very complex project portfolios and necessitates very complex resource utilization models.
  • We try to measure and track when people are going to be done with one project so we can move them off to the next project.
  • There is very little focus on delivering the working software… we are thinking about getting our piece done and moving on to the next most important project.
  • Change becomes very hard difficult because… if anything needs to change… be it requirements… or if we found a defect in the design… folks have moved onto the next project.
  • If the team slips a schedule you have a cascading series of changes that ripple through the entire project portfolio. In any moderately complex environment, this quickly becomes unstable and very difficult to manage.
  • We in effect create a complex network of dependencies that cripple our organization and prevent us from responding to new information… or new opportunities… in a timely manner. If we are able to respond… we end up throwing all that detailed planning out the door to pursue the new opportunity. I have worked for maybe 5-6 PMOs in my time… and I have never really seen any of them do this well. The cost of all that planning… tracking all those dependencies is very high. Our organziations tend to be more complex… more fluid that all that detailed planning implies.
  • Where does a company like this start? How do they go from this siloed and complex project portfolio… one that is trying to manage a complex set of dependencies… to one made up of loosely coupled and independent small agile teams. I hope it goes without saying that this is not a trivial problem. The problem is very similar to the challenge a software architect faces when trying to move from a tightly coupled systems architecture with low cohesion to a loosely coupled modular software architecture with well defined responsibilities and interfaces. The general approach is to look for services that you can pull out… one at a time… and build a parallel system based on sound architectural principles. You have to define what services you are going to pull out… what they are going to do… and how they are going to work with the legacy system to support the operations of the business. You build this new team based system along side the old way of doing things until the entire organization has moved to a team based model.
  • There are quite a few ways of doing this… but we have decided that our goal is to build an agile organization. We want to take advantage of the benefits provided by a self-organized, self-managed team. We want to empower people and build trust… we want to improve morale and get people working on the most important things. We want the softer side of agile that makes small teams so effective delivering for the organization…. So we are going to focus on building our organization around small agile teams. I like to say that agile teams are the building blocks of agile organizations.
  • If you’ve ever checked out either of my blogs… Agile Chronicles or Leading Agile… I quite often like to draw a team as a small circle with a little dot on it. The yellow circle is the team… the small blue dot is the product owner. It could also be a product manager… or a team lead… or even a development manager. It is basically the person that coordinates and defines the work for the team. The blue dot is half in the team and half out… not because they are not part of the team… but because they are the external interface to the rest of the business.
  • So here is our small agile team.
  • The literature says that agile teams build features… features are thin vertical slices of system functionality that span the entire software architecture. Features are things like ‘login to the system’ or ‘make a payment’. They are not tasks… they are not requirements or specifications… they are written in language that is valuable to and end user. Writing requirements this way is great for small teams. The team has everything… they have every role… they need to build the solution. The team is made up of folks that are specializing generalists… there is shared code ownership… team members level the work… it solves many of the project portfolio problems we talked about earlier in the presentation. It eliminates all the dependenies with the rest of the organzation. The problem is that at some level of scale this guidance is not going to hold. The largest program I managed had 17 large scale architectural components. Aside from the organizational issues we were facing… and the degree of specialization amongst the teams… a cross functional feature team would have had over 20 people to deliver a single customer facing feature. That is a pretty big agile team… and just wasn’t conducive to how the organization did business. In effect we were building a large scale system of systems. Each system was a product in its own right. Organizations struggle when they try to build these feature teams when that model is not conducive to their organzations.
  • In these kinds of large scale projects… when we have large scale system components that have to integrate to deliver some large or complex end user feature… sometimes it makes sense to organize your agile teams around components. When I say component… I am not talking about the architectural layers of a small software system… and I am definitely not talking about building teams around skillset. I am taking about building a dedicated design/build/test team that is responsible for a major sub-system within the overall solutions architecture. They define their value as being able to provide a service to the other parts of the busiess. That is the inrement of busienss value
  • Closely related to the idea of a componet team is the idea of a service team. If you are building your organzation around the idea of a services oriented architecture… you might want to consider forming your agile teams around a service or a collection of services. Just like with the component team… the services are integrated to deliver some overall business value back to the end-consumer. Insisting on the agile team being a feature team… working on some unit of business value… led by a single product owner is somewhat limiting at enterprise scale. You don’t have to be Microsoft to have this problem… this is common in organizations with as few as 100 people. This is a rule that works with small teamsIt is the place that I startIt needs adaptation in larger organzations.
  • You might find that you use a combination of all three of these approaches… you’ll have feature teams that consume components and services built by other teams within the organization. We are in effect building teams around the delivery capabilities of the organization.Teams are the elemental units that deliver business value back to the business regardless of how that business value might actually be defined.
  • Determining what capabilities to start withCoordinating capabilities to deliver the complex product objectives of the enterprise.Defining how these capabilities interact with each other and the legacy organizationThis is really the problem that we are trying to solve when we look at adopting and scaling agile in a meaningful way across the organization.
  • When we start thinking in terms of capabilitiesIt is the responsibility of the larger organization to provide teams with the right stuff to work on, in the right order, with the right level of specificity such that they can produce the valuable outcomes that the business is expecting. Scrum assigns this responsibility to the product owner… this is fine in a small environment… but what many midsized organzations are learning is that the PO role is too big for a single person and are assigning this role to a team of people. The point is that we don’t have to be constrained by the limitations imposed by scrum. What the team needs is well groomed product backlog… if that can come from a single person… great… what we really need to do is to make sure that the team is always working on the highest value backlog items in synchronization with the rest of the business.
  • When a team has a well groomed backlog… and you allow that team to stay together over time… that teams begins to establish a stable velocity. Velocity is the rate of flow through the team. How fast the team can deliver value back to the business.
  • When I have a well groomed backlog and a stable velocity… the team becomes predictable. It establishes a predictable throughput. I can begin to predict when things will be done so I can effectively coordinate the activities of several teams working together on larger initiatives.
  • And when teams become predictable, they establish trust with the rest of the organization. The business knows and understands it capacity and knows what it can commit to. If we want to know what the organization is capable of delivering… we have to first establish what the team is capable of delivering.
  • As we begin to form organizations around teams… we learn certain things about building out our agile organizations…We learn that to establish stable throughput at the organizational level… we need stable throughput at the team level. To get this, we build our organizations around small agile teams.. In other words, teams are the building blocks of agile organziations.
  • We also learn that having teams build small features helps to normalize our velocity and increase predictability. Building smaller gives the team more frequent measurement points to assess overall team throughput and lowers risk.
  • We also learn that for teams to establish a stable velocity, it is important to have a well groomed and stable backlog. This mean that we have to know what the team is going to work on… the order it needs to be worked on… and how their work will integrate with the other parts of the overall business.
  • By keeping teams together…. Creating smaller work packages… and coordinating activities aross teams… we provide a platform that helps teams measure progress and get better over time.
  • Now that we have a pretty

Adopting Agile in the Enterprise - Pillar Technology Presentation Transcript

  • 1. Adopting Agile in the Enterprise
    Presented by: Mike Cottmeyer
  • 2. mike cottmeyervice-president, pillar technology semcottmeyer@pillartechnology.com404.312.1471www.pillartechnology.comwww.leadingagile.com
  • 3. Agile teams are foundational to building agile organizations
  • 4. Agile teams are foundational to building agile organizations
    Coordinating multiple teams working on shared objectives is the core challenge
  • 5. Agile teams are foundational to building agile organizations
    Coordinating multiple teams working on shared objectives is the core challenge
    Adopting agile in the enterprise is a systematic and incremental learning process
  • 6. Team Level Adoption
  • 7. Team Level Adoption
    Multiple Teams… Replicate Success
  • 8. Team Level Adoption
    Multiple Teams… Replicate Success
    First Order Agile… Projects
  • 9. Team Level Adoption
    Multiple Teams… Replicate Success
    First Order Agile… Projects
    Second Order Agile… Programs and Portfolios
  • 10. Team Level Adoption
    Multiple Teams… Replicate Success
    First Order Agile… Projects
    Second Order Agile… Programs and Portfolios
    Third Order Agile… Enterprise
  • 11. Ideal Agile Team
  • 12. Ideal Agile Team
  • 13. Developers
    Ideal Agile Team
  • 14. Testers
    Developers
    Ideal Agile Team
  • 15. Analyst
    Testers
    Developers
    Ideal Agile Team
  • 16. Analyst
    PM
    Testers
    Developers
    Ideal Agile Team
  • 17. Analyst
    CSM
    Testers
    Developers
    Ideal Agile Team
  • 18. Product Owner
    Analyst
    CSM
    Testers
    Developers
    Ideal Agile Team
  • 19. A Traditional Team
  • 20. Dev.
    A Traditional Team
  • 21. QA
    Dev.
    A Traditional Team
  • 22. QA
    BA
    Dev.
    A Traditional Team
  • 23. QA
    BA
    Dev.
    PM
    A Traditional Team
  • 24. QA
    BA
    Dev.
    PM
    PO
    A Traditional Team
  • 25. QA
    BA
    Dev.
    PM
    PO
    The Project Team
    A Traditional Team
  • 26. Phase One
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Two
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Three
    Analysis
    Design
    Build
    Test
    Deploy
  • 27. Phase One
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Two
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Three
    Analysis
    Design
    Build
    Test
    Deploy
  • 28. Phase One
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Two
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Three
    Analysis
    Design
    Build
    Test
    Deploy
  • 29. Phase One
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Two
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Three
    Analysis
    Design
    Build
    Test
    Deploy
  • 30. Phase One
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Two
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Three
    Analysis
    Design
    Build
    Test
    Deploy
  • 31. Phase One
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Two
    Analysis
    Design
    Build
    Test
    Deploy
    Phase Three
    Analysis
    Design
    Build
    Test
    Deploy
  • 32.
  • 33. Where do I start?
  • 34. An Agile Team
  • 35. An Agile Team
  • 36. Team
    An Agile Team
  • 37. Team
    Features
    An Agile Team
  • 38. Team
    Components
    Features
    An Agile Team
  • 39. Team
    Components
    Services
    Features
    An Agile Team
  • 40. Team
    Capabilities
    An Agile Team
  • 41. Team
    Capabilities
    An Agile Team
  • 42. Team
    Backlog
    An Agile Team
  • 43. Team
    Velocity
    Backlog
    An Agile Team
  • 44. Team
    Predictable
    Velocity
    Backlog
    An Agile Team
  • 45. Team
    Predictable
    Trust
    Velocity
    Backlog
    An Agile Team
  • 46. Build organizations around teams
  • 47. Build organizations around teams
    Build small features
  • 48. Build organizations around teams
    Build small features
    Garbage in… garbage out
  • 49. Build organizations around teams
    Build small features
    Garbage in… garbage out
    Measure progress and get better
  • 50. Multiple Teams
  • 51. Capability 1
    Multiple Teams
  • 52. Capability 2
    Capability 1
    Multiple Teams
  • 53. Capability 3
    Capability 2
    Capability 1
    Multiple Teams
  • 54. Scrum of Scrums
    Capability 2
    Capability 1
    Capability 3
    Multiple Teams
  • 55. Product Owner Team
    Capability 2
    Capability 1
    Capability 3
    Multiple Teams
  • 56. Product Owner Team with
    Architects
    Capability 2
    Capability 1
    Capability 3
    Multiple Teams
  • 57. Integration Team
    Capability 2
    Capability 1
    Capability 3
    Multiple Teams
  • 58. Context
    Capability 2
    Capability 1
    Capability 3
    Multiple Teams
  • 59. Context
    Coordination
    Capability 2
    Capability 1
    Capability 3
    Multiple Teams
  • 60. Product Owner too big
  • 61. Product Owner too big
    Dependencies increase costs
  • 62. Product Owner too big
    Dependencies increase costs
    Feature teams break down
  • 63. Product Owner too big
    Dependencies increase costs
    Feature teams break down
    Velocity across teams
  • 64. Multiple Projects
  • 65. Project A
    Capability 2
    Capability 1
    Capability 3
    Multiple Projects
  • 66. Capability 2
    Capability 1
    Capability 3
    Project
    B
    Project
    A
    Multiple Projects
  • 67. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Multiple Projects
  • 68. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project B
    Project A
    Project A
    Project B
    Project A
    Project B
    Project B
    Project A
    Project A
    Project B
    Project A
    Project A
    Project B
    Multiple Projects
  • 69. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project B
    Project A
    Project A
    Project B
    Project A
    Project B
    Project B
    Project A
    Project A
    Project B
    Project A
    Project A
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Multiple Projects
  • 70. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project B
    Project A
    Project A
    Project B
    Project A
    Project B
    Project B
    Project A
    Project A
    Project B
    Project A
    Project A
    Project B
    Project B
    Project B
    Project C
    Project B
    Project B
    Project C
    Project B
    Project C
    Project C
    Project B
    Project B
    Project B
    Multiple Projects
  • 71. Project A
    Project A
    Project A
    3 months
    Project B
    Project B
    Project B
    Project C
    Project C
    Project C
    Multiple Projects
  • 72. Project A
    Project A
    Project A
    3 months
    Project B
    Project B
    Project B
    6 months
    Project C
    Project C
    Project C
    Multiple Projects
  • 73. Project A
    Project A
    Project A
    3 months
    Project B
    Project B
    Project B
    6 months
    Project C
    Project C
    9 months
    Project C
    Multiple Projects
  • 74. Project A
    Project B
    Project C
    Project A
    Project B
    Project C
    Project A
    7 months
    Project B
    Project C
    Multiple Projects
  • 75. Project A
    Project B
    Project C
    Project A
    Project B
    Project C
    Project A
    7 months
    Project B
    8 months
    Project C
    Multiple Projects
  • 76. Project A
    Project B
    Project C
    Project A
    Project B
    Project C
    Project A
    7 months
    Project B
    8 months
    9 months
    Project C
    Multiple Projects
  • 77. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Multiple Projects
  • 78. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Multiple Projects
  • 79. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Multiple Projects
  • 80. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Multiple Projects
  • 81. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Multiple Projects
  • 82. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Multiple Projects
  • 83. C1
    C2
    C3
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Project A
    Refactoring
    Training
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Project B
    Refactoring
    Training
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Project C
    Multiple Projects
  • 84. Build organizations around capabilities
  • 85. Build organizations around capabilities
    Optimize throughput across teams
  • 86. Build organizations around capabilities
    Optimize throughput across teams
    Prioritize for finish…
  • 87. Build organizations around capabilities
    Optimize throughput across teams
    Prioritize for finish…
    Smaller projects are better
  • 88. Agile Enterprise
  • 89. PMO
    Agile Enterprise
  • 90. PO Team
    PMO
    Agile Enterprise
  • 91. Team
    PO Team
    PMO
    Agile Enterprise
  • 92. Team
    PO Team
    PMO
    Enterprise
    Architecture
    &
    Epics
    Agile Enterprise
  • 93. Team
    PO Team
    PMO
    Enterprise
    Architecture
    &
    Epics
    Solutions
    Architecture
    &
    Features
    Agile Enterprise
  • 94. Team
    PO Team
    PMO
    Enterprise
    Architecture
    &
    Epics
    Solutions
    Architecture
    &
    Features
    Detailed
    Design
    &
    Stories
    Agile Enterprise
  • 95. Guidance
    Team
    PO Team
    PMO
    Agile Enterprise
  • 96. Feedback
    Team
    PO Team
    PMO
    Agile Enterprise
  • 97. Not the entire business
    Product
    Delivery
    Agile Enterprise
  • 98. Product
    Delivery
    Strategy
    Agile Enterprise
  • 99. Support
    Product
    Delivery
    Strategy
    Agile Enterprise
  • 100. Establish direction… give feedback
  • 101. Establish direction… give feedback
    Business is made up of capabilities
  • 102. Establish direction… give feedback
    Business is made up of capabilities
    The goal is greater profitability
  • 103. Establish direction… give feedback
    Business is made up of capabilities
    The goal is greater profitability
    Focus improvements on constraints
  • 104. Capability Modeling
  • 105. Teams
    Capability Modeling
  • 106. Teams
    Identify
    Capability Modeling
  • 107. Teams
    Define
    Identify
    Capability Modeling
  • 108. Teams
    Define
    Assign
    Identify
    Capability Modeling
  • 109. Teams
    Define
    Optimize
    Assign
    Identify
    Capability Modeling
  • 110. Thoughts?
  • 111. mike cottmeyervice-president, pillar technology semcottmeyer@pillartechnology.com404.312.1471www.pillartechnology.comwww.leadingagile.com
  • 112. Adopting Agile in the Enterprise
    Presented by: Mike Cottmeyer