It’s about time…

Written by Mike Cottmeyer Saturday, 27 March 2010 05:10

Join the conversation. There are currently 3 comments.

Getting Started with Agile… Two of ‘Who Knows’

Written by Mike Cottmeyer Friday, 19 March 2010 03:30

Okay… way too big a gap between meaningful blog posts. Since it has been so long, you might want to go back and take a look at the first post in this series called “Getting Started with Agile… One of Five“. There is a bit of irony here around how this post came to pass.

I did almost all of this post two weeks ago. The post got really long. There were a few parts I was still hammering out, a few parts I still am as a matter of fact. The whole post sat on the shelf waiting for the unfinished parts. This morning I decided to break the post in smaller parts and start releasing it in chunks… pretty smart huh? ;-) Amazing how sometimes it is hard to eat your own dog food!
Here goes…
At last year’s Scrum Gathering in Orlando, I heard Ken Schwaber make the comment that in his opinion, over 75% of all organizations using Scrum won’t get the benefit they hope from it. That is a pretty depressing perspective, especially coming from one of the guys that invented Scrum. I don’t know about you, but I am pretty convinced that this agile stuff works. I’ve seen it work, and I’ve seen it work well. If we know agile works, why do we have so little confidence in our ability to make it stick in most organizations?

Personally, I am not prepared to believe that Scrum’s failure rate is because people don’t implement Scrum properly. That’s the whole Scrum-but argument. Scrum is such a light framework, if you give it a serious go, it’s pretty hard to really do it wrong. That said, I do believe that many organizations aren’t prepared to fix the organizational disfunction that Scrum is going to show them. Scrum’s primary benefit is that it shows you the stuff you need to fix. If you aren’t willing to fix the problems, you aren’t going to get the benefit.

How many companies using Scrum are really trying to transform the entire enterprise? I’d wager that most Scrum teams live within a larger, more traditional enterprise. In these organizations, structure and culture are going to trump anything that a single Scrum team does with people, process, or tools. You could have the best team members, run a perfect Scrum, have big visible charts everywhere, and I bet you still stand a chance of falling into Schwaber’s 75% statistic.

For everything we do to build a high-performing agile team, the organization is going to work to pull that team a part. The pull might be intentional, led by people that are threatened by any change to the status-qou. More than likely, the organization just doesn’t get it. The value delivered by the Scrum team just get’s lost within the larger underperforming organization. Even though the team was effective, it just never really translated to any kind of measurable value for the larger organization.

So therein lies the problem. What does it mean to have a successful Scrum team in an organization that isn’t performing very well? What do you do when Scrum helps you identify an impediment that can’t be solved by the team, but no one outside the team seems to care? Scrum ends up being a local optimization within the larger enterprise value stream. Unfortunately, it doesn’t matter how hyper-productive your team becomes… getting higher team velocity isn’t your biggest problem.

The trick to adopting agile is to form a team around a business problem the organization actually cares about solving… one that will increase bottom line performance. And this is where the conversation get’s interesting. Many of us aren’t responsible for improving the whole system. We are only empowered to do our part. We can only operate within our circle of concern. Our challenge is to figure out a way to make our local improvements, but in a way that is respectful of the whole.

There are a few things I want to suggest that will help you understand how your company looks at value delivery. For the rest of this post, I want to talk about aligning your agile pilot team to something your organization actually cares about. The important thing to realize is that not every company has the same kind of goals. If we are going hook ourselves up to big business problems, we need to understand how our companies look at value… how they look at the unit of production. For most, a unit of production is not a single user story delivered by a single team.

Next post we’ll talk about a few ‘units of production’ that I see larger organizations really care about.
Join the conversation. There are currently 4 comments.

Agile Coach Camp, North Carolina, March 19-21

Written by Mike Cottmeyer Wednesday, 3 March 2010 07:36

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!
Join the conversation. There is currently 1 comment.

Getting Started With Agile… One of Five

Written by Mike Cottmeyer Saturday, 27 February 2010 07:12

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.

Join the conversation. There are currently 3 comments.

Agile Training from Mike Cottmeyer and Pillar

Written by Mike Cottmeyer Thursday, 25 February 2010 01:29

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!
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
Join the conversation. There is currently 1 comment.

Public Training Locations

Upcoming Training Classes

2-Day Agile Requirements Course
2-Day Agile Requirements Course
April 7-8 Orlando, FL
Advanced Agile Development with Dr. Alistair Cockburn 3 Day Master Class
April 14-16 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
April 14-16 Reston, VA
3-Day PMI-Agile Certified Practitioner Course
April 28-30 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
May 5-7 Denver, CO
2-Day Agile Requirements Course
May 15-16 Alpharetta, GA
2-Day Certified ScrumMaster Training Course
May 19-20 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 9-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 16-18 Reston, VA
2-Day Agile Requirements Course
June 23-24 Orlando, FL
2-Day Agile Requirements Course
July 10-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
July 21-23 Westminster, CO
3-Day PMI-Agile Certified Practitioner Course
August 11-13 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
August 18-20 Reston, VA
2-Day Agile Requirements Course
August 25-26 Orlando, FL