– Tobias

A quote from the website:

“We are in the midst of an economic downturn. People are losing jobs, losing money and having to rethink their priorities. In addition, the whole world of business is undergoing a profound change which is likely to affect the way we work for the remainder of this century, and beyond: mechanical systems are out, human systems are in. In this time of economic uncertainty and shifting paradigms some people will react with fear and panic, clinging on to old ideas and closing their hearts and minds. Others will respond with laughter and ingenuity, seeking and embracing the new opportunities that will arise from the current chaos.”  — WelfareCSM

This program is not about handouts.  I use the term “welfare” in the sense of “something that aids or promotes well-being for the common good; the enjoyment of health and the common blessings of life; exemption from any evil or calamity; prosperity; happiness.”  I am seeking passionate, committed individuals who desire to learn, and broaden their outlook on work and life.  The workshops are open to anyone, and not restricted to people in the IT industry.

If this interests you in any way, please read more at WelfareCSM.  Thanks.

Subscribe to the Agile Thoughts Blog

You can read the post for yourself, here: A Conversation on Agile Long Overdue.

____________________

“…we all safely interpret dangerous things in ways that don’t require us to change our lives.” — Orson Scott Card

I was honored to co-facilitate an Introduction to Scrum session recently for sixty-eight Project Management Institute (PMI) folks, who were all willing and open-minded. Even the ones I had known in past years who were not so open minded to Scrum raised their hands high and proud when asked, “Who is excited to try this in their work?” Within an hour of starting the session, though, I was compelled to stop it. My co-facilitator was introducing the group to Scrum and hands were popping up everywhere. The questions being asked were all some version of “How does this match what I already know?” “So, the product backlog is your requirements document, right?” “You can’t really expect people to sit together. That would never fly where I work.” “I just don’t get what you do without a plan. How will people know what to do everyday?”

When I stopped the group, I asked that they give themselves the gift of learning something new without forcing it into the categories already in their heads. “Perhaps,” I said, “just perhaps you will need new categories to understand what’s being given to you. So rest for now and learn Scrum for the sake of learning Scrum – without relating it to plan-driven project management, without worrying about whether or not it will work in your current situation.”

As I peruse the submissions for the Agile 2009 conference, I see the same tendency in the community as a whole. It’s a fervent desire to map Scrum to something else, something more familiar and, therefore, at least seemingly safer. PMBOK, CMMI, Lean, Kanban, the list goes on.

As the Orson Scott Card quote says, there is something in us that desperately wants to “safely interpret dangerous things in ways that don’t require us to change our lives.” Is Scrum dangerous that way? Absolutely. If you are doing Scrum well it will require you to change your life. You will have to give away your belief that having a checklist makes things run smoothly. You will have to stop chasing the perfect process and, instead, start cultivating your ability to trust the resourcefulness of others. You will cease using line items checked off on a plan as your measure of value. You will face your fears, all of them, about yourself and other people. You will stop making progress and start making products.

If you must map Scrum to something you already know, go ahead. Use that door to come to Scrum if that’s what makes sense to you. Heck, for PMBOK, you don’t even need to do it yourself. Michele Sliger and Stacia Broderick have done a fine job of it for you [ref]. If you come through that door though, don’t stop just inside the foyer. Keep moving. Immediately seek out people who allowed their brains and hearts to expand when they learned about Scrum and go learn from them. Allow the simplicity and depth of Scrum to rock your world and open your mind up to news ways of being in the workplace and getting work done, together. Try on some of the radical practices recommended by good Scrum coaches, even if you think, “Oh, no. I could never…” The practice you have that reaction to is the one you need most. So, do it. Let the dangerous thing into your life and allow it to change you. It’s absolutely for the better.

© Lyssa Adkins, 2009
____________________

Lyssa Adkins is a personal coach, a Certified Scrum Trainer and a PMP.  She authors the excellent cricketwing blog and is the the creator of the well-respected and oft-cited YouTube video The Road from Project Manager to Agile Coach.  Lyssa presents regularly at Agile and Scrum conferences and gatherings, and tends to make friends wherever she goes — look out for her on your Agile journey

Having both CMMI and PMI representation at the gathering was an odd choice, and given the energy and creativity often found at Agile conferences these guys had much to do to impress.  No easy task, especially given the resistance from many (including this blogger) to their very presence. It seems reasonable that when in enemy territory, so to speak, a person would tread with caution.  Fair enough, but reasonable people rarely inspire and that was the case here.  Nevertheless Gregory Balestrero’s talk was not without value.

