There is a book review of “Becoming Agile” by Smith and Sidky on Slashdot.  I haven’t read the book (yet) so I can’t comment on the book nor on the review.  However, I did want to comment on the comments of Slashdot users.  Their experience with agile methods seems to be terrible.  Either that or they are incredibly ignorant and have pre-judged agile.  Since I know that (most) Slashdot users are pretty intelligent, I’m going to assume that they have mostly just had really terrible experiences with agile.

The Agile Manifesto values “Individuals and Interactions” over “Processes and Tools”.  Many of the comments were about agile being used as a cudgel to beat teams into submission.  No matter what anyone says, this is not agile.  This is perverted agile or “Pervagile”.  Pervagile is common.  Scrumbutt is one form of Pervagile.  Waterscrum is another form of Pervagile.  Scrummerfall is yet another.  But there are many other forms as well: the Pervagile Sweatshop where teams are forced to meet arbitrary scope in one week deadlines, the Pervagile Common Room where people on many different projects are forced to work in an open space, and the Pervagile Silo Team where only developers are doing agile and everyone else is in their normal functional silos.

On Slashdot we see some interesting comments like this one:

So we’ve gone from over-designing systems to under-designing systems.

How about right-designing a system based on the complexity of the scope and the key personnel involved?

Is that crazy?

No, it’s not crazy, and that’s what agile is trying to help us to do.  Pair programming, test driven development, potentially shippable software, continuous integration, agile modeling are all agile practices that help us “right-design” a system.  So this person must have experienced a team doing Pervagile Minimum Discipline where all good practices are not just done in small bits along the way, but actually ignored.  I’m not sure why they ignored doing good incremental design – perhaps someone told them that agile doesn’t require good design skills on the team!

Here’s another interesting comment:

The attempt to write a Python implementation in Python, PyPy [codespeak.net], turned into a death march. The project has been underway since at least 2003 (when they had their first “sprint”), never produced a usable system, and the European Union pulled the plug on funding. But the project limps on. There’s a released version. It’s slower than CPython. There’s supposed to be a “just in time” compiler Real Soon Now. (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.) Six years in on a compiler project, and no product.

The PyPy project is very “agile”. They have “sprints”. They have “flexibility”. They have nightly builds. They have mailing lists and trackers. They support multiple output back-ends. They have about 50 contributors. What they don’t have is a usable product.

Hmm.  Sounds like they’re trying to do Scrum.  But they’ve missed a pretty critical piece: potentially shippable software at the end of _every_ Sprint.  I have no idea why they aren’t able to do that, but I imagine that if they really understood Scrum, they would be in a much different place at this time.  This is a clear case of Pervagile Valueless Deliveries where the team does stuff every iteration, but they don’t worry about delivering valuable results.

So.  Pervagile is pervasive.  That’s clear.

Why is it so pervasive?  There are two parts to this: one, agile is hard and two, agile is mistaken for a silver bullet.

Agile is Hard

Okay, I’m actually being a little dis-honest.  The real truth is that doing agile is extremely, exceptionally, agonizingly difficult (for most people in most organizations).  Why?  Because agile is not just another process to roll out.  It is, as has been mentioned in numerous places, a deep cultural change.  Agile is actually a liberation movement for people involved in software development.  Like most movements, however, it has been subject to corruptive forces.

Agile is Mistaken for a Silver Bullet

Agile is Hard, and therefore it cannot possibly be a silver bullet.  Many executives and managers hear about agile and want to do it in their organization because they have heard the amazing success stories (yes, they do exist – scroll to the bottom to learn about Wildcard Systems).  But what often is not effectively communicated is how much crisis, how much effort, how much radical change went into these success stories.  Here’s a hint: if you think a large organization can become agile in less than five years, you’re fooling yourself.  Even a very small organization should expect at least two years of solid effort before the changes really take hold.  Of course, if you are lucky enough to be starting from scratch, then you might do better than this.

I’m pretty tired of people mis-understanding agile methods.  But unfortunately this is the reality of our work landscape.  I would love to work with a client where the CEO has said something to the effect of “I’ve budgeted 10% of our operations and ten years to do our agile transformation.”  Of course, that’s pretty much a laughable wish.  Unfortunately it’s the reality of the effort involved for most organizations.

Berteig Consulting is thrilled to announce the early release of the OpenAgile Primer, version 1.0, now available for download at http://www.openagile.com/TheOpenAgilePrimer.  This release falls 2 weeks ahead of the scheduled release date of 1 December 2009 thanks in large part to the implementation of OpenAgile itself in the creation of the document.

The Primer is intended as an introduction to the methodology of OpenAgile as well as required reading for the soon-to-be released OpenAgile Readiness Knowledge Test.  Successful completion by individuals of the Readiness Test will result in the award of an OpenAgile Readiness Certificate—the prerequisite for OpenAgile Team Member Certification.

The team wishes to thank all those who have generously contributed to the realization of the first version of the Primer and looks forward to collaborating with many more of you in the future.

OpenAgile public course listings have already been posted on the Berteig Consulting website: http://www.berteigconsulting.com.

We also warmly invite you to become involved in the OpenAgile Community through the OpenAgile Wiki:Community Portal.

We will keep you posted as the work progresses.

To learn more about OpenAgile, please visit us at http://www.openagile.com.

