Agile Chronicles

Is your Organization out of Alignment?

Today is a good day. We got the kids up early... went out for a big country breakfast at Papa Jack's... and then drove up to South Carolina to pick up a mess of really awesome fireworks. You can't get really good fireworks here in Georgia... and since the South Carolina border is only about 90 miles North of Atlanta... we decided to make a trip. We've got about 20 lbs. of ribs basting in the oven... which should be ready in about an hour... so needless to say... but I'll say it again... it is a good day.

While we were driving this morning I got to thinking about my post from yesterday and why people fail to adopt agile in a meaningful way. We were talking about how often people fail to consider the human side of change. We tend to think in terms of process and practices... we don't think as much about the fears that are holding people back and preventing them from letting go. That said... and this was what was nagging me a bit... it's not fair to imply that fear, uncertainty and doubt are the ONLY reasons we struggle to adopt agile... often there are other factors at play

Our Trip to Disney World and Mike's Back Problem

I want to tell you guys a little story.

Up until last year... we used to take the kids to Disney World every October. Disney is great family fun and I highly recommend it. The only reason we didn't go last year was that the kids were getting older and decided they wanted to try something new. Last year we went on a cruise to Mexico.... but I digress. Back tot the point... the last time we went to Disney for vacation... I threw my back out the day before we left. I had never experienced anything like it. I've always been pretty healthy and have never had a back problem. I didn't know what to do and it sucked... sucked bad!

My kids we ready to go to Disney... my wife was ready to go to Disney... so we went to Disney. I spent the first two days walking the park... riding rides... and trying my best to have fun... but in reality I was pretty miserable. It's kind of funny... when I look back at the pictures from those two days... I had a smile on my face... but I can see the pain coming through the smile. Back problems are no fun at all.

The morning of day three I finally had enough. We were at Disney's Animal Kingdom and my wife looked over at me and told me I had to go to a doctor. Not knowing what the heck a doctor was going to do to get me through my vacation... short of prescribing some pain killers which I did not want.. I decided to go to a chiropractor. To that point in my life I had never been to a chiropractor and I wasn't sure what to expect...

Long story short... the chiropractor told me that my spine and pelvis were not where they were supposed to be and it was putting pressure on a nerve in my lower back. He did a minor adjustment and I was functional and relatively pain free the rest of the week. Good news is that I haven't had a problem since... the chiropractor found and fixed the root cause... I was out of alignment.

I had the desire to go to Disney... I had a great attitude... I tried to keep a smile on my face... I wasn't afraid to ride the roller coasters... the problem was it just hurt. My body was not in proper alignment to take advantage of all the fun that Disney had to offer. A bunch of the companies I work with are kind of the same way. They want to do agile... they want the business benefit... they want to change... its just that their organizational structure is not in proper alignment to get the full benefits. It's like being at Disney with a back problem.

How do organizations get out of alignment?

Our organizational hierarchies provide the basic infrastructure in which we operate... in which we run our business... that is our foundation. On that foundation we have many forces that pull that structure in lots of different directions.

We have projects run by project managers with schedules, budget constraints, and performance objectives. We have managers that manage teams of specialists... the managers are incented to optimize individual performance and get maximum productivity from each team member. We have products that have their own set of managers... each responsible for managing their markets and trying to get as many revenue generating features in their products as possible.

We spin up teams to do projects... so we have a project team view. We have to mange the component architecture outside the context of any single project... so we have an archtiectural view. Projects might also be part of a program or a portfolio, team members are matrixed across multiple projects, products, and architectural sub-components... all of which put different pressures on the enterprise. Its amazing to me sometimes that we manage to get anything done.

Steven Covey in his book The 8th Habit talks about how so few people in a company feel they understand the objectives of the organization... that that they are working on the most important stuff... or that they are pulling in the same direction as their co-workers. Covey compares this to a soccer team where:

• 4 of the 11 players on the field would know which goal is theirs
• Only two of the 11 would care
• Only two of the 11 would know what position they play and know exactly what they are supposed to do
• 9 players are competing against their own team

Getting on the Same Page

So... while the people issues are really, really important... it is also important that the organization get in alignment if we are going to make a serious go at widespread agile adoption. That means putting some thought into how we create teams... what we have them work on... how we measure their performance... and how we have them work together. Its a matter o aligning the structures of our organization and then aligning team to support those structures. That is fundamentally what will make an agile organzation work.

Like most things... that kind of change doesn't happen overnight... but realizing this is a problem is more than half the battle.

