Are you registered for the Agile Coaches Camp this month in Durham, NC? If not, you should. I'll admit... I was a bit skeptical about the first Agile Coach Camp in Ann Arbor. The guys at VersionOne asked me if I wanted to go. I was like... fly to Michigan... on a weekend... with no agenda... no speakers... we all just get together and figure it out? Sounded like a train wreck to me, but for some reason, I went anyway.

Needless to say, I had never been to an Open Space conference...

I learned that there is something very powerful about being a room full of passionate people that are trying to make the world of software development a better place. It was a pretty amazing experience... some of the closest relationships I have in the agile community were formed at the last Agile Coach Camp. Nothing like a couple of late nights, talking about agile stuff while smoking cigars and drinking martini's, to bond a group of strangers together!
Head over the the AgileCoachCamp Wiki for more information about the camp and links to register. I have no doubt this camp will be as powerful as the last one. Seriously... you gotta be there... I'll be there... go... register now!

Yesterday, I did my first live presentation of a new talk I'm calling "Getting Started with Agile". A better title for the talk might have been "How to Select an Agile Pilot Team in a Large Company, Get Them What They Need to be Successful, and Help Them Build Trust With the Rest of the Organization", but that just didn't seem to flow quite as well ;-) Now that it has been vetted live, and I'm pretty sure it solves a real problem... I want to spend some time talking through the content with you guys here... and give you a chance to weigh in.

If you are new to this blog, and for some reason haven't been able to get through my earlier 270 or so posts... you might not be as familiar with my background. I've got a degree in Computer Science from the University of Florida but somehow never managed to become a professional programmer. I spent the first ten years of my career as a data center guy working with network and server hardware. The second ten years of my career I've been, in some form or fashion, a project manager. Most everything I have ever worked on has been big and uncertain and with teams of people that were figuring out stuff as we went.

We were doing iteration planning, daily stand-ups, story points, and retrospectives back in 2001 before I ever knew there was a movement forming called Agile. These things were the stuff I just figured out to cope managing projects in the face of brutal uncertainty. I have a huge aversion to wasting time and doing stuff that doesn't make sense, and I sure as hell wasn't going to spend my time doing Gantt charts that everyone knew were fiction. I opted to lead my projects rather than spend all my time keeping project plans up to date. My approach wasn't always popular, but we delivered some really kick-ass projects.

Because so much of my career has been spent challenging conventional thinking, I've developed a passion for helping folks understand how to use non-traditional ways of managing work. I want to help people to understand context, and apply what they know in ways that make sense. That is the backdrop for most of my writing... let's take what we know... let's understand where we are... let's figure out what we need to deliver... and let's make good decisions about how to most effectively manage the work. We are not living in a one size fits all world. We can't take a one size fits all approach to solving problems.

So, that is kinda where this talk started. When VersionOne asked me to kick-off their webinar series, I thought I would use one of my existing talks on scaling agile... maybe something on enterprise value, or the role of the product owner. They actually wanted something that was more introductory... something for people just getting started. There is a ton of stuff out there that explains the basics of Scrum and XP... and I knew I didn't want to do an intro to Scrum talk. The other thing was, that while most people seem interested in Agile... they have a hard time going back and applying these concepts in more traditional organizations.

This talk was designed from the ground up as less of an 'intro to agile' talk... and more of a 'okay you are sold on agile... now let's really figure out how to get started' talk. Getting started doesn't start with your first release planning meeting... it starts with spinning up your first team. It starts with choosing an agile pilot team and putting them in the best possible position to be successful. It's about understanding how to get them everything they need to deliver working software. How to get them tied to a real enterprise level problem, something the business really needs to have solved, and help them knock it out of the park? It's about helping the team be successful... but also making sure the larger organization is successful too.

This talk is broken down into four main sections:

1. Understanding what your organization values and spinning up an agile pilot team to unlock that value
2. Understanding the anatomy of an agile team and getting them what they need to be successful
3. Establishing a delivery cadence and building trust and safety with everyone else in the organization
4. Understanding common challenges and facilitation tools for taking the first step toward agility

Over my next few posts, we'll break these four sections down and talk through each in more detail. Looking forward to your comments.

A few weeks ago, I put together a custom two-day course on Agile and Agile Project Management. I was so pleased with how it turned it out, I've decided to offer it publicly here in Atlanta. The course uses real life examples and project simulations so folks leave with some really solid anchor points and confidence that they can go back to their companies and actually do this stuff.
Since this is my first public course, I am practically giving the training away. Super early bird is $295 for both days, early bird is $395, and full price is $495. If you ask, I might even send you an additional 20% off for being a reader Leading Agile ;-) It is a great course and I think you'll get a lot out of it. Hope to see you there!
Register for Agile: Beyond the Basics
Course Overview:
Agile is not a one size fits all methodology... your Agile training shouldn't take a one size fits all approach! This course is designed to create an emergent experience based on the unique needs of each individual class. We use the same planning techniques to run the class that you will learn while in the class. Be prepared to fully immerse yourself in learning the fundamentals of agile project management and leadership, by participating in a class that is structured to run just like a real agile project.

Who Should Attend?

• Managers and Project Managers that will be actively running agile projects
• Team Members that need to know how to deliver working software on an agile project
• Senior Leaders that want a hands on experience working in an agile environment