In describing the work of the PMI Mr Balestrero mentioned that the new version of the PMBok has a chapter on iterative development and incremental delivery.  Bear in mind that IID has actually been practiced in software companies since the 1970s.  That it has only come to the attention of the PMI recently is odd, to say the least.  IID is not the same as Agile, of course, it is one small part.  Still, progress is progress, and credit to the speaker for seeking alignment between Scrum and PMI values.

The one thing that jumped out at me from the talk was Mr Balestrero’s announcement that since he took over as CEO of the PMI seven years ago the organization has become more focused on value.  This is good news, as Agile is, and has always been focused on value, so we can all see alignment there.  Of course, the question this raised for me was “what was the PMI focused on before that time?”  I decided to ask.  As there was limited time in the session for questions I waited to speak with Mr Balestrero after the keynote was complete.  With all the powerpoint events of the morning I was hungry for some actual dialog.  In the event my question turned into an hour-long conversation about the nature of management.

Raffi Simonian (CSP), Alan Cyment (CST), Jesse Fewell (PMP) also took part in the discussion.  Raffi’s particular interest was on how a CSP could fast-track his way to becoming a PMP, given that there was some cross-over of skills, and to their credit the two PMI representatives didn’t shoot this idea down, but instead offered Raffi a number of direct contacts with which to further explore the idea of how CSP and PMP could dovetail.  The gesture offers potential for open dialog, for collaboration.  All good.

— As an aside, Gregory Balestrero publicly congratulated Raffi and his co-worker Anu on the excellent PMO set up at their organization, saying it was one of the best there was.  In fact, Raffi and his team have been slowly working over the past few years to remove this same PMO as it is actually considered an impediment.  —

Back to my question, what was the PMI focused on before it decided to focus on value?  Gregory Balestrero explained that the PMI was originally set up to focus on value (of course it was, what else would its purpose be?) but over the years lost that focus and became transaction-orientated, focusing on delivering certification to the individual rather than supporting organizations in successful outcomes.  This seems to have resulted in a large group of people with impressive knowledge of how to manage projects, but perhaps with some loss of focus as to why they needed to do this.  Seven years is a long time, and many of us in this community do not yet see that focus on value over certification.  Big ships take a long time to turn around.

Mr Balestrero went on to say that when he joined the PMI he asked the question “do we need project management?”.  Good question.  Apparently the answer was “Duh, yeah!”  I challenged that answer.  Perhaps the “duh yeah” applies when the processes we use cry out for management.  Upfront requirements, definition, work-breakdown structures, dependency charts, critical path analysis, efficient assignment of resources… all of this needs to be managed.  Sure.

But what about an agile process?  I suggested that management, as we know it, is inappropriate, and that instead projects need support and guidance through a process of visioning, reflecting, facilitating and inspiring.  Does the PMI teach that, I asked.  The answer was vague.

I felt that Gregory Balestrero didn’t understand Scrum beyond the concept of iterative development and possibly collaboration, so in the short time we talked Alan, Raffi and I introduced some of the underlying values of Scrum to him.  He listened (he appeared to listen).  What if we took away the names PMI and Agile and Scrum, I asked, what if we went right down to underlying values and principles: openness, trustfulness, visibility, courage, self-organization, collaboration, beauty, inspiring visions… early delivery of working software.  Are we seeking the same thing?

I think this is a question that Gregory Balestrero will need to consider if he is serious about PMI and Scrum collaboration.  The sense I had from our discussion is that perhaps he will.  Time will tell.

Jesse Fewell captured (and captioned!) the discussion.  Take a look.

We tend to think of oppression only in its deliberate form, when used as a weapon to subdue the conquered or to quell the sense of unrest and the spirit of uprising in the lower classes, but oppression exists in many forms, and does not only affect poor, underprivileged people. We can observe many levels of oppression in large organizations today, amongst middle class, well paid professionals.

As an example, consider cubicle culture, so ingrained in our idea of how people work in the software industry — yes still, even after 10+ years of Agile.  Isolating someone in a cubicle is an act of control, a way of ensuring compliance.  Prisons throughout the world use the concept of solitary confinement as a form of punishment — some would say punishment bordering on the ‘cruel and unusual’, or even torture: it is so deeply unnatural for people to be isolated from one another.  One’s imagination does not have to be stretched far to see the similarities between a corporate cubicle and a one-man prison cell.  Without the support of their fellows an individual is more vulnerable to suggestion, and more likely to tow the line.  Is this the deliberate intention of a cube farm?  Possibly not, but it is the outcome.

But it goes far beyond office layouts.  Games of power are played out daily — often with great zest within the upper echelons, but with ever-dwindling willingness as we move down towards the grass roots of an organization. The oppression that takes place is sometimes conscious, but more often is “an unintended outcome of social arrangements”, and manifests itself in the phrase “it’s just the way we do things around here”.