Why are you Failing with Agile?

Okay... you're a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs... check... got team members trained... check... identified a pilot project... check... hired an agile coach... check. Why then... after all this time, effort, and money... are we still struggling with the fundamentals? Why can't we seem to get over the hump?

It seems that there is always someone... sometimes there are a lot of someones... that just don't seem to get it. They just can't let go of their trusted MRD... they can't seem to get past the idea that agile teams don't do Gantt charts. These folks want to know exactly when their project is going to be done... what it is going to cost... and what they are going to get for their money.

How do we respond to these people? Hey... agile can't be any worse that what we are doing now? Agile is all about trust... you just need to trust that this new way of doing things is better. Just give us a few sprints and we'll prove to you that this new way works. I promise, you'll like it.

Put yourself in that other person's shoes for a moment... your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK...not to mention the bonus he got for becoming a PMP in the first place.

These folks know something is broken... they know that we are making product development too hard...that is whey they let the team give this agile stuff a try in the first place. The problem is that... at the end of day... these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.

It's important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families... they have kids in college... they have financial obligations. You are not just asking them to change... you are asking them to put their livelihood at risk. People don't resist change because they are bad people or because they just don't get it. Chances are... at some level... they are afraid.

More than likely... there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful... and work to satisfy that need... on their terms... they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose... you'd probably do the same thing.

Trust me doesn't cut it until you have earned that trust. Agile will help you get there... but you know what... you might have to let them have their Gantt chart... you might have to let them have their MRD... until you can make it safe for them to let it go.

Yes... Agile Isn't Project Management...

...but it sure will change how you do project management.

I've got this talk called the Agile PMP: Teaching an Old Dog New Tricks. The first time I delivered the talk was last year at the Agile Development Practices conference in Orlando. So far this year I've done the talk for a few local groups here in Atlanta and then out in Vegas at the Better Software Conference and Expo. Later this year I'll deliver the talk at Agile 2009 in Chicago, the PMI Global Congress in Orlando, and the Agile Development Practices Conference... also in Orlando.

I've been pretty pleased with how well the talk has been received by conference selection committees and by the attendance at the shows. The talk works because it helps people understand Agile in the context of what they already know. We talk a bit about what is the same... and we use that commonality to explore what is different. At the end of the day... regardless of whether we choose to a traditional approach or an agile approach... we still have to deal with the fundamentals of project management.

Agile projects have to have a way of dealing with the triple constraints... there has to be some concept of time... some concept of cost... and some concept of scope. We have to manage risk... decide how we are going to communicate... and how we are going manage quality. How we go about doing these things on an Agile project might be different, but we need to have a shared understanding of how all this stuff is going to be accomplished. By helping folks understand Agile in the context of the PMI process groups and knowledge areas... we provide a solid baseline of understanding.

My core message centers around the triple constraints and our typical assumptions about uncertainty. Most traditionally managed software projects begin by defining what we are going to build... by defining scope. Once we know what we want to build... then we'll assess the requirements to see how much it is going to cost and how long it is going to take. There is always some acknowledgement of time and cost constraints up front... and there is negotiation with the stakeholders to get the three variables to converge... but starting with scope causes many software projects to start slow and finish even slower.

The problem happens when we go off and decide what we want to build without any idea of what it is going to take to build it. We create a wish list of things we'd like to have in the release and product managers get married to the ideas early on. It becomes tough to see how we can deliver value to market without everything we have spent all this time and energy to specify for the development team. I have worked on projects that needed to be delivered in six months and the product team created over five years worth of requirements.

When you push back... the discussion usually goes something like... well just do the estimate and tell us how much we can get. The problem is that it takes time to learn enough about the set of possible solutions to actually do an estimate... there might be technical dependencies... there are clearly resource dependencies... so evaluating a multi-year project to determine what can be delivered in the next six months can be a huge waste of time and resources. This problem is further compounded by changing market needs and the fact that software has a tendency to evolve... a lot... as it is actually built.

We create a false sense of certainty about what it is we are going to build and when we can get it done. Once time and cost commitments are made... being married to a fixed set of requirements is going to get in trouble. There has to be some room to negotiate as we go.

While Agile is not a project management methodology... it does impact how we do project management... mainly because Agile is going to have us make a different set of assumptions about our project constraints. Now... just like anything... these new assumptions and constraints need to be validated in your specific environment... but in general... on Agile projects we are going to decide that scope is not the primary driver. Rather than starting with scope... we are going to start with time and cost. We decide first when we need to go to market and how much we are willing to spend to get a product out the door.