What You Will Learn?

Here is our preliminary backlog, but like we said, be prepared to inspect and adapt and change as we go!

Day One

• Background and history of Agile methodologies
• The importance of collaboration (exercise)
• Overview of agile principles, values, and practices
• The basic mechanics of Agile
• The importance of flow (exercise)
• The cultural impact of Agile
• User stories, estimation, and release planning

Day Two

• Learn how to run an effective sprint/iteration planning meeting
• Learn how to run an effective daily stand-up meeting
• Learn how to run an effective sprint/iteration retrospective
• Understanding Scrum Roles: ScrumMaster, Product Owner, and Team
• Servant leadership (exercise)
• The role of traditional managers
• Common impediments to adopting agile
• Advanced topics as defined by the class

I kicked off the 2010 VersionOne webinar series today with a talk called 'How to Get Started with Agile'. The idea was to do an 'intro to agile' talk focused on how to select a good pilot project, how to get the team started on the right foot, and how to bridge the team to the rest of the organization. I think it's time we start giving teams some tips for surviving and thriving in non-agile organizations. Take a look at the deck and let me know what you think!
Getting Started With Agile
View more presentations from Mike Cottmeyer.

Hey everyone! I just submitted three session to the Agile2010 submission system. If you have a minute, please head over and give me some feedback. Submissions close this Friday, February 26th... not sure how long sessions will be open for input. I'd love to hear what you guys have to say while I can possibly change something. Sorry for the fire drill... been slammed ;-)

How to Own a Really Big Complex Product

Product Owner is the most misunderstood and misapplied role in Scrum. The concept barely works on small products… it almost always fails in larger enterprises where many teams work together on complex enterprise deliverables. We hear about people implementing product councils and product owner teams but that seems to miss the point of having single wring-able neck. This talk explores the role of Product Owner and breaks down just what it takes to do this role well. We’ll explore a capability driven model for scaling the PO role and keeping us all focused on building the right products.

• What does it mean to be a PO in Scrum?
• Why the PO role is often too big for one person?
• What happens when the PO tanks the project?
• Scaling the PO using a capabilities based approach

http://agile2010.agilealliance.org/node/6014

Value over Velocity... What To Do When Velocity Isn't Driving Business Outcomes

Having a stable team velocity is critical to delivering a well run and predictable agile project. When organizations begin comparing velocity between teams, or trying to roll-up velocity across teams, many find that team level performance doesn’t necessarily provide an accurate picture of project or portfolio level performance. This talk explores where velocity works, and where velocity fails, and outlines several approaches for tracking project and portfolio performance in more complex software development organizations.

• Understand where velocity works and where it doesn’t… and why!
• Discover how the relationship between velocity and value breaks down on larger corporate initiatives
• Learn a lean portfolio management approach that ensures we are driving value creation on more complex projects and products.
• Learn how to restructure your agile portfolio to focus on your highest priority business outcomes

http://agile2010.agilealliance.org/node/6012

How To Get Started With Agile

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.

• Learn how to form agile teams around clearly defined business benefit and constrained value.
• Discover how to set teams up for success by giving them what they need to be successful
• Build trust with your organization by managing commitments and delivering on regular intervals
• Overcoming organizational impediments and building on your success

http://agile2010.agilealliance.org/node/6010

Thanks for your help! Looking forward to hearing what you have to say!

Tomorrow (Wednesday, February 24, 2010) I am doing a webinar in partnership with VersionOne titled 'Getting Started with Agile'. The talk is going to go beyond some of the basics of spinning up agile teams, and focus more around how to choose a pilot project... and how agile teams can co-exist within a more traditional organization.
I'm thinking of this talk as almost a prequel to some of the presentations I've done recently on agile transitions and scaling agile to the enterprise. If you are thinking about pulling together a team to give agile a try, check out my webinar. You'll leave with some practical advice that will help make sure your first step toward agility is a successful first step.
Head here to register for the event. We are getting started at 12:00 PM ET.

Cory Foy does a great job giving us some insight into the recent history of the Scrum Alliance, especially as it relates to current efforts around developer certification. He also does a great job getting to the nut of the issue we are talking about here, something I am clearly struggling with. Cory's point? The Scrum community is fractured and trying to get some stuff figured out. Personally, I think that's a fair assessment.

Cory also wants us to acknowledge that most Scrum practitioners are in the software development space. He wants us to stop trying to be all things to all people. He wants us to get down down to the business of building software... the best we know how. I support that direction 100%, and in that context, totally support defining a set of developer practices that are a good idea on most projects, most of the time. I might even support a certification.

So why does all this matter? Here I am going to quote Lee Henson quoting the most recent series of Spider Man movies... "with great power comes great responsibility." Like it or not, most people equate Agile with Scrum. Many people, especially the new ones, don't realize that Scrum certification is only a two-day course. Lot's of people think that when you call yourself a master of something, you have some idea of what you are doing.

Scrum's positon as the preeminent Agile methodology... or framework... or whatever you want to call it, puts it in the position to have precious little time to dork around. I think that if the Scrum community doesn't get things figured out... and soon... we are going to see other groups rise and take Scrum's preeminent role. How many of you guys stopped watching baseball after that strike a few years ago? I did.