Such oppression is usually hidden beneath the niceties of corporate behavior, beneath so-called socially acceptable norms.  At its most insidious it hides beneath a facade of ‘fun’, ‘teamwork’, ‘community spirit’ and other such fashionable buzzwords.  In the oppressed people it takes the form of silent compliance, the fear of making mistakes (CYA) and a general sense that it is better to make no decisions than to make the wrong one.  It is better to delay than to act.  The result of this corporate oppression is inertia: it is stagnation. If this oppression is not recognized for what it is, it cannot possibly be surfaced and dealt with. An organization groaning under the burden of such oppression can never be agile, no matter how many nice facades it puts on itself.

As well as oppression at the individual company level, there is the additional fear-based culture across companies of compliance to “standards”, e.g. SOX, ISO 9001, CMMI.  I have twice observed the effort exerted to meet such standards by those forced to comply.  It was a pathetic sight — fearful workers, terrified of making mistakes, outwardly exhausted and inwardly cowering.  I don’t exaggerate.  Others may have a different experience; this was mine.

But who is responsible for the way things are?  The oppressors?  Society?  It would be easy to apportion blame, and carry on the same way.  The reality though is that the oppressed person himself is the culprit.  In a democratic society we have choices.  If we are oppressed (and we are) it is because we choose to live that way.  “There can be no really pervasive system of oppression . . . without the consent of the oppressed.” — Florynce Kennedy

This is all well and good, and a simple two-step solution would be to a) recognize it and b) act differently.  The reality though is trickier.  Too often the oppressed don’t want change; they simply want to be on the other side of the oppression.  That is the ugly reality we live in.  We have all seen individuals rise to middle-management and change behavior accordingly, fitting in to the system and emulating their superiors.  Many of us have seen teams fall apart through infighting — indeed a key part of the Scrum Master training course is focused on dealing with such situations.  Reward systems in most software corporations are based on individual superiority, and to be superior, others must be considered inferior.

Commenting on the syndrome of in-fighting between oppressed natives in colonized countries, Paulo Friere notes “Because the oppressor exists within their oppressed comrades, when they attack those comrades they are indirectly attacking their oppressor as well.”

He goes on to say “on the other hand, at a certain point in their existential experience the oppressed feel an irresistible attraction towards the oppressors and their way of life.  Sharing this way of life becomes an overpowering aspiration.  In their alienation, the oppressed want at any cost to resemble the oppressors, to imitate them, to follow them.”

If large monolithic bodies such as IEEE and PMI are the oppressors in the software industry, then it follows from Friere’s observations that the smaller process innovators, the ones who once kicked back against the style of management represented by these bodies, will now wish to emulate them, to essentially become them. The Scrum Alliance events, for example, are moving from intimate gatherings of passionate people to corporate sponsored events with big-name keynote speakers, in essence becoming identical to all the other mainstream software conferences.  The PMI, champions of the oft-scorned waterfall process, are now being looked to for advice and support.  This isn’t progress, it is regression, or at best circularity.  The spirit of revolution so apparent in the beginning of this movement has all but disintegrated, as we march to the corporate drum.

Where does Scrum fit into a landscape of compliance and corporate emulation?  Quite possibly it will be absorbed back into that culture, watered down, commoditized.  It will be made nice.  And in 20-30 years time a new generation of dissatisfied, disempowered workers will start the revolution all over again.

We all desire change, but evidence indicates we don’t know how to go about getting it in any deep and lasting way.  By recognizing the reality of the oppression we live in, by facing it, acknowledging its truth, perhaps we can shake off the shackles of ingrained behaviors and begin to think and behave in new ways.  And in doing so perhaps we can reinvent the world — or for now, at least the software industry.

Disclaimer: the views I express here do not reflect the views of the Scrum Alliance, nor of any other individual member.  They are my views.  That is all.

The Orlando Scrum Gathering is approaching.  Gregory Balestrero, the Chief Executive Officer of the Project Management Institute (PMI) has been invited, with much fanfare, to be one of the keynote speakers at the event.  I object to this.  Not because I have anything against the man (I’d never heard of him until now) but because I feel uncomfortable with the idea that the Scrum Alliance is turning to the PMI to learn… what?  I don’t know.  After three years of seeking to understand I haven’t yet found a good reason to listen to the voice of the PMI.  This is hard to say as I know it upsets a lot of people.