Rather than create a giant wish list of features... we are going to start defining features to fill the time and money allotted. When we have filled up the time... and planned to spend all the money... we have to decide if we have a release that could be taken to market. There is a very subtle difference at play. There is still negotiation... still an assessment of the viability of the release... its just that we don't spend time assessing features that have no chance in hell of actually getting implemented.

In effect, we are talking about what agilists call product planning and release planning. We create a product plan... a roadmap... that gives us some confidence around what the customer is going to get... when they are going to get it... and what it will cost. The main difference is that we are starting with time and cost and figuring out what we are going to build within those pre-defined constraints.

Just because we started with time and cost... that does not mean that we can fix scope... we need some room due to our new assumptions about the certainty of our estimates and the stability of our requirements. Again... we are going to start with the notion that time and cost are our primary constraints and that we'll want to fine tune the scope as we go to deliver the greatest business benefit possible. Because we deliver working code on short cycles... and we have empirical evidence of our progress... we can constantly evaluate how we are doing against where we hoped to be. The project stakeholders have the ability to control the project... either by adjusting scope... or by adjusting the time and cost constraints... in real time as the project is progressing.

If at any time we learn that the business objectives and ROI targets cannot be met... we have the opportunity to kill the project... or radically alter its course... having invested as little as possible to make that decision. We are using the real data... being generated by real teams... writing real software... to provide feedback into the higher level roadmap. It really does put the business back in the driver seat. This idea that we are just going to start building software and let the backlog emerge.. the architecture emerge... and product emerge isn't workable in most contexts.

With all the talk of late regarding Kanban and single piece flow... I wonder if we will lose the ability to make any kind of commitment back to the business. I think that in some contexts... this is probably appropriate. In many though... we will still need to have the concept of roadmaps... vision... release plans... and product backlogs. I don't see these things as waste... but more as an acceptable level of overhead to give the business some idea of what they are going to get... when they are going to get it... and what it will cost when we get there.

So... again... we find that Agile is not a one size fits all strategy. We have to use our brain... we have to use ALL the tools and practices and principles we have at our disposal... we have to come up with the best approach to deliver the project given the constraints the business has imposed. At the end of the day... we are still doing project management... its just that agile changes the game a bit and introduces a new set of tools... and a new set of assumptions... and a new set of constraints which we'll use to deliver projects in more uncertain environments.

June Is For Commitment!

I, Project Manager, take you, Agile Methods, to be my wife.
I promise to be true to you in good times and in bad, in sickness and in health. I will love you and honor you all the days of my life.

I, Agile Method, take you, Project Manager, to be my ScrumMaster. I promise to be true to you in good times and in bad, in sickness and in health. I will love you and honor you all the days of my life.

Now on the surface this may sound ridiculous, but the real question seems to be who are we married to and why? What is the level of our commitment to success? What do we vow to do and what expectations do we have of others in the relationship? How serious are we about the projects we engage and how we leverage our teams?

Is this a marriage with a happy ending or is it destined to end in divorce? (We all saw what happened to Jon & Kate). Just as any good psychologist or Marriage Counselor would ask, what are you doing to enhance the level of communication in your relationship? What are you doing to make the relationship work better on a whole? What steps have you taken to work better together as a team towards a common goal? Have you set both short and long term goals for your relationship? Have you set and agreed to accept ground rules?

Is this an eternal commitment or is it until death do us part? Where do you expect this relationship to go and by what metrics do you measure success? The good news is that Agile Methods are for the most part very attractive spouses! They tend to help you increase your visibility and productivity.

With Agile Roots just completing and Agile 2009 just around the corner, I think it may be a good time to re-evaluate our relationships and make choices that support a healthy relationship. Even if that means revisiting the things in the beginning that drew us together as a pair. As people make more and more vows in the month of June, may we take a moment in retrospect to look at our own commitments and at what level we are working to exceed our partners expectations!

VersionOne Agile Project Management and Agile Best Practices Webinars

Think of this post as a quick public service announcement for all you folks out there looking to comp some free Agile training ;-)

Over the next month or so... VersionOne is hosting a series of free webinars on Agile Project Management and Agile Best Practices. These talks are done by several of the leading thinkers in the agile community and... given that they are free... and during lunch... there is no reason not to attend ;-) The following is a quick summary what's coming up. You can visit the VersionOneResources page to get more information, to see archived talks, and to register.