We don't have time for in-fighting... we have companies to run and software to build.

I have to say, I've been a little surprised by some of the responses to my last post on Scrum Certification. For the record, I'd like to restate my position as simply and with as few words as I possibly can:

1. Scrum is a simple framework for empirical process control. That is why it is so effective.

2. Scrum does not tell us how to write code or how to be good product owners. It is up to us to bring our knowledge and experience in ways that are unique to our context.

3. I do not believe it is right to offer certification when there is not standard or a published set of competencies. We should not certify more than Scrum is willing to include in its body of knowledge.

I am all for holding classes that teach us how to be better developers and better product owners, and even better ScrumMasters. I do not believe this training should be called certification.

That is my point. If my point makes you angry, just remember... sacred cows make the best hamburgers!

Couple of things here. I have been involved with the Lean Software and Systems Consortium since it's inception last year in Miami. The Lean & Kanban Conference was excellent and this year's Lean Software & Systems Conference is looking to be another outstanding event. I can't even begin to list all of the speakers that have agreed to come and do talks.
I really believe that the LSSC is positioned to be a powerful voice of influence as Agile methods move even more into Mainstream Corporate America.
As practitioners and thought leaders, it's up to us to stay abreast of new developments and help lead our community forward . The Lean Software and Systems Conference is the most forward thinking conference we having going right now. If you want to learn more about where our community is headed... this is a great conference to attend.
Personally, I believe so strongly in the message of this group, my company Pillar Technology decided to put our money where our mouth and sponsor the event. That means I'll be there (I would have been there anyway) and I'd really like to see all you guys there too. It's only something like $995 to go... so no excuses, go ahead and register. Now!
From the LSSC website:
The Lean Software and Systems Conference 2010 is the premier international conference showcasing the Next Wave of Software Process. The conference looks forward to hosting 250 software process thought leaders immersed in the application of Lean concepts such as Kanban to deliver better economic outcomes for their organizations and better working conditions for their team members.

At the risk of being accused of bashing Scrum for the second time this week, I want to talk a little about the Product Owner role. What I want to explore a bit is why the Product Owner is such an important construct in Scrum... and furthermore, why it is difficult for so many organizations to really fill it well.

The Product Owner is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. The Product Owner gives the team unambiguous direction and ensures they don't have to worry about conflicting business priorities.

As a community, we seem to be backing away from the idea of a Product Owner as the single wringable neck... but that's really the whole point, isn't it? We need to have ONE person that is RESPONSIBLE for telling the team what to build. Without it, how are we sure we are building the right product? How do we know the person defining the backlog can singularly and authoritatively guide the output of the team?

In reality though, how often does one person really own a product? If there really is one person that owns the product, how often does that person have time to sit full time with the team? Is it realistic to ask the real Product Owner serve as Product Manager, Project Manager, and Analyst? Is it realistic we can have one person own the vision and guide the execution in any but the most trivial of organizations?

As Scrum goes more mainstream, there seems to be acknowledgement that most of the time, we have multiple people filling the role, most of whom are merely proxies for the real decision makers. If this has become the norm, if we don't have a single authoritative voice to guide the team, if we don't have a single person that decides what to build, what is the point of having a role called Product Owner anyway?

I wonder if most of us are even honoring the basic principles behind why the Product Owner role was created in the first place? Are we bending Scrum because the demands it places on us are just too great?

So again, I find myself asking questions like... if the PO doesn't really OWN the product, are we bending Scrum past it's acceptable limits? If we have several stakeholders in a PO team, are we doing Scrum-but? Do I REALLY have to empower a SINGLE person to be ACCOUNTABLE for telling the team what to build? If I don't am I really doing Scrum? Where are the limits? What defines acceptable adaptation?

So... I think what is nagging me here is a growing dissonance between what you might call textbook Scrum, and Scrum as practiced in most organizations, by most people I talk with. I don't want to bash Scrum, I want to reconcile how we teach it, how we certify it, with how it is generally practiced. And by all means, if we are going to certify these adaptations, I'd like to see us start including them in our body of knowledge, however lightweight or informal.

We got some snow in Atlanta yesterday. It's not very often that we have 4 inches of snow on the ground. I had my kids all convinced to go backpacking with me this weekend, but the cold temperatures and damp conditions scared them off. I guess the 10 degree down bags they got for Christmas didn't make them feel any better about putting in some miles and sleeping outside. So anyway... in the absence of backpacking, decided to do a little writing today. Hope you enjoy this week's installment of 'Interesting Post...'.

Poppendiecks, in Glasgow, May 2010 - 2 day course http://bit.ly/bfS9G1

Your Corporation: Corpus or Corpse? http://bit.ly/cZy03n

Still getting interesting comments on my last post about Scrum certification. Looks like I struck a nerve... http://bit.ly/dr5byR

What is a Project Plan? http://bit.ly/9OHnnl

Moving Items Backwards on a Kanban Board http://bit.ly/9l6YD2

Really InfoQ picked up my post from this morning and added some color commentary... http://bit.ly/9Dws8Q
Emerge ground up or build to plan? http://bit.ly/bpPBlU

Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” http://bit.ly/bHZM8t

Trusting People You Don’t Know http://bit.ly/bgefq0

