Tag: Methodologies

The agile methods are deceptively simple and common sense oriented. In many ways, that’s one of their great strengths, but its also one of their fundamental weaknesses. I see so many teams convinced that they can “go Agile” just by reading a book or an article and then diving in and “sprinting” towards successful software delivery. The logic goes that agile is simple common sense practices, self-directed, and intuitive—so of course it will be simple to pick up and execute.

I typically categorize these teams as “bad agile” teams in that they adopt a small, superficial, and somewhat trivial set of the core agile practices and then think they’re agile. In almost every case they don’t understand the agile mindset nor how the core principles and practices complement one another to foster improvement. They’re “doing Agile”, but they’re not “being Agile”.

Ken Schwaber coined the term ScrumBut to capture this common anti-pattern, as in—“We’re doing Scrum, but…”. And Ken was solely focused on Scrum in coining the term. I’ve also found the Extreme Programming practices to be a wonderful complementary set of agile practices and they’re often left out of the conversation as well.

One of the core drivers for this is that teams don’t receive sufficient agile training from the right level of experienced coaches and trainers. So, yes, you can pin some of the blame on the teams themselves. But I think some of the assumptions we’ve set in the agile community are also to blame.
In this post I want to explore what sorts of training are sufficient to get agile teams up and going. In this case, I’ll be using Scrum as the baseline methodology for the discussion. But you could essentially replace Scrum with Extreme Programming, Kanban, or any other agile methodology. I think the points generally remain the same.

Before we go after training in general, I want to explore certifications—most of which have a strong training component as part of their adoption.

Agile “Spaghetti” Certification Choices

There are essentially seven certifying bodies at the moment with respect to agile—sort of a spaghetti like set of choices to make. In a nutshell, they include:

1. Scrum Alliance: the venerable institution that certifies Scrum Masters (CSM, CSP) Product Owners (CSPO), Coaches (CSC) and Certification Trainers (CST). There is some movement towards individual team member qualification as a Certified Developer (CSD), which focuses on hands-on development practices. When I sampled the website for this post, there were over 130,000 Certified Scrum Masters, over 130 Certified Scrum Trainers, and over 40 Certified Scrum Coaches. Clearly the Scrum Alliance is still the leading certification body in this space.

2. Scrum.org: this is Ken Schwaber’s group that is a historical spin-off from the Scrum Alliance. He started it after breaking with the Alliance Board. Aligned with the Scrum Guide, he’s established a 2-tier certification for the Scrum Master and the Product Owner. Scrum.org also has a very strong offering targeted at the developer or practitioner. This is more or less a direct competitor to the Scrum Alliance (CSD) and may be a stronger offering than it is. Arguably, Scrum.org focuses more on assessments and practitioner-level skills. It’s also clearly not as widely known as the Scrum Alliance.

3. Net Objectives: has been focusing on more enterprise level and lean agile training for quite some time. They also offer certifications as part of their training offering, two examples being Agile Project Manager and Product Owner. It’s more of a niche certification, although they’re very well respected in the Lean, Kanban, and Enterprise Agile spaces.

4. ICAgile: is more of a generic Agile BOK (Body of Knowledge) certification authority. They provide sensible “outlines” for what good courseware should cover in specific areas of agile AND they “certify” materials and provide certification management mechanisms. So they don’t provide a certification per se, they provide some trainer material consistency & transparency assurances. A promising part of ICAgile is the breadth of their purview—virtually covering all areas of agile practices and not simply Scrum Master or Product Owner roles. Definitely a WIP though…

5. Dean Leffingwell – SAFe: has begun to dominate the enterprise / scaling agile space and is offering a certification around his scaling framework. He calls it a Scaled Agile Framework (SAFe) and is offering various levels of certification for its implementation. He is delivering the certification via his Scaled Agile Academy. To be fair, this is a brand new initiative and, even though Dean is well-respected, it’s not clear we need this certification in the market.