Inviting someone to do a keynote speech implies they have something important to say, that we need to hear.  Gregory Balestrero, the man, may have something important to say, but Gregory Balestrero the CEO of PMI does not.  The PMI is an outmoded organization which represents, and promotes, a particular way of working now known to be largely flawed.  That the PMI wants to change itself is good news.  That the PMI has an important message for Scrum practitioners is unlikely.

If Gregory Balestrero is interested in learning about Scrum, then have him attend the Scrum Gathering, and have him pay his entrance fee along with the rest of us.  I welcome him there, as I welcome anyone who wants to learn about Scrum.  I have no reason to believe Mr Balestrero is anything other than a lovely man, with a desire to learn new things.  No doubt he is a very smart and passionate man to be where he is today.  Such drive and passion are always welcome in the Scrum world.  I would just rather have him attend the gathering simply as Gregory, not as “the chief ambassador for advancing the profession of project management on behalf of PMI”.  And I have no interest in hearing “powerful messages about the importance of project management in achieving success in today’s global business environment.”  I am tired of corporate rhetoric, and I don’t buy this.

Scrum, as I understand it, has nothing to do with project management, and personally I eschew the term “Agile Project Manager” and consider it an oxymoron.  Ken Schwaber has often made the statement that there is no Project Manager role in Scrum.  Indeed there is not, so why partner with the Project Management Institute?  It starts to feel like compliance to the existing status quo, and appeasement to what is still a very powerful organization, albeit one whose power is threatened.

I have always seen the move to Agile as a software revolution, throwing off the weight of oppression and releasing into a new way of being.  The  tragedy of many revolutions is that once successful the leaders tend towards the same behavior that caused the need for the revolution in the first place.  The oppressed become the oppressors, i.e. they take on essentially the same behaviors because they don’t know how else to behave.

George Orwell characterized this tendency in the novel Animal Farm, an allegory for the Russian Revolution and subsequent events.  By the end of the book, the revolutionary leader, Napoleon (a pig, by some charming coincidence) is walking on two legs, dressing in human clothing and selling his best friends out for horse meat.

Why does the Scrum Alliance want to work with the PMI?  Let me be clear: I see absolute value in working with those individual members of the PMI who care about Scrum, but I see no value in working with the organization.  It has some influence today, but that influence is waning in the light of Agile.  I say leave it be, let it die.  Let’s all seek entirely new ways of collaborating and advancing our professional skills.  Giant monolithic institutions representing “the interests” of their members may not be the way of the 21st century.  Maybe small is better.  I sincerely hope that the Scrum Alliance won’t scale to PMI proportions.  I’d like to see it splinter instead, into small passionate, self-managing groups each with a slightly different agenda, and different interests.

I feel oppressed not so much by the PMI, but by monoliths in general; they are, by definition incredibly heavy and immovable.  And I feel uncomfortable with the burgeoning relationship between the PMI and the Scrum Alliance, thinking I’d rather not dress up as a farmer.
_____________

In part two of this post I’ll explore the nature of oppression and look at how raising awareness of this mostly hidden syndrome may be useful to help us identify problem situations with more clarity, and thus change our behaviors and thinking.

I have written the first post: #1: Helsinki, January 2008. All subsequent entries will be available on the Danube blog, which also contains great writing from many excellent Scrum trainers.  Check it out.

I’ll still be writing here from time to time, so don’t desert this space just yet.  My blog life is reflective of my home life: I am somewhat rootless these days, wandering and wondering…

I am writing here to process an interaction which I found unsettling.  There are a few guest speakers here from the USA including Mary Poppendieck and Micah Martin.  It surprised and disappointed me that both Mary and Micah used the final panel discussion of the conference to publicly denounce Scrum as “insufficient for building software”, and deride the CSM certificate as being useless.

Micah bemoaned the fact that the last Agile conference (in Toronto) had been “taken over” by Scrum Masters, and made the comment that teams “did not need a Scrum Master to tell them what to do”.  Luckily many attendees at this event were differently informed than Micah in their understanding of the role.  I talked quietly off-panel with him afterwards to explain that 1) I agreed with him: teams do not need Scrum Masters to tell them what to do, and 2) that he had completely misrepresented the role.  Micah was willing to listen and hear.  In his other panel comments Micah said many memorable and insightful things about software craftsmanship that I happily agree with.  In fact, I think that he and I are 90% aligned in our thinking.

More disturbing was Mary Poppendieck’s attitude towards Scrum.  I would actually describe it as hostile, and when I tried to engage her in dialog about it later at the reception she (unlike Micah) seemed unwilling to listen but chose instead to talk at me.  She claimed again that Scrum was insufficient, that it had the wrong roles, that it targeted dysfunctional companies (well, yes!), and that she disliked it because she spent 90% of her time cleaning up after bad Scrum implementations (she then went on to say she never worked in dysfunctional companies, which seems somewhat inconsistent with the earlier clean-up statement).

