Good document on Scrum

Graeme Matthew has provided an in-depth look at Scrum. You can get the document here.

Certification and Agile: Are We There Yet?

I've always been a little skeptical around certifications. Why? Because I am not sure that the certification process is focused on what counts (experience) but what is easily obtainable (knowledge). Seems I'm not alone in that feeling. The Agile Alliance came out with their own viewpoint last week. Here's what they said:

Now that Agile software development is becoming a mainstream practice, more and more employers need to staff teams that will perform it well. How can they know if a particular person will be an asset? One way might be to favor employees who are vouched for by some certification body. It is the position of the board of the Agile Alliance that employers should have confidence only in certifications that are skill-based and difficult to achieve. We also believe that employers should not require certification of employees.

Certifications in our industry usually tell you that a person has been exposed to particular knowledge. Some certifications additionally tell you that she has passed a test on that knowledge. Knowledge is a wonderful thing, but businesses pay for performance. Performance requires skill. A skill is not as simple to acquire as knowledge: the learner has to perform the skill badly, recover from mistakes, do it a bit better, and keep repeating the whole process. Especially for the interrelated and interpersonal skills required of Agile software development, much of the learning has to take place on real projects. It is that learning that a certification should vouch for. Vouching for someone else’s skill requires close observation or questioning by someone already possessing it. For anything other than uninterestingly simple skills, that’s a lot of work–which means it’s expensive. Therefore, the only skills worth formally vouching for are those that require substantial effort to learn.

While a skill-based certification can shorten the hiring or promotion process, there are many skilled practitioners who are not certified. Excluding them from consideration would be a poor business decision. Moreover, the state of the practice moves on. Skills decay when unused. The question is not whether an applicant once possessed appropriate skill; it’s whether the applicant can do what’s required today. A certificate cannot substitute for the hard work of individual evaluation.

Certifications such as Certified Scrum Master and DSDM Foundation are knowledge-based and easy to achieve. We believe the courses that lead to them are good ones. We believe people who attend them get their money’s worth. But while the certifications may be evidence of good faith, useful knowledge, and a desire to learn, they are not in themselves evidence of skill. Higher levels of certification, such as DSDM Practitioner or Certified Scrum Practitioner, require project experience, a written project synopsis, and an oral examination. They are skill-based. Other organizations like the Agile Project Leadership Network are working on skill-based certifications. We applaud their efforts. Although, the position of Agile Alliance remains firmly that employers should not require certification of employees and that skill needs to be acquired by practice on agile projects not by training alone.

I think there is a place for certification in Agile as it has worked for other technical certification processes such as PMI, Sun, Microsoft, and others. It's good to see that Agile is maturing to a point where certification is becoming important in hiring skilled people. However, it's just too easy for anybody to become a Certified Scrummaster. Just a two-day course and viola....you are certified. This does not guarantee that you are skilled in Scrum, have experience with teams, and understand Agile principles and practices. Perhaps some of the higher levels discussed above will demonstrate those skills.

Going to a Lean Development Course - Update!

Next week, I will be attending a 2 day course in Seattle on Lean Software Development. The course is being conducted by Net Objectives and led by Alan Shalloway. I have enjoyed reading Alan's contribution to the Lean Development Yahoo Group and can't wait to learn more. Here is a synopsis of the class taken from their website (you can learn more by going here):

The software industry is looking for ways create quality code in an effective, efficient manner that is rapid, repeatable and reliable. Attempts such as CMMI and Agile methods have found some success but also seem to have some inherent drawbacks.

Of the many methods that have arisen to improve software development, Lean Software Development is emerging as one that is grounded in decades of work understanding how to make processes better. Lean thinking focuses on giving customers what they want, when and where they want it. It provides a way to maximize value while minimizing waste.

The varied background and history of Lean makes it very valuable to practitioners. However, the varied perspectives available from which to look at Lean sometimes makes it a challenge to learn how to apply it. This course takes four prominent perspectives of Lean and integrates them, creating a consistent, comprehensive view of how Lean can be applied to software development. These perspectives are:

Lean Manufacturing from Toyota (from Taiichi Ohno of Toyota)
Lean Thinking (from Womack and Jones’ work)
Lean Software Development (from Mary and Tom Poppendieck)
Lean Product Development System (from Toyota, as described by Michael Kennedy)

The course centers on how to create a fast, flexible flow of customer value-add. Principles of Lean that facilitate this are:

Eliminate Waste
Create knowledge
Respect people
Build quality in
Defer commitment
Deliver fast
Optimize the whole

The course teaches how to manifest these principles within the context of software development as product development. This is one of the distinctions of this course over mere agile training. Agile project management focuses on managing a single project and perhaps coordinating several projects together. However, true software development should be focused on the products these projects relate to. Selecting products, scheduling projects for the products, balancing product loads, are business perspectives that Lean addresses while agile methods do not. The focus of this course is on the mindset of Lean and the Lean-Agile Software Development process. The issues of architecture and how to evolve designs is only dealt with at a superficial level.

P.S. I found out about Net Objectives through subscribing to their Lean-Agile Straight Talk podcast. If you want to learn more about how Lean and Agile work together, visit their site. But just promise to come back here to learn more!

Update: If you are trying to implement Agile or Lean in your organization, you NEED this course! Though there are plenty of books on the topics, Alan did a great job of blending various experts and ideas out there and be able to understand the big picture. This isn't your typical training course however. We were able to have a lot of discussion among the group about our own experiences so far. Alan, being an Agile/Lean coach as well as trainer, provided a lot of good ideas for us to take back. It was like getting free consulting/coaching along with the cost of the course (which, by the way, at $1000 is a fantastic bargain). Check their web site for more details on the next courses as well as other courses in the area of Agile.