There is no velocity before there is a velocity http://bit.ly/c3gTJL

PCAMPATL: Learning, Sharing and Discussions http://bit.ly/b322de

Time for a change http://bit.ly/bfNLj9

The relentless search for "tell me what to do" http://bit.ly/dpaOrK

Managing Risks and Opportunities http://bit.ly/d7eXUj

Scrum Checklist translated to Russian, Japanese, German, and Portuguese http://bit.ly/cT9Les

Replacing the Iron Triangle of Project Management? http://bit.ly/dcXVlV

CIO Bad Habits – Still valid 7 years later http://bit.ly/ciwBl3

A few weeks ago, I had a guy come over to my house to do a little handyman work. I needed my deck stained and my front porch painted. Both were really showing signs of wear. I was afraid if we didn't do something quickly, we'd end up having to do some more significant repairs later on.

The guy did an excellent job, my deck looked great and my front porch was as bright and clean and as freshly painted as the day we moved in. The only problem was, now with my porch looking so good, it made the rest of the house look like crap. I didn't see that the rest of my house needed work until I saw it in comparison to my new porch.

Here's an interesting question. If I knew how much work there really was to do, should I have ever gotten started painting my front porch in the first place? If I had known the full scope of the repairs, would it have been better to wait until I was ready to do the whole job at once? If I had waited to do the whole job at once, would we even have realized there was a bigger problem?

Since I decided to go ahead and get started painting, I took a risk that we'd find problems we weren't prepared to fix. If we had chosen to do nothing, we'd have risked ending up with even more costly repairs, due to our neglect. Would it have been better to just maintain the status quo? Did we do the right thing getting started... even though our house isn't as complete as we'd really like? Is knowing the depth of your problem a good thing or a bad thing?
Personally, I think it was a good idea to get started. My house is admittedly a little out of whack... but now I know the scope of what I need to fix. I can do something about it. I have a nice new looking porch that just screams at me to do the rest of the work. The handyman didn't have to tell me, I see it for myself. I have the opportunity to do the work that needs to be done , and I can avoid costly repairs down the road. I can plan.
To be honest, I wish I would have seen the scope of the problem before we got started. There is a part of me that wishes the handyman would have pointed it out. In some ways though, I am glad he didn't... I am not sure I would have decided to get going until I was ready to do the whole thing. I think that the secret is being able to see the big picture, but having the fundamental courage to take the first step.
If we understand the bigger picture, we have the opportunity to invest our limited resources where we can have the greatest impact.

To some extent, I think that Scrum is going through an identity crisis. Part of what has made Scrum so successful is its simplicity. We've got three roles, three ceremonies, and three artifacts. That's a pretty refreshing idea to those of us that came out of much more heavyweight methodologies. Scrum has a simple elegance that is easy to communicate and easy to sell.

The Scrum community is full of some really smart people. If you've been building software for more than 10 minutes or so, you know that Scrum doesn't tell you everything you need to know to be a good software engineer, a good tester, a good business analyst, or even a good ScrumMaster. It is up to us to bring our skills and experiences to the table and fill in the gaps. We figure out how to make it work.

So here is what I want to know... if Scrum is a simple framework... if it is so clear and precise that we can talk about Scrum-But and call out those people that aren't doing it right... where is the definitive body of knowledge? Where is the documented set of stuff that is acceptable on most Scrum projects, most of the time? How do I tell the difference between when I'm bending Scrum to hide my own disfunction versus just filling in the gaps? Who gets to decide? Am I just supposed to know it when I see it?

This identity crisis becomes really apparent when we start talking about Scrum certification. What is there really to certify when the rules of Scrum are so simple? Not much. What about when we start offering specialized certifications like the Certified Scrum Product Owner? What does Scrum really teach us about being a good Product Owner? In my opinion, not a whole lot. How about a Certified Scrum Developer? That role doesn't even exist in Scrum. Furthermore, does Scrum say anything about good development practices? Not at all.

Scrum can't have it's cake and eat it too. It can't be a simple framework that is not prescriptive and then start certifying people on how to do all this stuff.

If we are going to acknowledge that there is actually a set of generally accepted practices that work well with Scrum, let's start building our body of knowledge and open up Scrum to public debate. I just can't get my head around certifying anyone on anything without at least a general definition of what we are certifying against. In the absence of some sort of accepted standard, 'Certified Scrum' anything is just a marketing gimmick.
What do you think, am I missing something?

Hey everyone! VersionOne has finally decided to do an Agilepalooza in my hometown... and VersionOne's hometown for that matter... Atlanta, GA. The event is on February 26th and you guys have to come.
This will be my third 'palooza and each one has been an excellent, excellent event. These guys bring in great speakers and deliver a lot of information for a really reasonable price, only $69. This is not a marketing event... it's not a sales pitch... it's not a product demo... it's a mini Agile conference right in your own back yard. We'll learn a lot and have a blast doing it, I promise!
Right now we've got yours truly doing two talks... one talk will be on the learning agility stage, the other on the advancing agility stage. We also have George Schlitz from Big Visible and Lee Henson from VersionOne. Head over to http://www.agilepalooza.com for more information on the lineup and how to register.
If you are within 300 miles of Atlanta, there is no reason to miss this event. I'll look forward to seeing you there!

