Getting Started With Agile... One of Five

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.

Subscribe to Leading Agile

Agile Training from Mike Cottmeyer and Pillar

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

Subscribe to Leading Agile

How to Get Started With Agile?

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.

Subscribe to Leading Agile

Just In Time Agile2010 Submission

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!

Subscribe to Leading Agile

Getting Started With Agile (#agilewebinar)

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.

Subscribe to Leading Agile

Cory Foy Nailed It

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.

Subscribe to Leading Agile

Sacred Cows?

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!

Subscribe to Leading Agile

The Lean Software & Systems Conference

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.

Subscribe to Leading Agile

Product Owners in Practice

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.

Subscribe to Leading Agile

Interesting Post... 2/4/2010 through 2/13/2010

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

Subscribe to Leading Agile

A Lesson in Getting Started...

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.

Subscribe to Leading Agile

Having Your Cake... Some Thoughts Around Scrum Certification

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?

Subscribe to Leading Agile

Agilepalooza Atlanta!

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!

Subscribe to Leading Agile