Regards,

The Berteig Consulting Team

Due to popular demand, we have added another Certified Scrum Product Owner (CSPO) training to our listing of courses.  There is an overwhelming need for well trained Product Owners, and we’re happy to take up the challenge. The next CSPO will happen on January 14 & 15 at our office in Newmarket, just north of Toronto.

During this seminar, our Certified Scrum Trainer will teach participants how to do the fundamental tasks of the Product Owner in the Scrum environment.  The attendees will learn:

• how to develop a comprehensive Product Backlog
• competently add value to the Scrum team during the Sprint
• fully understand how Scrum works and their role within the agile environment

With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Certified Scrum Product Owner. After completing this course, attendees of this seminar will be able to create and manage a Product Backlog, work with a Scrum Team to create high-quality software, and use the Scrum framework to build and deliver the right software.  Please refer to our website for a course description and to reserve space for yourself or others on your team. http://www.berteigconsulting.com/CSPOCourseDescription

We look forward to adding value to your team!

If you would like more information contact us at sales@berteigconsulting.com

This summer, Berteig Consulting delivered an intensive OpenAgile training to Infonium, developers of enterprise application software for the Canadian healthcare industry.  Based in Ottawa, Infonium collaborates with Canadian healthcare practitioners to develop innovative software solutions that solve issues that are specific to the healthcare industry. 

http://www.infonium.ca/about-infonium/news/96-news-berteig

Berteig Consulting is proud to be helping Infonium achieve their vision of transforming healthcare across Canada.

Interesting link – the “Learning Manifesto” of OpenAgile: http://www.openagile.com/LearningManifesto

“Learning is the key that unlocks human capacity…”

At Berteig Consulting, we have made some changes to our already well-received Certified ScrumMaster training seminar.  These changes will apply to courses starting in January 2010.

- Our seminar is now a more effective, participatory 2-day seminar giving more value for your time
- The price is now lowered to $995.00 per participant to reflect economic conditions
- We have created a new agenda which is even more practical and more hands-on
- You will experience an improved facilitator/participant ratio with a maximum of 20 participants per seminar
- We have scheduled more locations across Canada to serve you better
- Our preparatory reading material replaces lecture-oriented course content to allow more effective use of classroom time
- The Scrum Alliance knowledge test helps you consolidate your learning of the core Scrum principles and practices
- We now offer high-value, discounted add-ons for coaching and other support to make you even more effective

Why would we make these changes?

All these changes help participants to be more engaged in their own learning, and derive more value from this seminar.  Our seminar, combined with our facilitator’s real-life experience, provides some of the best training value available!  By learning to use Scrum effectively in our Practical Certified ScrumMaster course, you can radically improve the performance and quality of the work of your team and organization!

Register now while spots are still available!

I’ve been researching teamwork lately.  I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”.  I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team.  First stop, Google and a search of “list of teamwork skills”.

Strangely, not much turned up on the first page.  The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site.  So, here’s my adaptation of their list:

Active Listening

Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects.  Active listening requires the ability to not think of your own responses until after a person has finished speaking.  One simple way of doing this is to echo what a person is saying in your silent internal voice.  When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind.  Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.

Questioning

Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model.  Asking questions is easy.  Asking good questions is much harder.  We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question.  For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions.  Instead, saying “I do not understand the reason you did that.  Could you please explain it to me?” can be a much more gentle way of getting to the same information.

Logical Argument

When presenting an idea or position, being able to logically support it is important to exploring the truth of it.  This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion.  Being able to avoid fallacious logical methods is also important.

Respecting

Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have.  This does not mean that you have to let teammates get away with inappropriate behavior.  In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.

Helping

Offering help and actually following through with real assistance are aspects of helping.  When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions.  This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together.  When we help someone, we share their burden.

Sharing

Sharing our knowledge, time, skills or physical resources are all aspects of sharing.  Sharing among team members is focused on those things which will help a team reach its goals.  This is similar to helping except that it tends to be more of a transaction than an ongoing activity.  The transaction is that you give a gift and then the other person uses that gift to meet their needs.  Sharing does not require reciprocity.  If you share something with another person, you should not expect that that person will return the gift at any time in the future.

Participating

It’s probably obvious, but in order to effectively be on a team, you need to participate!  Participation itself is mostly obvious: do work with the other team members.  However, there are also some less obvious aspects of it.  You are not participating when the team is having a discussion, you find it boring, so you check your email.  You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree.  You are not participating in a work team when you are mentally checked out because of a crisis at home.

All of these skills are critical teamwork skills… but there may be others.  Do you think there are other skills missing from this list that are critical for effective teamwork?

http://theagileexecutive.com/2009/09/29/technical-debt-on-your-balance-sheet/

Many people in my CSM classes start by thinking that the ScrumMaster job is easy and can be part time.  Here’s a good article that summarizes why this is not the case, and provides even more useful references.

New to Agile? What Does the ScrumMaster Do Anyway?

We have wrapped up our Summer Special. There are still a few classes scheduled this year that have the discount price, but others have reverted to our normal price. I encourage you to take a look at our course schedule at http://www.berteigconsulting.com/ to see what is still available.

Also, all our future Certified ScrumMaster courses will have a knowledge test as part of the certification process. Please see the Scrum Alliance website for more information at http://www.scrumalliance.org/.