6. CAT – Certified Agile Tester: mostly a European-centric certification, this is the only tester focused certification out there. If you review the website, there aren’t too many certified testers yet, perhaps +/- 200, so I’d consider this a beta and experiment at the moment. The primary customer seems to be European at the moment—probably because of the intense general certification interest there.

7. PMI-ACP: finally, the very venerable PMI has entered the fray with the Agile Certified Practitioner or PMI-ACP certification. After running a beta test in late 2011, there were over 2000 certified practitioners as I write this post in May 2012. Beyond the certification, there is a Community of Practice and the PMI seems to have embraced the notion of agile. The guidelines for certification are quite loose at the moment—being driven mostly by a “reading list”. PMI has yet to develop an “Agile BOK – Body of Knowledge” upon which to more fairly base the certification.

8. IIBA: while not directly certifying BA’s from an agile perspective, the IIBA has defined an Agile Extension to the BABOK Guide. It’s a collaborative effort between the IIBA and the Agile Alliance to establish a baseline definition. Between ICAgile and IIBA, you probably get the best BOK-related references. It’s currently unclear how they’ll be leveraging it in their certification program(s).

I think the fact that there are so many certifications and how quickly they’ve grown from the Scrum Alliance is a testament to the popularity and pervasiveness of the agile methods. However, I can’t help but think that the sheer number of options dilutes the value from a certification-holder perspective and from a prospective employer perspective. How in the world do you select a path through this mass of spaghetti?

The other problem is that all of them place a focus on prescriptive knowledge acquisition (reading & memorization) and traditional testing. Very few of them emphasize real-world experience and verify that with more serious examination and proof. The Scrum Alliance CSC attempts to set a very high bar for entry and the numbers bear that out. But very few of the other certifications attempt to do that.

Most often the recipe is study a set of materials, then take & pass a requisite test. Then you have the credential. In a methodology that places so much on inspect & adapt hands-on experience; this really doesn’t pave the way for practical and situational experience.

My personal preference is that Scrum Masters need real-world experience and that it trumps all of the certifications. I’d much rather hire a person who’s been in an active Scrum Master role for 1-2 years, than someone who’s simply acquired a certification and thinks they can generally map their experience towards the role.

Body of Knowledge(s) and Consistency

The other thing that is somewhat lacking across the certifications is consistency.

For example and to their credit, the PMI and the IIBA both have developed a Body of Knowledge or BOK that is the basis respectively for the PMP and CBAP credentials. The BOK clearly identifies the areas of study and competency that a holder of the credential must achieve in order to receive it.

While you may disagree with what’s in the BOK, it at least provides a consistent baseline for the certification. I believe this is what ICAgile is trying to achieve by reviewing course materials on various agile topics.

Most of the other certifications don’t baseline themselves on a transparently established BOK—so there is widely disparate coverage of the topic based on which instructor / trainer you choose. The CSM is notorious for this, because each CST has their own set of material and covers the topics that they believe most relevant for the certification.

While this is allows wonderful flexibility for the CST, attendees can get very different views. I know of one company that sent employees to two different CSM classes taught by two different trainers because of geographical distribution. When they pulled these folks together on teams, they found that they didn’t have the same understanding of basic Scrum and agile practices. It caused the teams’ tremendous start-up pain and needed additional coaching to get the teams on a level playing field from a core skills perspective.

That wouldn’t have happened with improved consistency amongst CST’s. And I don’t think the burden of discovery should be on the client in these cases.

Even the PMI-ACP doesn’t yet have a BOK. What they do recommend is a “reading list” of 10-12 agile books that serve as the core of the certification. That’s an awful lot of reading and little real-world experience.

So be wary of how each certification quantifies its coverage and look for some semblance of consistency either by basic BOK definitions or partnering with a specific coach or trainer to better understand their philosophies and content delivery.

Basic Training

When I kick-off a Scrum team I have four levels of basic training that I’m trying to instantiate within the organization.