Pretty light week when it comes to Agile blogging, huh? Have we really said everything there is to say!? Maybe the conversation has moved elsewhere? Anyone know of new bloggers out there that I don't seem to be following? Maybe it is time for Jurgen to post another Top 200 list. Anyway.... if anyone knows where all the good conversation is going on, please clue me in ;-)

Here is another installment of Interesting Post...
Tackling LEAN change week 1 http://bit.ly/cX8ETR

The Impact Of Social Networking On Project Management http://bit.ly/amG8hU

How Not to Hurry http://bit.ly/9IXVYy

Do I Need User Stories? http://bit.ly/96ghsp

Use the Agile Triangle Instead of the Balanced Scorecard http://bit.ly/cnfr5l

Shu Ha Ri as the flow of Energy http://bit.ly/6DV7BY

Why the CIO Loves Agile Development http://bit.ly/8sxzUn

Pillar Technology is Hiring http://bit.ly/8NLfyo

Don't aim for the target http://bit.ly/8LrZCT

Pope tells priests: Start blogging http://bit.ly/5BxcpY

PMI Agile Survey http://bit.ly/5yY946

Doing what I do for a living, I find myself often trying to explain agile concepts to folks that are relatively new to agile methodologies. Sometimes this comes up when I am teaching a class, doing a conference talk, or breaking down some idea in a blog post. I thought I'd share my approach with you guys, and a little on how I think about this, and see if you guys have anything to add.

Agile is a Family of Methodologies
Okay... so you are going to 'adopt agile'. What exactly does that mean? Well... if you are going to change how you are delivering software, it helps to start with an understanding of the methodologies and approaches that you have at your disposal. I like to start off talking about these methodologies and how they relate to each other.

• Extreme Programming
• Scrum
• Agile Unified Process
• Adaptive Project Management
• Feature Driven Development
• Dynamic Systems Development Method
• Crystal Clear
• Lean
• Kanban

Methodologies Share a Common Value System
What came first, the chicken or the egg? If you look at the history of Agile, the manifesto didn't come first. We had some folks in the community, folks that were already using lightweight methodologies, that came together to explore what these approaches had in common. After we have an anchor point with the various approaches, I like to talk about the principles and values that unite them. Seems consistent with how we actually evolved as a community.

• Agile Manifesto
• Declaration of Interdependence
• Lean Values

Supporting the Modern Development Organization

Next I like to explore what these methodologies have in common from the standpoint of how we build software in today's modern product development organizations. Each of the methodologies express different aspects of the product development lifecycle. XP is heavier on engineering, Scrum heavier on project management and team dynamics. I like to explain the methodologies in terms of how they address stuff we are already familiar with.

• Engineering
• Project Management
• Business Analysis
• Leadership

Practices that are Consistent with Values

Now is a good time to explain the practices that are associated with many of the common agile approaches. Doing these practices doesn't make you agile, but if you understand how they fit into and support the values and attitudes, they certainly do reinforce an agile mindset.

• Iteration Planning
• Daily Standup
• Iteration Review
• Retrospective
• Pair Programming
• Continuous Integration
• Test Driven Development
• Small Teams
• Co-location
• Collaboration
• Information Radiators

Artifacts that Support Practices

Similar to the practices we just discussed, agile artifacts don't make you agile. These artifacts are proven to support agility and make collaboration and responding to change all that much easier.

• Backlogs
• Users Stories
• Burn-down Charts
• Cumulative Flow Diagrams

Agile Roles and Responsibilities
At the end of the day, it is the people in your organization that ultimately determine your success or failure with agile methods. It is important to tell them how adopting an agile methodology is going to impact what they do for a living. When I talk about roles and responsibilities, I often find myself talking about culture and the impact that agile adoption is going to have on yours.

• Customer
• ScrumMaster
• Team
• Business Stakeholders
• Managers

Scaling Agile
All but the simplest organizations are going to have to deal with the scaling issue at some point in time. Even if you are going from one team to two, or two teams to four... understanding how scaling impacts your business is an important part of the adoption discussion.

• Agile organizations are built around cross-functional teams
• Structure and culture will trump people, process, and tools every time

Final Thoughts and a Bit on Chapter Two
This isn't an exhaustive list, just the things I seem to come back to the most. It's raining here in Atlanta, so today I am doing some writing. My kids are going to drag me off the couch in a few hours and make me take them to the indoor airsoft arena, so I need to get a few words in while I have the chance. Chapter two is going to explore some of these ideas in more detail, so I expect to share some more on this approach over the next few days. Stay tuned!

Last year sometime, I heard Jim Highsmith do a talk on replacing the traditional project management iron triangle with a new 'agile triangle' that is based not on time, cost, and scope... but instead, based on value, quality, and constraints (time, cost, and scope). This is a concept Jim introduced in the latest release of his book Agile Project Management: Creating Innovative Products. Something in the idea has been bugging me a little, so when I read Isreal Gat's post this morning, discussing ways to use Jim's agile triangle, it got me thinking.
The general idea behind the agile triangle is that we need to take the focus off of delivering to a set schedule, a fixed budget, and some predetermined set of deliverables; and focus more on the value the product is delivering. In principle I agree, but does it make sense to modify to triangle to deliver that message?
I've always looked at the iron triangle as a way to explain the relationship between time, cost, and scope. If you change one of the three variables, the physics of project management says that one of the others has to change too. If I want to add scope, time or cost has to go up as well. If I want to deliver in less time, I either need more budget or I need to reduce scope. If I want a less expensive product, I either need to reduce scope or reduce the time it takes to build it.