Then Mary singled out Jeff Sutherland as an exception, claiming he doesn’t do Scrum the way everyone else does, as he enforces all necessary software development practices, has a lead engineer in the team, does architecture up front, and has a Scrum Master who codes 90% of the time. In essence he runs “the Toyota process”.  I am not stating facts here, just repeating the gist of the conversation.  I concluded that in Mary’s opinion only Jeff Sutherland (and those trainers who work directly “for” him) understand what Scrum is, or ought to be: i.e. Sutherland-Scrum rather than Schwaber-Scrum.  The rest of us are charlatans.

It was a very uncomfortable, and one-sided conversation, and a little surreal given the joy and openness of the conference up to that moment; it seemed that every question or comment I offered was taken as an attack.  I was seeking a crack in the wall of resistance to initiate a dialog with Mary, but I did not find one.  Dave Nicolette, also present at the table had more luck, perhaps because he is not a Scrum Trainer.  Dave actually did a skillful and patient job of attempting to offer some balance to the conversation.

Disparaging and mocking comments about Scrum and CSM certification were also made during and following the Agile2008 conference in Toronto by some of the key speakers.  There appears to be a trend here, one which I find ugly and sad.  It is no surprise when people new to Scrum misunderstand it — it is difficult to fully grasp its full implication, but it is very surprising and disturbing that people deeply involved in the Agile movement show such a lack of understanding of the true nature of Scrum, to the point where they feel the need to publicly denounce it.

As I thought about all of this later in the evening, I recalled a comment Mary made during the panel today, immediately following my suggestion that reflection was essential and teams need to run regular retrospectives if they are to improve.  Mary enthusiastically retreived the microphone from me and said something like “as the voice of opposition here I have to say that I don’t agree with Scrum retrospectives.  I have my teams meet for a couple of hours every week to focus on process improvement, using ‘plan-do-check-act’ and other scientifically proven process improvement formulas” (I am paraphrasing).

It occurred to me that maybe Mary was a process-focused person, and was not considering, or particularly interested in human factors.  Retrospectives in Scrum (for me, and many I know) begin with individual improvement, personal development if you like.  Good process follows.  Perhaps this is a key difference between Lean and Scrum: Lean is about efficient process; Scrum is about effective people.

I am sure the preceding statement will call forth loud objections, but I am grasping at straws here, trying to make sense of why someone as intelligent, experienced and well-respected as Mary Poppendeick would need to publicly disparage a beautifully elegant Agile framework proven to be so successful for so many organizations.  It doesn’t make sense to me.

Why is Agile Software Development becoming a competition for some?  Why must Scrum lose for Lean to win?  This is not the presidential election.  We are all seeking the same goals, and it is the diversity of thought, the rich, chaotic mix of ideas that will help us achieve those goals.  There is no “one truth”.

I’d love to help get the focus away from competition and back onto collaboration.  If you have any suggestions toward this end, please add your thoughts here.

N.B. this blog post naturally represents only my perspective.  It is a gut response, wholly subjective, and therefore not “truth”.  I’d be happy for anyone else present during the panel discussion or the following reception, especially those mentioned by name, to add their own perspective.

This was the second year at Agile that Jim York and I collaborated on an Improv-led session.  In our work as coaches and trainers we have found the improv mindset to be an essential tool for Scrum teams, moving them swiftly towards deep and productive collaboration, without fear.

The session has been written up for the Agile2008 site and is available to download as a PDF from here: Operating on the Creative Edge — PDF.  In the document we describe many (not all) of the exercises we ran, and describe briefly the purpose of the work.

Both Jim and I have trained with the Improv artist and actor Matt Smith.  Here is an extract from Matt’s web site, where the parallels with what we are asking from Scrum team members can clearly be seen.

“I studied improvisation so that I could become funny on stage in front of people. What I learned from the training was quite different. I learned to: listen, honor, be accountable, be positive, move things forward, stay present, reincorporate, empathize, reflect.  And I learned to surrender: my agenda, negativity, judgment, control, anticipation, pre-determinate listening.  More than readying me for the stage, it improved my life!”

If you live on the NW coast of the USA I highly recommend you attend one of Matt’s workshops.  They are mind-altering.

_____________

A word of warning: although the PDF document may be of interest to many, it is highly advisable you do not attempt to run the exercises described unless you have yourself experienced them.  Words are too easy to misinterpret.  Only by being in these exercises can you truly comprehend them.  If you are interested in introducing these ideas to your organization contact Jim or me directly, or better yet contact Matt Smith.