1. Team-level—training the entire set of teams that will be initiating Scrum in the core methods. Usually this is a short class, 4-8 hours, with several workshops or games that illustrate the core behaviors of agile teams. This gets everyone on a level playing field for the method, roles, terminology, and basic practices.
2. Product Owner-level—training the selected Product Owners and the entire product organization in the nuance of user stories, Product Backlogs, and Road-map Planning techniques. I’ll usually coach them until they have a well-established backlog for their first release and have a solid tempo of grooming meetings established.
3. Scrum Master-level—this training can take the form of sending individuals to CSM (or similar) classes, or running an internal class that focuses on the role. I prefer the latter approach and then jump-starting the Scrum Master in operating in their roles. After 3-6+ months if they want to go for a CSM, they can do it from a position of experience.
4. Organizational Leadership-level—training here focuses on the role shift for managers and executives in moving towards Scrum and agility. Addressing the requisite changes in their roles and how they have to adapt for effective agile adoption. I’ll also review organizational transformation strategies for specific functions, for example: the PMO, or Testing Center of Excellence.

I basically think that a team shouldn’t be “going Agile” without these four levels of basic training in place. They don’t have to be exhaustive, in fact all levels can be delivered in 2-3 days, but the overall balance in understanding they provide is often crucial for an organizations adoption.

Beyond the training, I don’t think you simply “walk away” and let these teams fend for themselves. As we’ll explore next, coaching is also a very responsible thing to do.

Training without Coaching is Irresponsible

As I alluded to earlier, agile training and certifications are IMHO virtually useless without real experience. And that experience isn’t gained without coaching and mentoring.

I’ll use a real story to make the point.

I was working with a team on starting up their adoption of agile. I came in and ran what I’d call an Agile / Scrum 101 session—equivalent to the CSM class. Everyone on the projected teams were “run through” the course as we setup the Scrum teams and Backlogs; preparing to start sprinting.

As a coach, I was given the opportunity to kick-off the first round of sprints. But then something wonderful & terrible happened. The client felt confident and comfortable with their skills—I guess I’d done too good a job of training. So soon after starting, they told me that they felt comfortable on their own and didn’t need any additional coaching.

I tried to convince them that having a coach around in the beginning was a very, very good idea; but they truly felt they had it down and declined. Six to nine months lapsed and I checked in on them a few times via email. The VP of Development kept saying that things were going “swimmingly” and they were truly enjoying agile development and the results.

But somewhere around the nine month mark I received a strange call. Things were “off the rails” at the client and they wanted me to come in and assess what was going on. When I arrived, I quickly agreed with their assessment. You could barely tell that they were applying the principles they’d been taught and there was tremendous distrust between the leadership and the teams—driving a lack of transparency and truth-telling. I was not totally surprised, but I was incredibly disappointed that they hadn’t called me sooner.

We quickly righted the ship and they’ve since become a stable, mature, and continuously improving agile organization. They’ve also agreed that ongoing, periodic coaching is a necessary part of their agile adoption until they gain more experience and sustainability.

That’s one of the key points I wanted to make in this article. The agile methods are deceptively simple and often newbie teams want to go it alone with too little training and little to no initial coaching. In most-all cases I think they’re making a HUGE mistake. Agility is very much of a mentored and experiential approach to software.

You’ll want to engage an experienced coach to help you adopt the methods (doing Agile) but also to internalize the core behavior changes at all tiers in your organization (being Agile) so that you truly gain the benefits of adoption to drive business value across your organization.

Wrapping Up

Solid Agile Project Managers can be a strong influencing point in early stage adoption. You can help the organization plan for training and ongoing coaching. You can encourage your teams to acknowledge their need for help—and you can have the seasoning to ask for it as early as possible.

You’ll realize that having experts around is not a sign of weakness, but truly a sign of strength.

Another area where you can help guide your organization is across the spaghetti confusion from all of the certification options. While training and certifications are an important part of adoption, you can provide the balance to help everyone understand that agile is about “the doing”. So having practical experience and gaining it with effective mentoring is truly a crucial part of your maturity and growth.

Thanks for listening,

Bob.