June 24th we have Pete Behrens from Trail Ridge Consulting doing a talk on Agile Program Management and Scaling Agile Projects.

Agile Project Management has driven successful results throughout thousands of projects across the globe through various frameworks like Scrum, Extreme Programming and others. Agile development, quality and project-level practices are allowing teams to react more quickly to changing market and business conditions, meeting customer needs more directly, and driving profits or cost savings sooner. Most organizations are experimenting with agile approaches on one or more projects within their portfolio.

The challenge, however, remains in the coordination across larger organizations aligning many projects, products and teams to deliver complex interdependent programs successfully. This presentation shares Agile Program Management Best Practices to guide project and program managers in larger organizations working across these boundaries to deliver complex programs. These best practices have been leveraged by programs with over 30 teams with hundreds of people (Larger programs are divided into subprograms and replicate similar practices). This presentation addresses best practices for program setup, goals, and investment; organizational team structures and work breakdown; and program coordination, tracking, dependencies, risk, and release predictability.

July 1st, we have David Hussman doing his talk on Pragmatic Personas.

Personas have that stickiness that sticks. With a pragmatic focus, this session covers simple and powerful techniques for crafting personas and using them to drive value into your development stream. The session will start with an overview of what personas are and how they provide value. We will create personas and discuss possible sources of information and potential authors. Once we have created a few personas, we will explore how they can be used to craft stories, create acceptance tests and help keep the user’s experience in the minds of the development community.

July 22nd we have Sanjiv Augustine doing his talk on the Agile PMO: From Process Police to Adaptive Governance.

How should we scale Agile methods beyond individual projects? How can PMOs avoid being process police and instead truly support Scrum teams, enable enterprise rollout of Agile methods, and sustain long-term Scrum adoption?

Learn how industry leaders are scaling Agile with Agile PMOs that:

• Support and empower agile teams through training, coaching, and organizational obstacle removal
• Track project portfolios using Agile tracking techniques
• Bring lean discipline to project prioritization
• Move towards a stable teams model of resource management

Sanjiv will share principles and techniques for an Agile PMO, and discuss how those concepts are being applied in the industry to scale Scrum through adaptive governance of programs and portfolios.

July 29th we have Michele Sliger doing her talk on Beginning with Values.

Agile adoptions can only be successful if corporate values match the values outlined in the Agile Manifesto and in agile frameworks such as XP and Scrum. In this presentation, Michele Sliger discusses the importance of values and the role they play in driving behavior. You'll understand the real meaning behind the often heard "agile is value-driven, not plan-driven" phrase. You’ll find out how to determine what your company values, and how to compare that to agile values and what to do if they are different. Most importantly, learn how to apply what you’ve learned in your own situation. See how to define values at the team level, a must in order to ensure effective working relationships and that the right actions are taken by everyone to achieve iteration goals. You’ll learn visioning exercises that you can conduct with your team, and on your own - so you can better understand what you personally value and what you plan to do about it.

All of these folks are among the best at what they do and all are excellent presenters... you won't want to miss these talks.

Catching Back Up...

I can't believe it has been over two weeks since I did my last blog post. Longer than that if you are an Agile Chronicles reader. The past few weeks have been a bit nuts.

As you guys know... the week before last I was in Vegas to do my Agile PMP talk. The talk went well but it is always entertaining to see how the dynamic in the room changes depending on who decides to speak up. I need to get better at avoiding language that can set people off ;-) Anyway... every time I get to deliver this presentation in front of people it helps sharpen the message.

The Agile PMP talk just got picked up by the PMI Global Congress in October... so I better get better fast. I am not expecting that crowd to show any mercy!

Last week I was with my two older boys at Rainey Mountain Scout Camp. Camp sure has changed since I was a kid. I didn't have a cell signal the whole week but there were several wifi hotspots around so I was not without some connectivity. After getting the troop off to classes... I spent each morning online and then each afternoon hiking in the North Georgia mountains. I would rather sleep in a tent than a swanky hotel... so life was good.

Before I left... we talked a bit about how it is so easy to get focused on how we are getting work done and to lose focus on what we are actually delivering. That problem has to be pretty universal... it applies to software teams and complex organizations... it also applies to scout troops. Are we here to build committees and sign paperwork or to help boys become young men? When we starting focusing on how things are going to get done... it is easy to lose focus on what is really important. But... I digress.

Some of my writing focus lately has been directed in places other than this blog:

Next month I am publishing my first executive report for the Cutter Consortium. I did the report with my good friend Dennis Stevens. Dennis is a really smart guy and we pushed each other on the ideas in this paper. The report is only available to Cutter Consortium subscribers but maybe we'll have a raffle here on Agile Chronicles to give out a hard copy.

I've also done a short whitepaper for VersionOne on the role of the Agile Project Manager. It is an introductory piece but you guys might want to check it out. The paper talks not so much about Agile Project Management... but more about the new skills a Project Manager needs in an agile environment and how they need to think about their role a little differently. This paper can he downloaded for the low, low cost of giving the VersionOne sales team your contact information.

Lastly, keep your eyes peeled for a screen cast I put together on agile adoption. Naming talks is not really my strong suite. The screen cast is on adopting agile... but more fundamentally it is about teams... and how to build organizations around teams... and how to decide what teams work on... and how to throttle work through the organization in a way that creates flow. So while this is an agile talk... it also hits on things like capability analyis and lean scheduling in the enterprise.

I'll shoot a link once we have the presentation up an publicly available. Hopefully, I'll get back in the groove of writing this week... still have lot's to say ;-)

What Do You Value?

Sometime I think we are missing the point.

I am becoming more and more convinced that building organizations around teams is the real secret to building agile organizations. How we setup our teams, what we have them work on, and how they work together with other teams... all determine how well value will be created for our business and ultimately our customers.

Some things are really important about teams... and some things just aren't. Getting straight about what we are are actually trying to accomplish with our teams will help us get past some of the dogma, methodology battles, and Scrumdamentalism that is preventing us from incrementally adopting agile practices. Is our goal to adopt Scrum or is our goal greater business agility?

Important Stuff about Teams...

Teams Deliver Value

Sometimes this means that teams work on cross functional threads of working software. Sometimes it means that teams deliver services that will be consumed by another part of the organization. Teams might be part of the business and handle billing... or marketing... or sales. I only care about teams being cross functional in the sense that the team needs to have what it need to deliver the value is was created to deliver.

Teams are Accountable

Teams make and meet commitments and are responsible for delivering on those commitments. They are accountable for outcomes. I don't care so much how they deliver those outcomes... assuming that they operate within moral and ethical boundaries... I care that teams do what they say they are going to do and deliver the outcomes that they promise to the business

Teams are Predictable

Over time, the business should be able to provide specific inputs and get reasonably predictable outputs. Throughput should trend up... and we should know why it is trending up. If throughput is trending down... we should be able to assess and understand why it is trending down. If throughput is variable... it should at least have a reasonably predictable rolling average. If teams aren't predictable... we can't plan anything.

Teams get Better

We need to have some mechanism in place for getting better over time. This could be a sprint retrospective... or it might be a Kanban board. We can rely on the knowledge and creativity of the team to improve... or managers can use specific tools that help make problems visible and help the correct the problems. It cannot be okay to accept mediocrity.

Teams are Transparent

The business needs to be able to understand exactly what the team is working on and how the deliverables relate to the objectives of the business. The business needs to understand what problems the team is having so that they can help get them resolved. Team performance metrics need to be visible and explainable

Not so Important Stuff about Teams...

Teams have Product Owners

I am probably going to get myself in trouble here... but I don't think that the Product Owner is all that important. It is important to have a well groomed product backlog. It is important to have someone to answer questions for the team on behalf of the business or the customers. It is important that the business is accountable for making decisions in a timely manner and giving guidance to the team.

If that can be done by a single person called a Product Owner... so be it. All I know is that it needs to happen.

Teams have ScrumMasters

Again... going to get in trouble. What I really need is someone to help the team stay on track... to maintain the vision... to help remove impediments... and to collaborate with the team to help them improve. If this is a ScrumMaster, great. It might be a resource manager that fills this role... it might be a project manager. It might be a good dev lead or a product architect.

Teams do Daily Standup Meetings

What I really need is communication between team members. I have worked with teams that all sat in the same space... worked together daily... and always knew what was going on. If a daily standup meeting adds value... do it. Just remember why you are doing it and if you are getting the outcome that you need. Communication... transparency... shared accountability... those are the important things.

Teams have Planning Rituals

The team needs time to plan. They need time to get their head around the problem is coordinate the work. They need a time to inspect and adapt. This might need to be a sprint planning meeting and a sprint review. It might be done ad-hoc as a requirement is moved from the backlog into the in process queue.

Do We Care About What or How?