I'm curious if the agile triangle follows this same pattern. If I increase value, does quality have to go up or down? Do the constraints have to change? What about if I change quality? Does value go up? Do I have to change the constraints? What about the constraints? If I tweak the constraints, does that always impact value or quality? There are some guesses that we can make, but the agile triangle doesn't give us any guidance. The relationships between the variables are less precise, and therefore I think using the triangle metaphor is less powerful.
We all know of projects that have come in on-time and on-budget, with everything the customer wanted, and have been total failures in terms of market performance. I agree that we need to focus on value and quality as first class citizens in the project management discussion. To me though, quality and value are attributes of scope, and it just comes down to the definition of done. Do we have features in our backlog that are 'done' when they have poor quality? Are they 'done' if the customer does not accept their value? Value and quality are part of the acceptance criteria of scope.




















I would probably flip what Jim did a bit and leave time, cost, and scope as the vertices of the triangle, but just like Jim broke the constraints into three attributes, I would break scope into three attributes... requirements, quality, and value. So, the question is... are value and quality project constraints or attributes of scope. I think you know where I stand ;-)

Pillar Technology is ramping up several large projects in Columbus, OH and Detroit, MI. We are in need of a bunch of people and have opportunities at many different experience levels.

We are looking to hire immediately and will entertain people who want to work 1099, W2 hourly, or become full time employees of Pillar Technology. Pillar's strength is the quality of our people and we are pretty selective about who we bring in. We are looking for people that are technically excellent, have great communication skills, and will fit in well to the Pillar culture.

To be considered for our technical positions, you need to be an experienced Java developer or technical tester and you MUST have experience with TDD. Other skills we are looking for are:

• Jboss Portal
• Portlet Specification
• XML Jibx parser
• Rest
• Strong UI / JSP experience
• Maven
• Team City
• EasyMock

The more of these you have the better.

We also have a few opportunities for team leads and delivery leads. These people must have a solid technical background and be familiar with all the stuff I just mentioned. That said, these roles are less hands-on. To be considered for one of these positions, you need to understand agile organizational structure, team dynamics, how to lead and motivate people. You must be an excellent problem solver and be able to talk a good agile game... and more importantly... deliver results!

I am looking to hire the best of the best in the Atlanta market and surrounding areas. If you happen to be in Columbus or Detroit, even better. Travel will always be a part of this gig, but we want to keep it to a minimum. Most of our work right now is in the Detroit and Columbus markets and we are building Atlanta. We try to hire locally, so that we can keep people close to home. We are a values driven company, and we know that being home is important. That said, if you live somewhere else, and don't mind the travel, we can talk.

If you are interested, please contact me at mcottmeyer [at] pillartechnology [dot] com. If you send me your resume, and I think you are a fit, you'll get a call from me this weekend. Thanks!

ProductCamp is returning to Atlanta on February 6, 2010.
I wasn't able to attend the last one, but heard from numerous folks that DID go, the event was excellent. Last year's productcamp attracted somewhere around 250 people. This year's event has over 200 signed up with nearly two weeks left to register. I believe this is a must attend event if you have any inclination toward Agile, Product Management, or Marketing. Head on over to http://barcamp.org/productcampatlanta to learn more information and to register. It is free... it is on a Saturday... what more could you ask for!
BTW - Pillar Technology just signed up to be a Gold level sponsor. That means I'll be there for sure . If you are in town, please make sure you come and find me, I'd love to meet you face to face!

Here is the last little bit of Chapter 1. Here we explain how we've laid out the book, and a bit about why. I want you to understand the entire story first, so as you are reading, you not only have context from a persona perspective, but also context from a structure and story telling perspective. This is not a mystery novel... we don't want you to have to guess or experience any unexpected plot twists. Our goal is for you to know where you are every step of the way.
Understanding the Book’s Layout

The structure of Value Driven Agile Transformation is designed to incrementally introduce the key concepts necessary to lead a meaningful agile transformation. The book is broadly divided into halves, each half containing two sections:

The first part of the book is designed to help you clearly understand your goals so you can compare them against your current reality. Understanding the gap between where you are and where you need to be is often half the battle. We’ll spend time talking about what it means to lead a value driven enterprise agile and explore the challenges you’ll face along the way. We’ll talk about the dynamics that drive your current organization and how to begin thinking about how you will lead change.

The second half of the book will focus more on how to get where you want to go and how to overcome specific challenges in a pragmatic and systematic way. After going through this material, you should have a clear idea how to determine what your organization finds valuable and how you can begin road mapping your agile transition. Your plan is going to change as you implement and learn, but you’ll understand why and be able to articulate the impact of the changes.

We have included for your reference an appendix that explains the tools we use to implement this approach as well as several section helping the reader understand the relationship between agile and various capability based approaches to enterprise process improvement. These sections are included so you can assess the similarities and differences between an enterprise agile transformation and more traditional approaches to process improvement.

