Having Your Cake… Some Thoughts Around Scrum Certification

Written by Mike Cottmeyer Tuesday, 9 February 2010 12:24

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?

Join the conversation. There are currently 27 comments.

Agilepalooza Atlanta!

Written by Mike Cottmeyer Thursday, 4 February 2010 05:52

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!

Join the conversation.

Interesting Post… 1/24/2010 through 1/31/2010

Written by Mike Cottmeyer Sunday, 31 January 2010 05:34

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

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

Join the conversation.

Agile Methodology : Explaining Agile

Written by Mike Cottmeyer Saturday, 30 January 2010 03:49

Agile Methodology

Doing what I do for a living, I find myself often trying to explain agile methodology concepts to folks that are relatively new to the agile methodology. 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 Methodology : A Family of Methodologies

Okay… so you are going to ‘adopt the agile methodology‘. 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 that are part of the agile methodology 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

Agile Methodology : Share a Common Value System

What came first, the chicken or the egg? If you look at the history of the Agile Methodology, 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

Agile Methodology : 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

Agile Methodology : 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

Agile Methodology : 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 Methodology : 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 the agile methodology. 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 an agile methodology adoption is going to have on yours.

  • Customer
  • ScrumMaster
  • Team
  • Business Stakeholders
  • Managers

Agile Methodology : 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 agile methodology 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!
Join the conversation. There are currently 8 comments.

Replacing the Iron Triangle of Project Management?

Written by Mike Cottmeyer Thursday, 28 January 2010 03:36

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 ;-)

Join the conversation. There are currently 10 comments.

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