When folks are just getting started with Agile... it is easy to get caught up in the how. How are we going to plan... how are we going to meet... how are we going to review outcomes... how are we going to ensure accountability. I need to focus on what the team is going to deliver and the attributes of that delivery that are important to the business.

It is extremely important that a team delivers something of value on short cycles... that they are accountable... that they value predictability... that they get better over time... and that they are transparent to the business. To the extent that Product Owners, ScrumMasters, daily stand-up meetings, and planning meetings help me get there... they are useful tools might get included.

These things could be out of sync with your organization and actually impede your ability to adopt agile. You might need to think about what you're really trying to accomplish and come up with some situationally specific strategy to build teams... and get teams predictable.

It might be unreasonable to ask the business to take a Product Manager and turn them into a Product Owner. It should be perfectly reasonable to ask them to make sure teams have the requirements they need to build software... requirements that accommodate change... help mitigate risk... and deliver value better and faster back to the business

So my question... are you more concerned about adopting specific agile practices or doing what it takes to build well functioning teams?

The Agile PMP Presentation

Okay... while I am publishing presentations today, here is the one that I am doing next week at the SQE Better software conference in Vegas. I'm also doing this talk at Agile 2009 and again at the SQE Agile Development Practices Conference in Orlando. It's nice to have a presentation that I get to do live more than once... I finally feel like I am getting good a delivering it ;-)

The Agile PMP v2

View more OpenOffice presentations from Mike Cottmeyer.

Adopting Agile Presentation

Last night I had a great opportunity to deliver this slide deck to the Turner Agile User Group here in Atlanta. The talk was on Adopting Agile in the Enterprise. I am still working on the overall message and consider the presentation in beta. This will end up being the deck that I do for the Oredev conference in Malmo later this year.

Adopting Agile

View more OpenOffice presentations from Mike Cottmeyer.

Oredev 2009 Malmo Sweden

I got an interesting invitation to head to Malmo, Sweden this year for the Oredev 2009 conference. I'll be doing two talks in the agile track... one on scaling agile and the other an experience report based on the coaching gig I did earlier this year. Regular readers will recognize some of the topics I plan to speak about.

The Manager’s Guide to Agile Adoption

Agile methodologies are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are exploring the possibility of implementing these methodologies across the entire product delivery organization. These managers launch their adoption efforts only to uncover many common myths, misperceptions, and obstacles that derail their efforts before they really get started.

Organizations fail to become agile because they don’t understand what makes agile teams work. Breaking past traditional organizational constraints, even the constraints imposed by some of the better known agile methodologies, will free managers to create situationally specific strategies that support the formation of teams and enable them to deliver both reliably and consistently back to the business. Agile teams become the building blocks of agile organizations.

This talk will explore a roadmap for agile adoption that begins with teams and demonstrates how teams work together to deliver more complex projects and portfolios. Mike will expand the team concept to include capabilities and show how capabilities can be organized to optimize value across the enterprise value stream. At each step of the adoption process, Mike will demonstrate how to choose the policies, practices, and metrics that create learning and drive sustainable organizational change.

Agile Adoption past the Team – An Experience Report

Discussions of agile often assume that there is a single team, assigned to a single product, with a single dedicated customer guiding all the product decisions. In reality, many organizations are building complex products that require the efforts of more than one development team. When teams have to coordinate to deliver a highly integrated product, the product owner’s job often becomes too big for a single person.

Not all the interesting scalability problems are reserved for the enterprise. Product Owners have challenges when trying to coordinate the deliverables for only four or five dependent development teams. Quite a few organizations are expanding the role of Product Owner to include Product Owner Teams and Product Owner Teams with Architects. These teams work in partnership with the Product Owner to maintain the product backlog and drive integrated decision making.

This talk explores a 3 month coaching engagement where the customer needed to coordinate requirements and design across five highly dependent development teams. Mike will show how the teams went from zero to hyper-productivity in a matter of sprints by implementing solid engineering practices and deploying a Product Owner team to coordinate deliverables across the entire product delivery organization.

Speaker Bio

Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining VersionOne, Mike was a senior project manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has 20 years of experience leading IT initiatives using a combination of traditional, agile, and lean project management best practices.

Mike is a certified PMP Project Manager and a certified ScrumMaster. He co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. Mike is an honorary member of the DSDM Consortium and a founder of the Lean Software and Systems Consortium. Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including http://www.leadingagile.com and http://blog.versionone.net and occasionally for http://www.agilesoftwaredevelopment.com.