Section 1: Understanding the Goal

Chapter 1: Defining Agile

Many folks lead with an intuitive sense that agile is going to solve their problems. If we just get that agile going, everything is going to be okay. Over the years agile has become an extremely overloaded word. Some days agile is nearly synonymous with specific agile methodologies and some days so abstract as to be meaningless. This chapter will establish a solid foundation for understanding agile in its broadest and most abstract context. We’ll also dive down deep enough to understand the specific values, principles, and practices that really make it hum. We’ll explain many of the common methodologies and practices and how they fit into the bigger picture of enterprise agile software development.

Chapter 2: Defining Transformation

Now that we have a common understanding of what agile is, and how we might begin to apply some of these concepts into our organization, we want to get really specific about what we are really looking to change. Are we interested in helping one or two teams adopt agile practices or are we talking about a company-wide change initiative? Are we looking to adopt a few practices (like test driven development and iteration planning) or are we looking to influence how people think about the nature of their work? Are we trying to instill values or just change the way people behave? This chapter will help you answer these questions as well as explore the various aspects of change management you’ll need to understand before you get started.

Chapter 3: Defining Value

The only reason to even think about introducing this kind of change is to get some sort of return on your investment. That return doesn’t have to be hard dollars, but if that is what your organization is looking for, you better understand that and make sure you deliver. If you’ve ever tried to have a conversation about value, the idea is pretty misunderstood and very context sensitive. This section will help you explore the many ways that your organization might create value. We’ll talk about the difference between things that might have intrinsic value and things that have actual market value. There is often a big gap between valuable work and value that the business is willing to pay for. We’ll discuss another five phase model to help you understand how various stakeholders in larger organizations might perceive value.

Chapter 4: Establish the Change Vision

The change associated with a value driven agile transformation lies at the intersection of value, transformation, and methods and practices. Understanding how your organization delivers value is the first step in the transformation process. By focusing on the areas of the business that create the most value, you are most likely to create positive outcomes and a return on your investment. Next you have to understand the scope of what you are changing and finally what principles, values, or practices you want to introduce to implement the change. This chapter will explore the tools you need to define this intersection. We’ll discuss the importance of top down vision and bottom-up incremental adoption. We’ll lay out the conversation framework, the modeling tools, and the adoption and scaling approach defined later in the book.

Section 2: Understanding Our Current Reality

Chapter 5: Understanding the Traditional Organization

At this point, you should have a better idea of where you are headed, and how you might want to get started. Before you begin though, there are some things you need to understand about your current organization. Chances are, it was pretty successful long before you came along. It might not want to change and you need to know what you are up against. This chapter explores the traditional software development organization as it exists in many companies today. This chapter will focus on understanding how your current organization operates and how it got where it is today. We need to know how it has been successful thus far and why it might be harder to be successful in the future. We want to fully understand what we are changing before we go and try to change it.

Chapter 6: Understanding the Agile Organization

Chapter 1 established a solid framework for understanding what agile is. Now we are going to take a look at why and how agile works. We want to understand teams and why they are so important as the building blocks of the agile enterprise. We want to know how to really make them really hum. We’ll discuss different approaches for managing agile teams and approaches that encourage us NOT to manages agile teams. This chapter will explore the differences between black box management and white box management and the importance of establishing stable inputs so the team can establish predictable outputs. We’ll talk organizational constraints and how they influence team behavior. Basically, everything you need to know about how and agile team works.

Chapter 7: Why Larger Agile Transformations Fail?
(or don’t live up to the promise)

Many large-scale agile transformations either fail or don’t live up to the promise. Many companies might claim to be agile, and many may have even adopted some agile practices, but they are not getting the business outcomes that they expected. This IS NOT what we want to have happen here. This chapter will help us understand some of the common failure modes we might see in a more traditional organization as they make the switch to agile. We’ll explain why some of these same root-causes work against us and the new changes we are trying to put in place. We’ll explore issues around local optimization, command and control management, organizational structure and alignment, and traditional/agile hybrid environments.

Chapter 8: Selling Change Up the Organization

If you think transforming your team is hard work, try convincing senior leaders to let you try is even harder. Convincing them to let you transform the enterprise is even harder yet. This chapter will explore why leaders might be okay with agile at the team level but are resistant to advocating agile across the larger enterprise. If we want to lead an agile transformation, we need to learn why the messaging around agile doesn’t always resonate with our senior leadership. It goes back to how different stakeholders measure value but the conversation goes deeper. As agile proponents, we need to learn how to bridge the gap and help our leadership create a safe environment for introducing change. This chapter is about helping you understand and communicate your value proposition to your leadership team.

Section 3: Understanding What We Value

Chapter 9: Deciding What Your Organization Values

Now that we have a good idea of where we are going and why, and we are armed with knowledge about the challenges that stand before us, it is time to start thinking about how we want to move forward. This chapter will help us understand what your company values. Sometimes it is not just valuable software that your organization wants. We need to assess the cultural aspects of your organization. What kind of importance does your organization place on documentation, group decision-making, organizational politics, and governance? Are you operating in a regulated environment or not These are things we need to know about before we get started.

Chapter 10: Understanding How to Create Value

Believe it or not, not everyone is in business to sell software. Value isn’t always about getting features to market faster than our competition. If we are selling software, we need to understand our most important market opportunities and how we can best deliver products to market that people want to buy. If we aren’t selling software, we might be responsible for writing software that enables internal business processes. We might be in a mature market where maintenance and support is most important. Our goal could be less about building new features and more about keeping costs down and profit margins high. This section will outline a detailed approach for helping your organization understand how it creates value in its marketplace, whatever that marketplace might be. We will talk about tooling and approach for pragmatically identifying what your organization finds valuable.

Chapter 11: Understanding Your Improvement Opportunities

Using a similar approach to the one we used for understanding how your company defines value, we will explore what your organization needs to improve to get better delivering that value. Teams and organizations can’t get better at everything at the same time, the change would be too disruptive, too expensive, and introduce too much risk. We’ll explore the kinds of problems that your company might want to solve, how to understand them in the context of a broad set of goals and core capabilities, and how to choose which areas to invest to get maximum benefit.

Chapter 12: Identifying the Intersection

This chapter will introduce in detail an approach to organizational improvement called capability analysis. We’ll explore the mechanics, the tools, and the conversations required as well as. Here we will talk about gaining consensus around value and which capabilities we want to improve. Here we will introduce the five phase agile scaling model and take a step-by-step walk through the kinds of capabilities we might want to get better at delivering. The three facets of this section are going to be the five questions, 30+ core capabilities, and the four categories (Project Management, Product Management, Development, and Leadership). We’ll leave this chapter with a firm idea of where we want to spin up our first agile team.

Section 4: Creating the Value Driven Agile Enterprise

This section introduces a five-level agile adoption and scaling framework. At each level; we help identify cultural challenges your organization will face, how it defines value, and what you can improve to get better business outcomes. We’ll explore many common challenges your company is likely trying to solve, figure out which capabilities have to be addressed to see improvement , and identify what agile practices you and your company might put in place to get better in that area. We’ll explain the conversation context, the learning patterns, and the expected outcomes that will drive improved organizational performance.

Chapter 13: Team Level Agile Adoption

This section will explore the principles and practices many of us are familiar with from basic Scrum and XP. The difference here is that we will take a value driven approach to selecting which practices we want to put in place first. We’ll assess the capabilities of the organization and pragmatically decide what to start on first. This section will deal with introductory agile project management, discuss the role of a product owner and the roles and responsibilities of the other team members. We’ll introduce basic agile reporting, agile engineering, and agile teamwork and leadership concepts. This will in essence be a comprehensive survey of agile methods with an eye toward helping the reader understand why they might choose to put particular practices in place.

Chapter 14: Horizontal Agile Adoption

Horizontal agile adoption is about taking what we have learned at the team level and replicating that success to many teams across the organization. Our assumption at this point is that we have created our first agile team and used the capability baseline to determine where we need to improve next. We’ll end up at the end of this chapter with several distinct teams, loosely coupled, with a low number of dependencies between them. Here we will introduce the idea of a Scrum of Scrum for managing simple interdependencies between teams. We’ll take a look at common patterns of reporting across teams, handling shared code bases, building distributed engineering environments, estimating and tracking progress, and multiple product owners.

Chapter 15: Project Level Agile Adoption

This chapter begins to introduce the idea of having multiple teams work together to deliver larger, more complex projects, where we have to manage dependencies between teams. We are moving up one level in the organization hierarchy and there is a good chance the nature of our value discussion is going to change. We will apply capability analysis to figure out which projects need our attention and how to improve them. We’ll address how to deal with highly interdependent feature teams and possibly component teams on larger enterprise initiatives. We’ll introduce the idea of tracking value at the project level separate from value the team level. We’ll need to expand our agile toolkit and start extending basic concepts and introducing a few new ones.

Chapter 16: Program Level Agile Adoption

Program level adoption is focused on dealing with multiple projects, multiple stakeholders, competing priorities and competing agendas. It is about throttling work through the organization, defining smaller projects, and working on fewer things at one time. There is an emphasis in this section on balancing load across teams, a thorough discussion of the theory of constraints, and more Lean portfolio management. We’ll talk about how stories are to projects as projects are to portfolios and introduce the idea that projects need to follow the INVEST model too. If we make projects smaller, we can increase flow through the organization and start worrying more about getting projects finished rather than getting more projects started.

Chapter 17: Enterprise Agile Adoption

Enterprise agile adoption takes the value proposition up yet another level in the organization. Here we look at the entire value stream from concept to cash. We are managing the flow of value across the entire enterprise and all the value creating processes. We want to deal with upstream processes like project selection and approvals, business cases, and strategy. We also want to deal with downstream processes like maintenance and support. We want to balance the flow of value across the entire organization. This is the point in our transformation when we have truly created an agile enterprise, one that is prepared to deal with anything the market can throw at it.

Before We Get Started

Before you get started, keep in mind that agile adoption is not an event. It is a process of continuous improvement where the journey is almost as important as the outcome. By focusing on principles and the core problems you are trying to solve, and not the rote application of practices, we have a shot at creating a sustainable change framework; a learning organization. People do not change overnight and companies don’t either…

Okay... so that is it for Chapter 1. Let me know what you think and if you have any feedback.