Archive for the ‘Scrum, XP and Lean’ Category

Comparison of OpenAgile with Scrum

Monday, February 1st, 2010

OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?

The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.

OpenAgile is an improvement over Scrum in the following ways:

  1. More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
    applicability over a larger range of team sizes from a single individual on up.

  2. Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
    Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.

  3. Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
    environment. OpenAgile also provides a framework to include additional types of work beyond these five.

  4. Improved role definitions based on extensive experience.

    1. There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).

    2. There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.

    3. The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:

      • is not responsible for team development
      • is not necessarily a single person, nor is it a required role
    4. The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:

      • is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
      • is not necessarily a single person, nor is it a required role
  5. Integration of principles and practices from other methods. Two examples suffice:

    1. From Crystal: creating a safe work/learning environment.

    2. From Lean: build quality in, value stream mapping, root cause analysis, standard work.

  6. OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
    unsuitable for operational work and general management.

  7. The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.

  8. Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
    OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.

  9. The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.

  10. Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).

  11. Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
    included below.

Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.

Comparative Glossary between OpenAgile and Scrum

OpenAgile Scrum
Cycle Sprint
Cycle Planning Sprint Planning and Sprint Review
Team Member Team Member or “Pigs”
Process Facilitator ScrumMaster
Growth Facilitator Product Owner
Work Queue Product Backlog
Work Queue Item Product Backlog Item
Cycle Plan Sprint Backlog
Task Task
Work Period Day
Progress Meeting Daily Scrum
Learning Circle w/ steps Inspect and Adapt”
Delivered Value Potentially Shippable Software
Stakeholders Chickens”
Five Types of Work:

New, Repetitive, Obstacles, Calendar,
Quality

- no equivalents -

User Stories, N/A, Impediments, N/A, N/A

Consultative Decision Making - no equivalents -
Sector / Community - no equivalents -

References on OpenAgile:

http://www.openagile.com/

http://wiki.openagile.org/

References on Scrum:

http://www.scrumalliance.org/

http://www.scrum.org/

“Agile Software Development with Scrum” - Schwaber and Beedle

“Agile Project Management with Scrum” - Schwaber

“Scrum and the Enterprise” – Schwaber

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile/Pervagile on Slashdot

Monday, November 16th, 2009

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.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

New Certified Scrum Product Owner training in Toronto added to calendar

Wednesday, November 4th, 2009

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

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Why try to be good?

Monday, June 29th, 2009

What motivates human beings to do the right thing?  To do good deeds, to be truthful, to be kind, to be helpful, to try to make the world a better place?  First of all, we have to realize that everything we say and do has an actual, real effect on our environment for better or for worse.  Every time we help someone, or tell the truth, it actually makes the world better in some small way, just as when we lie, cheat, steal or speak unkindly to someone, no matter how small the affront, we actually make the world worse.  In fact, our thoughts, words and actions can really have only one of two basic effects on the world – they can make it better or make it worse.  Period.

There are some powerful cultural forces in our society, most obviously the constant stream of materialistic propaganda through various forms of hypnotic media, that influence the way we perceive our ability to contribute to the betterment or worsening of our environment.  The basic message is that individuals can’t affect any real fundamental change in society (i.e., their environment) and that the best any of us can do is to change our position, rank or class within the permanent structures of our society.  Therefore, “only the strong survive”, “get what you can while you can” and the “pursuit of happiness” have become not only slogans that we live by, but conceptions of human nature that have constructed our social reality.

For example, the concept behind “the pursuit of happiness” is that happiness is something external and fixed that a person has to find somewhere “out there”.  Embedded in this “right” is the implicit message that “average” individuals and groups do not have the potential to exert influence on, and contribute in any meaningful and lasting way to the shaping of the prevailing social order.  Thus, there is always a better neighborhood to live in, a better employer to work for, a better school for your kids to go to, etc.  It disempowers us all from thinking that we can get together and do something right now about our immediate reality.  ”Don’t even bother”, it says, “you won’t be able to change anything anyways – you’re wasting time, effort, and worst of all – money!  Better to lie just a little, cheat just a little, step on your neighbor just a little in order to protect your own little piece of turf.”

Understanding the truth about our reality – our potential to contribute to the betterment of the world – is what will actually begin to motivate us to be good – that is, the fact that our good thoughts, good words, and good actions can and do make the world better.  ”Better” becomes not merely an external pursuit that we fight to get our little piece of; rather, it is an organic, sembiotic process of growth.  For one thing, it requires vision: What would the world be like, for example, if everyone always tried to tell the truth?  Would it really be so bad?  Would human affairs come to stand still?  Would the economy crumble?  Or would it, rather, begin create something new… something better?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

How the Agile Community Can Contribute to the Betterment of the World

Friday, June 26th, 2009

On April 1, 2009 Scott Ambler posted on his blog “a parody of a very serious ethical lapse within the agile community.”  It was an April Fool’s joke – a fake ad for a 2-day agile certification course called “SCUM Certified™ Agile Master, or more colloquially SCAMmer”.  The mock-ad states that

We want to be perfectly clear about this, by taking this ‘certification course’ what we’re certifying is that you attended the course.  It is your choice (nod nod, wink wink) if you wish to present yourself as a professional SCAMmer.  Yes, about 99.8% of course attendees choose to do this, why would you take the course otherwise?

This piece will not be a direct response to Ambler’s joke.  That would be…well, rather foolish.  Instead, what I intend to address here are the concerns raised by his “Parting Thoughts”, which take on a more serious tone and seem to be getting to the heart of what’s really (and understandably) bothering him.

In his “Parting Thoughts”, he states “I believe we can do much better.”  He is referring, of course, to the “ethical lapse” jokingly addressed by his mock-ad.  He goes on to say:

My hope is that this joke has made you step back and think about what’s going on around you. Being a “Certified X”, whatever X happens to be, implies that you’ve done something to earn that certification. If you’ve done very little to earn a certification then at best that’s what your certification is worth: very little.  If you’re involved in a questionable certification scheme, regardless of whatever justifications that you tell yourself you have still shamed both yourself and your so-called profession.  If you turn a blind eye to people who claim to be “certified masters” after doing almost nothing to earn that certification then you too are complicit: As Edmund Burke first said, all that is necessary for the triumph of evil is for good men to do nothing.  I invite everyone in the agile community to read Ethics for the Real World and to stand up and show some integrity.  Enough is enough.

What Ambler seems to be saying here is that for those of us in the agile community to “do much better”, what we really need is to do something about “questionable certification schemes”.  The “something” he proposes is that we should not “turn a blind eye to people who claim to be ‘certified masters’ after doing nothing to earn that certification”.  What he then prescribes to all of us in the agile community is to read a book and to “stand up and show some integrity”.

So I decided to take the challenge… sort of.  What I mean by “sort of” is that I didn’t read the whole book; rather, I followed the link to amazon.com and read the first chapter entitled “Almost Ethical: Waking Up to Compromise”.  I think I got it.

So, let’s say that we can all agree that integrity is a good thing and it would be a good if everyone’s actions were always distinguished by integrity and uprightness.  At the same time, let’s assume for the sake of this blog that we can also all agree that we live in a very complex world that constantly presents us with situations that make it very difficult to live up to such a standard.  Perhaps we may also all agree that in many of these situations, we often fail to live up to the standards of integrity that we espouse and would like to see established in the world.

In Ethics, Howard and Korver identify that “Lying, a form of deception, plays a central role in ethical compromise” and that lying “appears… commonly in ethical thinking.”  They point out that “Most of us are practiced liars.”  They offer the results of one study as evidence of this:

147 college students and community members kept daily diaries of lying.  The students reported telling an average of two lies per day, the community members one.  None thought their lie telling was serious (although none of them asked the people they lied to).

They go on to make the following observations:

If we hold a video camera up to our lives, we may be astonished at the incredible sweep of lies on the landscape.  If we pan that camera to view the lives of others, we see disingenuousness everywhere.  Imagine being in the shoes of the following people, whose stories are based on real events:

  • You are a consultant, and you know your bid for phase one of a project, $300,000, will turn off your client.  You could bid $200,000, knowing your client will soon agree to the extra work and expense anyway.  You are tempted to understate the cost.
  • You are a young engineer, and you can’t get a software test to run as specified before an industry trade show.  Your manager urges you to run past tapes of the test at the show, pretending that it is a live test.  You are tempted to go along.
  • You are an entrepreneur seeking money to fund your new start-up.  You know venture capitalists chop revenue forecasts by 50 percent.  You are tempted to inflate your revenue forecast by a factor of two to compensate for the expected discount.

Whether or not you’ve ever been in these situations, you no doubt have been in similar ones.  Every time, you have probably had at least one very good reason to compromise – and at times you did.  You lied.  You may feel uneasy about it.  You may even be haunted by it.

But you shouldn’t feel alone.  Using compromise as a helping hand in life has a storied, if seamy, tradition.  Even revered leaders lie routinely…

No doubt, subsequent chapters of this book offer helpful advice about how to overcome the temptations to lie that so many of us so often find ourselves feeling.  What I would like to point out, though, is Howard’s and Krover’s insight that lying “has a storied, if seamy, tradition.”  In other words, lying has become an ingrained, normal and expected habit of our culture.  Temptation is one thing, but breaking out of a culture of lying requires a sea change in human morals, standards and codes of conduct.

Now that the immensity of what we’re actually dealing with when we start talking about “integrity” has become more clear – i.e. integrity is a really hard thing to figure out in a complex world that is really messed up – what can we actually do about it?  In other words, is it futile to try to be a person of integrity in a corrupt world?  The short answer to this question is, unfortunately, “No”.  Just like you cannot be a just person in an unjust world.  A brief example will illustrate this fact:  It is almost impossible for any one person living in North America to be able to guarantee that not one article of clothing that they own was manufactured in a sweat shop or by child laborers.  Indeed, most of us can agree that sweat shops and child labor are examples of flagrant injustice.  By participating in an economy that feeds off of their existence, i.e. paying for goods manufactured under such conditions, we are investing in the system that perpetuates the oppression and exploitation of the people whose survival depends on that system.

Being a person of integrity is equally elusive to being a person of justice.  In order to survive in the jungle, you have to obey the laws of the jungle.  So what is the solution?  What can we actually do?  Is it a hopeless situation, this reality of ours?

Indeed, it is not enough for people to just “be good”.  We must also all strive to transform the social environment, structures and institutions that we are a part of in our daily lives.  In other words, it is not enough to be a “good” person who attacks everything that one perceives as being “bad”.  You can’t just decide that you are going to be civilized in the jungle and complain about all the things that are going to eat you and hope to survive.  You also have to contribute to building the civilization that will replace it, contribute to cultivating a new garden.  You will need to find like-minded individuals and work shoulder to shoulder with them and learn to overlook all of their many shortcomings as they learn to overlook yours.

There is another good book that I’ve been reading:  Beyond the Culture of Contest by Michael Karlberg, Associate Professor in the Department of Communication at Western Washington University, whose research and writing focus on the relationship between communication, culture and conflict.  Here is how Karlberg opens his book:

We live in a culture of contest. In western-liberal societies our economic, political and legal systems, as well as many of our other social institutions and practices, are competitive and conflictual.  Surrounding this culture is a culture of protest.  In response to the social and ecological problems engendered by our culture of contest, we engage in protests, demonstrations, acts of civil disobedience, partisan organizing, litigation, strikes and other oppositional strategies of social advocacy and change.

These competitive and conflictual norms have become so ubiquitous that they appear natural and inevitable to many people.  Indeed, conventional wisdom suggests that these social norms are an inevitable expression of an essentially selfish and aggressive human nature.  The prevailing social order, according to this logic, is an inevitable reflection of human nature.  But is a culture of contest and protest really an inevitable reflection of human nature?  Or is it possible that human beings have the developmental potential for either adversarial or mutualistic behaviour? Is it possible that human culture, rather than human nature, determines which of these potentials is more fully expressed?  Is it possible that the prevailing culture of contest and protest cultivates the former rather than the latter?  And if so, what are the implications?

It seems that by taking Ambler up on his challenge, that is, in trying to figure out how to “stand up and show some integrity”, some initial conclusions can be drawn:

  1. Lying is a big, complex problem – a central part of our culture.
  2. You can’t stop the problem of lying by pointing fingers.
  3. Lying is a social problem engendered by a culture of contest – a social norm that is so ubuiquitous that it appears natural and inevitable to many people.  Many would even believe that it is an inevitable expression of an essentially selfish and aggressive human nature.
  4. Overcoming such a powerful cultural norm is not as easy as getting everyone to just read a book or attend a course.

I hope that everyone who reads this finds it to be an attractive invitation to participate in a mutualistic discourse on how we in the agile community can find ways we can work together to contribute to building a better world – a world characterized by integrity, uprightness, justice, truthfulness, prosperity and joy.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

ANN: June Agile Software Engineering Practices

Monday, May 25th, 2009

Isráfíl Consulting Services is pleased to announce our upcoming:

Agile Software Engineering Practices Courses (2 day)

Software Developers, Technical Architects and Lead Developers for teams that currently use or are intending to use Agile methods such as Scrum, Extreme Programming or OpenAgile will benefit from attending this course.
After completing this course you will:

  • increase your development productivity
  • be familiar with basic disciplines to create well-tested, defect-free code
  • be able to integrate successfully into Agile teams
  • understand what makes healthy, maintainable code
  • receive a Certificate of Attendance
  • receive $100.00 discount on a 3-day Scrum training and certification course by our partners

Available Classes:

  • 2009-06-22: 2-day Agile Software Engineering Practices – Ottawa, ON $1450.00 CAD [16 spaces]
    • Register by June 1 and get the early-bird price of $1,250.00.
  • 2009-06-25: 2-day Agile Software Engineering Practices – Markham, ON $1450.00 CAD [16 spaces]
    • Register by June 1 and get the early-bird price of $1,250.00.


Register!: http://www.israfil.net/publictraining/registerCourse Details: http://www.israfil.net/publictraining/coursesClass Schedules: http://www.israfil.net/publictraining/scheduleFor more information, please e-mail us at: training@israfil.net

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – PMP? ScrumMaster?

Thursday, March 19th, 2009

PLEASE NOTE: This stream of notes does not reflect everything said in this session which was very discussion-heavy.

50k+ registered agilists – what about the unregistered?

Project Managers are the largest segment (18%) of agilists

CSM is a distinguishing designation for PMPs

How to mature the certifications – team members, etc.

Everyone wants it

PMI is responding to this because it has to.  Richmond chapter signed a collaborative agreement with the APLN, this is happening in other places as well.

People asking lots of questions.

IT Telecomm PMI Chapter playing a large role in building bridges.

PMI Global Congress in 2008 had 5 agile presentations that were all very popular.

PMI Agile group.

What gaps are there?

Shu-Ha-Ri progression:
Study under a master the “one true way”.  Then try many variations.  Then understand the principles and “the Way”.

Tension for agilists – transition.

Project/Product/Program manager vs. ScrumMaster and Product Owner – no set definitions.

Worried about hiding behind process…
Project Management is a scapegoat
Agile is a scapegoat
Both are because of human dysfunction
Mac vs. PC = Agile vs. PMI – camps based on labels
Moves us away from pragmatism to fundamentalism

Certifications:

CSM -> Scrum -> Agile Thinking

The CSM is the gateway to agile thinking

PMP -> Project Management -> Tools

How do we move people between PM and Agile?

Fundamentalism in Scrum – wrongness of not doing agile.

Not adapting Scrum to reality.

Agile is about truth-telling – different flavors of agile do this a little differently.

The Project manager often has multiple roles – this hides the truth.

The truth is necessary to successful projects.

Scrum focuses around an objective – e.g. making money.

Would it help if the PMBoK had explicity added an agile component?

PMI like IBM – when the IBM launched a PC, then it was okay for the corporate environment to use PCs.

Differences b/w PMBoK and Scrum are more about who, how and why, but not so much about what.

In most organizations, there is a customized “one way” and it is this that is difficult to change, not so much the PMBoK.

Some fundamentalism in Scrum: if you aren’t doing it right, then you are hiding dysfunction – not because Scrum is the one true way to do delivery, but because it is a way to do learning.

Keep my job!

Get agreement around values and principles. – do no harm -

How do we save the world?  Top down?  Grassroots?  Viral?  Not forced!  Building on success!

Attraction vs. promotion.

Not enough of us!  Lots of cultural inertia, crossing the chasm.

Not transforming people despite themselves.  You can’t transform someone else!

False dichotomy b/w execution and transformation.

Learning vs. dysfunction.  Example of Toyota making 1000s of improvements every day.

PMI is about advancing the profession of the project managers.  Therefore it is incumbent on the PMI to bring Scrum in because it works!!!

It needs to get it into the PMBoK

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Beta CSM Exam

Tuesday, March 17th, 2009

This afternoon I took the Beta version of the knowledge exam for the Certified ScrumMaster credential.  I’m not allowed to provide any details on the questions, but I will provide my impressions.

I’ll start with a story.

Microsoft Certified Application Developer

About six years ago, near the end of my career as a technical contributor, the company I was working for, Solution Architects (who still have my profile on their “people” page), decided that I should become a Microsoft Certified Application Developer.  At the time, I was doing .NET development and I had a long background in Java and Objective-C development.  The approach we decided on was for me to go to a “Boot Camp” where I would be immersed in all things .NET and after nine days of solid training, write the Microsoft exam.

I arrived at the Boot Camp (which was very much a outdoorsy camp environment) quite excited.  I got a room for myself, and it looked like I would be treated very well.  One the first day of classes, the instructor gave us some strong advice: come to class, and then in all your spare time, do the practice exams and study them hard.  I was a bit baffled by this.  We were also given the huge Microsoft Press books to study for the exam (I kept them for a few years, but recently got rid of them).  My first night I studied the books and my notes from class.  To be frank, the instructor spent most of the time going over exactly what was in the books and giving us all a little time on computers to do the “exercises” in the books.  Instruction was really limited to rote recital of the book content.  Any time someone would ask a question that was in any way deep, the instructor would simply redirect with another reminder to study the practice exams.

The second night I decided I would try the practice exam since the first of three real exams was in the afternoon of the third day.  It was fairly simple multiple choice test questions.  I went through all the questions, made sure I found the answers for ones I didn’t know in the books or in my notes, and then after I had done a once-through, I did a quick second pass.

And then, the next day, I took the real exam.  I was utterly, completely shocked.  The real exam was exactly like the sample exam.  The only difference was that the word problems change the names of the fictional people and companies used in the problems.  The structure of the questions was identical.  The answers – including the ordering of the multiple choice answers – were exactly the same.  And of course, it was a breeze.  Anyone could have passed.  In fact, it was completely unnecessary to attend the classroom training part.  I was extremely dis-illusioned.

Why do I mention this experience with a certification exam?  Simple: it has made me extremely sceptical of exams.  They simply cannot measure any level of competency.  They simple measure people’s ability to pass exams.  And since there are many fair and unfair ways to do that, exams are not relevent.

Now I will say that I have changed my mind just a wee bit about this… but that’s a topic for a completely different blog post.

So, when I heard that the Scrum Alliance was going to add an exam to the CSM certification, I felt that it was a waste of time, and probably would encourage all sorts of bad behaviors.  I still think that.

The Beta CSM Exam

Okay.  A few facts about the exam.  It was administered in a room in the convention center here in Orlando.  There was a registration desk and when you sign in you are given a password.  You then go to a workstation which has Internet Explorer running pointed at the exam site.  The exam has bookends: at the start an experience self-assessment that is used to help interpret the exam results, and at the end a satisfaction survey.  Throughout the course of the exam, you are able to comment on the questions.  These bookends and the feedback along the way are a great way to help improve the exam and I really like that.

As I mentioned, I am not allowed to discuss the details of the questions.  I will make some general comments about the questions.  Some questions are about Agile, some are about Scrum principles and some are about Scrum practices.  Some are fairly standard fact-based kinds of question like: what are the roles in Scrum, while others are more scenario-based question like: you are the ScrumMaster and X-bad-behavior is happening… what do you do?

There were 99 questions in total and I was told that it would take approximately one hour to go through the questions.  Now, just so you know, I normally do _really_ _really_ well on multiple choice exams, and I normally complete them extremely quickly.  I read fast, and my mind seems to be able to eliminate incorrect options almost subconsciously.  So, for this exam, I completed it in 35 minutes including the time it took me to comment on about a third of the questions.  If I hadn’t been commenting as I went, I estimate it would have taken me about 20 minutes.

How Did I Score?

Well, I got 84%.  Not bad.  The summary page of the exam said this was a “mastery” level.  I should explain why I didn’t score higher (after all, Certified Scrum Trainer (TM) Mishkin Berteig should be able to do 100%!!!).

I decided before I even started, that I would answer the questions as if I was a “perfect” student of my own training.  In other words, I would deliberately get things wrong if I taught them differently than the “right way” that the question implied.  As well, if I didn’t cover a topic in my training, I would do a best guess putting myself in the shoes of someone who had attended my class.  There were two broad topic areas that I don’t teach about that showed up: Product Vision and Release Planning.  As well, there were a few topics that I teach slightly differently: Scrum Team membership, burndown charts, and Sprint Planning/Sprint Backlog Tasks.

Apparently, despite these differences, a student of my class would do pretty well on the exam.

The Problem

When I first became a Certified Scrum Trainer (no TM, this was before the existance of the Scrum Alliance), Ken Schwaber had a clear policy that as a trainer I was encouraged to integrate into my training materials and approach things that I had discovered through actual practice about Scrum.  I loved this.  It meant that Scrum was not a Canonized Body of Knowledge, but rather a living framework for doing excellent work.  When we put in place an exam like this, it changes the nature of Scrum.  Is this good or bad?  I think it has aspects of both.  The clear down side is that it will have the tendency of freezing Scrum which might make it less relevent.

Another problem is more personal: as a trainer, there will be clear pressure for me to teach to the exam.  If a student of mine goes and does the exam, and fails because (in part) I have taught things differently than what is on the exam, then does that mean this person can blame me?  Sure!  Why not?!  So then I am faced with a problem: do I teach what I know works or do I teach what I know will be tested?

Solution

There is a simple way to avoid this second problem and in fact to mitigate the first problem at the same time: the exam should be taken before taking the CSM course.  The exam is clearly based on the reading materials: Agile Software Development with Scrum and Agile Project Management with Scrum.  Then, if people don’t pass the exam, they can blame only themselves for not studying these excellent books deeply enough.  And, it will simplify training since as trainers we will know that people coming into the class are already _knowledgeable_ about Scrum.  We can then teach our variations, see the dynamic of people in the class, and offer Certification based on that.

This solves the trainer’s dilema easily and obviously.  What is not so obvious is that it also helps prevent Scrum from ossifying.  The Certification becomes based on living interaction with an experienced Scrum trainer rather than an exam.  The long term effect of this is that people will place less importance on the exam (rightly) and more importance on making a good showing in the course (rightly) and then we have a relationship-based Certification.  Since it is based on a relationship, it can live more easily as an organically changing framework rather than a defined (simple) methodology.

After all: Individuals and Interations are valued over Processes and Tools (Agile Manifesto).

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Open Space Discussions

Tuesday, March 17th, 2009

All the Open Space sessions will be recorded and posted to a web site… to be determined, but I will add the links once they are ready.

Scrum Beyond Software

I arrived late for this one and only caught the final 20 minutes.  It seemed like it was a good discussion.  One person was interested in using Scrum for doing process documentation.  Another person was interested in Scrum for software maintenance.  Of course, I talked about what we are doing with our business using OpenAgile.

Scrum Must Die

Great discussion!  Main concepts seemed to be: Scrum is fuzzy, it is not well-defined, and can we find an abstraction of Scrum that then is applied to many different situations.  The discussion included many specific examples: is the Product Owner on or off the team, is the Product Owner always 1-to-1 with teams, is the Product Owner always a single person, is the sprint burndown done on the basis of hours or points, is the daily Scrum necessary, is the retrospective necessary (yes), is release planning necessary?

Anti-PMI

Vigorous discussion – a little unfocused, but really really interesting.  People making claims and counter-claims about Scrum and PMI (actually PMBoK).  Some interesting distinctions: Scrum as a framework that allows imperfection and encourages improvement vs. PMBoK as a framework that tries to give all the tools (best practices, processes) to avoid mistakes and do things “right”.  I enjoyed this discussion a lot!!!

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Day 1 Summary

Monday, March 16th, 2009

The first day of the Scrum Gathering in Orlando is finished.  I had a great day all-in-all.  I went to 3 and a half sessions, took a nice sun break in the afternoon, and then mingled at the evening reception.

Some observations:

More People Using Agile and Scrum for Non-Software

This was interesting.  When I actually spent time talking with people I heard several times that people were using agile approaches in non-software environments.  One person is working with an oil company to apply agile methods to all project work.  Another two people are extending agile / Scrum into marketing departments.  And one other person was applying agile into the whole organization.

Of course, with OpenAgile, I’m very interested in all this.  I’m hoping that I can organize some sort of group / institute / organization for people using agile methods outside of software development.  If you’re interested, please contact me on LinkedIn or Facebook or any other method you wish.  People seemed to be in general agreement that this is still new stuff, and that they are having to make adaptations to make agile work in these other environments.  After all, not all work is purely creative or problem-solving!

Economic and Recession Fears

Gregory Balestrero gave a talk about the relationship between the PMI and the Scrum Alliance.  I felt that his talk was much more 30000 foot level and that it probably wasn’t quite right for the audience.  The questions people asked at the end seemed much more appropriate for someone who was an author of the PMBoK rather than the CEO of the PMI.  There was a mis-match between presenter and audience.  At any rate, Gregory spoke quite a bit about the economy and the fears people have about it.  He emphasized that this time actually represents a real opportunity for organizations to get better at doing projects by focusing on value.  I couldn’t agree more!

As well, in my discussions with several other individuals who are coaches or run agile coaching businesses, I heard quite frequently that the past few months have been hard on business here in the United States.  One company has actually laid off some coaches.  This is in line with our experience at Berteig Consulting… up to a point.  December and January were slow, and in fact slower than “normal”, but we still did very well in the Dec. to Feb. quarter.  Clearly the Canadian market is still moving well, and there is a recognition that agile and Scrum are a means to help organizations get through these tough times.

One a related note, the resort we are staying in and in which the conference is being held is the Gaylord Palms.  Apparently, bookings are way down at the hotel to the point where they have temporarily closed some of the restaurants in the resort.  Likewise, when my family went to a water park during the day today, some of the rides were closed because there were so few people.  Please remember: this is Spring Break!!!  Clearly tourism is _way_ down.

Reconnecting with Friends and Collegues

I’ve met up with (in no particular order): Tobias Mayer, Alistair Cockburn, Catherine Louis (from Nortel), Sanjiv Augustine, Mike Vizdos, Carole Marks, Mitch Lacey, Jim Cundiff, Gabby Benefield, and probably others that I can’t remember.

I also met for the first time several people.  I hope I can keep in touch with everyone!

Highlight of the Day

Mike Cohn gave a presentation on Leading Self-Organizing Teams.  It was fantastic.  My favorite part of it was his introducing the CDE (Containers, Differences and transforming Exchanges) model.  In this model, self-organization is positively influenced by appropriate constraints on the containers, differences and transforming exchanges among the people who are asked to self-organize.  To explain: containers define in-ness vs. out-ness for participation, scope of work, environment of the group that is self-organizing.  Differences are the variations in the skills, qualities, attitudes, knowledge etc. of group members.  And transforming exchanges are the interactions between group members both amongst each other and with outside groups, where such interactions cause a transformation of some sort: creation of value, sharing of knowledge, new activities, etc.

By using the CDE model, we can diagnose challenges facing an agile team.  Mike Cohn included a number of scenarios for us to use to practice the application of this model.

Looking Forward to Day 2

Hopefully Day 2, which is primarily and Open Space event, will be even more interesting that Day 1.  I will continue to post frequent articles about the events of the day!  Please feel free to ask for more details in the comments… or to suggest that I connect with someone, or to bring up a topic for the Open Space portion.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Ken Schwaber and Alistair Cockburn – You Thought You Knew Scrum

Monday, March 16th, 2009

PLEASE NOTE: these are my own notes based on the presentation – any errors or omissions are my own.

TOPIC: Treat People as Adults

- “we need to X first”… e.g. X=architecture
- – this is a parent-child approach – need to tell someone how to do something
- – does this mean we are not adults?
- – only through direction and planning will we do intelligent things
- Story from “Scrum in the Enterprise” about a “team” of 17 people
- vs. treating people as “resources”
- — banter –
- “Maverick” book

TOPIC: Teach “ask the team” by actually asking the team (in the class).

- teaching by example!  Using the adults in the class to help answer the question

EDITOR’S NOTE: okay.  this is very interesting, but I’m having so much trouble hearing that I’m going to bail on this one.  Instead, I believe that Mike Vizdos at implementingscrum.com is also blogging this session.  I’m sure his notes will be up soon :-)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Mike Cohn – Leading Self-Organizing Teams

Monday, March 16th, 2009

Something wrong with starting late at a Scrum Gathering!

Did this talk before at SD conference at Santa Clara

Think self-organizing teams are fundamental to all agile methods
- people claim: Unified Process is an agile process – but doesn’t rely on self-organizing teams
- Wicked problems: get the right people together, throw them at the problem

TOPICS:

Self Organization and subtle Control – not all forms of control are evil

Containers, Differences and Exchanges Model

Influencing how the team evolves

Premise: self-organization isn’t just locking a team in a room and saying “just do it” – we influence

What is a Self Organizing Team?
- does not mean:
- – the team gets to decide what goal they pursue
- – or even necessarily who is on the team
- – - some self-org teams are given this responsibility

Complex Adaptive Systems
- a dynamic network of many agents
- – acting in parallel
- – acting and reacting to what other agents are doing
- control is highly dispersed and decentralized
- overall system behavior is the result of a huge number of decisions made constantly by many agents
- e.g. QA group
- in a project:
- – sounds like a software project!

Some Examples
- ant colony
- flock of geese
- us right now – self-organized into room, some at front, some near power outlets
- a crowd batched up to get into a concert or sporting event
- – Jimmy Buffet concert – queueing, at the bar, at the beach etc.
- a family preparing, eating, and cleaning up after a meal
- cars and drivers on the heighway
- a software team

Control is not Evil
- was command and control leader before scrum!
- Simple rules or incentives are used to guide or direct behavior
- – “Drive this direction and on this side on the highway.”
- for bioteams, these are provided by nature
- for our teams rules and incentives can be added by managers or leaders… or in some cases by team members
- Generative rules – rules that generate behavior
- Some control is okay

Quote from Philip Anderson, The Biology of Business about Self-organization

Popular to criticize Taylorism – don’t specify exact steps, instead put in place things that guide behavior

(NOTE: slides on website)

Takeuchi & Nonaka “Although project teams are largely on their own, they are not uncontrolled… ”

What this is not
- we’re not talking about
- – being deceptive or sneaky
- – manipulating people
- – IS subtle rules and guidelines
- nothing I’m going to advocate needs to be secret
- – but there may be reasons why you don’t broadcast your reasons
- – e.g. if you have to fire someone

Containers Differences and Exchanges

Glenda Eoyang: Conditions for Self-Organizing in Human Systems
- Container
- – a boundary within which self-organization occurs e.g. project, team, role, nationality
- Differences
- – there must be differences among the agents acting in our system
- – e.g. technical knowledge, domain knowledge, education, experience, power, gender
- – e.g. individual sub-goals
- Transforming Exchanges
- – agents in the system interact and exchange resources
- – information, money, energy (vision)
- how can we use these to influence the way the team behaves?
- – amplify or dampen the differences
- – re-frame the problem
- – change the communication environment

Comment from audience about “Wisdom of Crowds”
- groupthink!

Using the CDE model
- Adjusting the Containers:
- – formal teams, informal teams, clarify (or not) expectations
- – e.g. the AI programmers thought they could not talk with each other, only the people on their teams
- – introduced a Community of Practices
- Differences:
- – dampen or amplify them within or between containers
- – e.g. if people are having a hard time making decisions because they are all too different, maybe adding people to increase similarity
- Exchanges:
- – insert new exchanges, new people, new techniques or tools
- – e.g. team that needed to get outside help re: architecture
- – cross-training

Containers
- enlarge or shrink team

Differences
- don’t require consensus
- – creativity comes from tension
- – quiet disagreement is not as good as fierce debate that leads to behavior change
- _do_ require consensus
- – e.g. if one person is dominating the discussion
- ask hard questions
- – then expect teams to find solutions

Transforming Exchanges:
- remove a document
- create a document!
- encourage communication between teams and groups
- – who isn’t talking
- add or remove people
- – change reporting relationships
- encourage learning

Exercise:

You are the ScrumMaster or PM:
- situations
- ID one thing to change
- use CDE model

Good Group Discussion around Scenarios

Mike Cohn is really good at creating discussion exercises.  I’ve always been impressed.  The discussion excercise asked us to apply the CDE model to the various scenarios.  In our group we only looked at two out of the five scenarios.  Each time the discussion was great – lots of good ideas from people about how to solve the problem in the scenario.  What wasn’t so good at first was using the CDE model.  It’s easy to just look at the scenario and come up with solutions.  What isn’t so easy is to use the model to generate solutions or to map solutions into the model.  At a personal level, I also found that folks in my group were emphasizing imposing solutions rather than using the Scrum model to have solutions emerge from the team’s own efforts.  For example, the retrospective is a Scrum practice that really should be the first line of defense.

Aother Philip Anderson quote:

“Self-organization proceeds from the premise that effective organization is evolved, not designed.  It aims to create an environment in which successful divisions of labour…”

Variation, selection and retention
- evolution is result of these three elements
- consider a giraffe:
- – variation: longer neck
- – selection: helps it reach food
- – retention: more food means more progeny

Seven levers for influencing team evolution:
1.  Select the external environment
- more than the physical environment
- business, industry
- approach to innovation
- approach to mistakes
- types of projects
- expectations about multi-tasking and focus
2. Define performance
- selection – traits that help us survive
- short vs. long-term performance
- providing training
- support sustainable pace
- explore wild ideas
- not exchanging deadlines for unmaintainable code
- e.g “Up or Out” culture – burn out or be promoted!
3. Manage meaning
- stories from leaders
- keeping messages out
- “we will become profitable this quarter”
- rituals
- Story about Mike’s background (1994)
- – valley of death
- – product did not have a long life
- – no new features
- – decided to create new product
- – “valley” in decline of revenue from old product, vs. increase in revenue for new product
- – as part of this, replaced two-ply with one-ply toilet paper to remind everyone of the need to save costs!
- Another story
- – “our GM counts the cars in the lot every day at 5pm” – not a good culture for Scrum!

4) Choose People
- who is on the team
- adjust:
- – team size, decision making style, location, gender, background, motivation

5) Self-selecting members?
- should a delivery team be allowed full control over who is on the team?
- under all circumstances or only some?  which?
- what are the advantages and disadvantages?
- – people often will choose to work with similar people
- doing this is giving up some control
- “you can self-organize unless I disagree” is not a good message!
6) Evolve vicarious selection systems
- variation-selection-retention
- – selection was determining which variations will be retained – can take a long time
- so we often use vicarious selection systems
- – this is an animal that can smell that a food is poisonous, rather than eating it
- using only the marketplace as our selection mechanism takes too long
- Organizations can have vicarious selection systems:
- – retrospectives, Google’s 20% policy which attracts people to projects, compensation
7) Energize the system
- unless energy is pumped into the system, entropy will set in
- make sure the group has a “clear, elevating goal” or an “igniting purpose”
- motivation
- opportunity
- information
- Teamwork by Larson and LaFasco or Hot Spots by Lynda Gratton
- example: Bill Gates and “Internet Tidal Wave” memo

New book by Mike Cohn:

“Succeeding With Agile”

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Dr. Mark Paulk

Monday, March 16th, 2009

Notes from the talk by Dr. Mark Paulk

PLEASE NOTE: These are raw notes based on both the talk and the slides for the talk.  Any errors or omissions are mine.  – Mishkin

**

  • Research
  • Practices that characterize the Scrum agile method, along with common variants and tailorings
  • Which Scrum practices, or variants thereof, have been implemented and the perceived value of the method
  • Factors affecting Scrum adoption

Scrum

  • a process for incrementally building software in complex environments
  • (really likes the Nokia test)
  • Backlog – all outstanding work for a product area
  • Sprints – 30-day increments of work that produce a deliverable
  • Scrums – daily status check meetings

Scrum Practices

  • practices: 30-day Sprint, Product Backlog, Daily Scrum, …
  • roles: ScrumMaster, Development Team, Product Owner, …

Variations on the Scrum methodologies

  • different lengths of Sprints
  • ScrumMaster = Project manager

People do stupid things because they interpret e.g. CMM to be waterfall
Waterfall is a stupid idea – CMM introduces 7 different lifecycles
Loves iterative, evolutionary lifecycles
What are the variations of Scrum that are legitimate?
From an impericist perspective, Dr. Paulk doesn’t care
Where is the dividing line on Sprint length?
2 weeks? 4 weeks? 6 weeks? 6 months?
Probably universal agreement that 6 months is counter to the Scrum philosophy
But 6 weeks vs. 6 weeks + 1 day?
As empiricist, when hears role of ScrumMaster, says it’s a Project Manager
what about teams that have both a ScrumMaster and a Project Manager?
There are going to be terminology issues
when doing survey, it is important to make sure that people know what you mean when you use certain terms e.g. Product Owner
E.g. What is a “project” vs. “task” (8 hour projects in a CR environment)
Not officially part of the methodology:

  • Defining “done”
  • Quitting/stopping and being “done” are not the same thing wrt End of Sprint
  • Design reviews
  • Code reviews
  • Unit tested

Practices commonly associated with other agile methods

  • if every successful Scrum project did TDD, then we might consider bring TDD into the method definition (relationship to “done”)
  • Test-driven development
  • Pair programming
  • Good engineering and management practices in general
  • Top-10 risks list
  • Risk management is done differently in agile approaches (note: the spiral model is explicitly targeted at dealing with risk)
  • Customer-supplier relationship

Empirical research always leads to surprises – we go in with pre-conceptions
Practice Effectiveness

  • The Scrum method in principle should be used without much variation – significant variation probably indicates a “ScrumBut” implementation
  • early termination of a project is not failure – business decision
  • Practices that are perceived as working will continue to be used…
  • Perception is important!  People will continue to use what they perceive to be effective
  • “Superstitious” learning
  • Were any Scrum practices perceived as not being feasible?
  • Did any Scrum practices not work well when tried?
  • Can we measure this in any meaningful sense?
  • Did it increase market share? Etc.?

What is the definition of a successful project?

  • Dept. Of Def. – meeting schedule is the most important factor
  • System, culture and environment play a huge part!
  • cultural clash between DoD and agile approaches do things
  • overcoming this clash is the only way that the DoD can get benefit from agile

Why Adopt Agile Methods?

  • pilot the agile practices and see how they work?
  • Use agile methods on my projects (because I like it)?
  • Adopt agile methods in a particular domain – where appropriate?
  • - Scrum is not as software-specific as other agile methods
  • - used a Scrum-like approach for the development of CMM!
  • - Some areas where these methods just might not be appropriate e.g. DoD
  • - Architecture breaker – a problem that requires a project be re-started (Barry Boehm)
  • - reliability on life-critical systems
  • Adopt agile methods for the organization?

CMM and agile – complementary
CMM eyes-wide-open, tailor when needed, standardize when possible
what class of projects would agile methods be applicable?
Process community has learned things about the factors that affect adoptions
Assessment readiness survey – even this can be difficult

  • Assessment failed (1/3)
  • Assessment completed, but nothing done with it (1/3)
  • Assessment completed and followed up with changes (1/3)

… fired “customers” who were dead in the water
Measuring Business Success

  • Does the project have a “product vision” that characterizes success?

How does the project measure success?

  • financial/market (profit, market share)
  • quickly responding to changing customer needs
  • cost and schedule drivers
  • quality
  • customer satisfaction / delight
  • innovation (building for the future)

Where does Scrum/agile fit in terms of business drivers?
Factors Affecting Adoption
some general adoption issues

  • sponsorship – addressing business problems
  • resistance to change
  • we need a requirements specifications
  • shelfware (facades)
  • training, user groups, conferences
  • scope of piloting / adoption
  • politics, responsibility, accountability

some cultural issues

  • power and control
  • uncertainty (when will we be done?)
  • confrontation vs. Compromise
  • risk aversion
  • National cultures are a big factor in methodology adoption

The Agile Alliance (quote the Agile Manifesto)
values need to inform research
e.g. Need to provide human feedback not just documented feedback
Cultural Misfits (Using the DoD as an example)

  • regulatory requirements for a level playing field raise challenges for evolutionary and incremental development
  • level playing field for vendors
  • The need by the contracts officer for a requirements specification
  • one project the proposal took more effort than the project itself
  • Progress payments defined from a waterfall mentality
  • Barriers – regulatory and cultural – to a collaborative customer relationship
  • Protests from competitors

Research Realities

  • We’d like more information than most people are willing to take the time to provide
  • participation by people doing the work is crucial to insight
  • Surveys inspire more questions
  • Follow-up interviews provide deeper, but less comparable information
  • e.g. To explore causality vs. correlation

Research Plans

  • survey of Scrum projects
  • Interviews and case studies of selected projects
  • hoping to chat with people here at the conference!
  • Publications confirming / testing “what everyone knows”
  • Scrum practices, variations, and associated practices
  • business value of Scrum
  • factors affecting Scrum adoption

Questions and Answers
haven’t seen much evidence that research changes anything – is spending this money worth it?

  • We don’t use empirical research very much!
  • Having evidence in toolkit can help discussions with people who have limited time/information to investigate independently e.g. executives
  • Research can help us understand the barriers to Scrum adoption

Starting with a theory of Scrum to test?  If so, what is it?

  • Starting actually with pure exploration of factors that affect adoption, and practices actually being used – surfacing issues

Couldn’t hear question – seemed to be about security
Would you use the Scrum approach for the research itself?

  • Collaborative approach with the Scrum Alliance, Ken Schwaber, Jeff Sutherland, etc.
  • Getting feedback from public at large
  • Not going to use all the practices e.g. Daily Scrum because working part-time as an individual, not with a team

Dr. Mark C. Paulk
mcp@sc.cmu.edu

http://www.cs.cmu.edu/~mcp/

Carnegie Mellon University
Institute for Software Research
407SCR 115
5000 Forbes Avenue
Pittsburgh, PA 15213 USA

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering Orlando Florida – Day 0 – Registration – NOT!?

Sunday, March 15th, 2009

Let me start by saying that I’m very excited to be in Orlando Florida for the next four and a bit days for the Scrum Gathering and then the Scrum Trainer Gathering to be held immediately following.  I look forward to connecting with friends, acquaintances, collegues, and of course making lots of new connections.  I also look forward to the sessions.

Over the next few days, I’m hoping that I will simply be posting my notes from all the sessions that I attend as well as any Tweets and relevent email exchanges.  Let’s start even before the conference itself starts with the registration process.

The Scrum Alliance is a growing organization and is clearly working hard to be professional.  It has gone from a concept in the mind of Ken Schwaber (at least) and matured to a well-known not-for-profit (or is it non-profit) organization that manages a substantial certification program, website, and conference schedule.  All that work to be professional was undermined for me this evening.  It’s a small thing, really, but I think it is important to mention.

When I checked at the hotel reception (Gaylord Palms), they told me that the Scrum Gathering registration would be open until 11pm.  Since I was hungry, and more importantly, my family were very very hungry, we decided to eat and that I would register after dinner… at about 10pm.  I went to the convention centre part of the resort to the location the person at hotel registration had indicated… and found absolutely nothing.  No signs.  No people lingering.  No little tiny note saying “Sorry… we closed registration early this evening, due to (illness|laziness|no one coming|hotel staff told us to get lost|etc.)”  Not only that, when I went back to hotel reception after wandering about hoping to find someone, they still had no idea that registration had closed.  I wonder how many people wandered up there only to find no one there?

I’m not impressed.  I would have been quite happy if there had been a note or some other attempt at communication to indicate that unfortunately the original commitment to be open until 11pm was not going to be honored.  I would have been even happier if hotel reception could have told me this.  But it’s pretty frustrating to realize that the people who are the first line of representation of Scrum didn’t understand/remember that Scrum is about visibility… clear proactive communication.

If this had been a conference for plumbers, doctors, astrophysicists, homeschoolers, or almost any other professional group, I wouldn’t see this as a big deal at all.  It would in fact be just another minor annoyance to quickly forget.  From the Scrum Alliance I find it less excusable.

Now, given that all the above is pretty much a rant that may be at least in part a reflection of my long day of travel, I have to step back and acknowledge that there might be a good reason that there was no one at the conference registration desk when I went almost an hour before they were to close.  Perhaps there was only one person on duty and he/she got suddenly ill!  Perhaps the person on duty simply took an extended bathroom break and didn’t think that there would be anyone coming at so late an hour.  Perhaps someone else suggested that they close up early and since the person on duty was bored, it was an easy suggestion to act upon.  But the lack of communication still bothers me more than it would normally.

I’m sure the remainder of the conference will be great.  I hope that you all who are reading this find that my impressions are more sunny for the next four days.  After all, I am in the Sunshine State!

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Changing Patterns of Thought for Defining and Expanding Done

Monday, January 26th, 2009

“Without changing our patterns of thought, we will not be able to solve the problems that we created with our current patterns of thought.”  -Albert Einstein

“We are what we repeatedly do. Excellence, then, is not an act, but habit.”  -Aristotle

Among leading Agile thinkers, coaches, trainers and practitioners there is a rich, ongoing discourse around a subtly deceptive concept  – the concept of the Definition of Done.  Within this discourse, a singular constant challenge is emerging:  old patterns of thought.

For example, there is an old pattern of thought that tells managers of software companies that at least some part of the Definition of Done must be imposed on teams in order to protect a universal standard.  Rationalizing this antiquated thought pattern seems to have become a rigorous intellectual discipline in and of itself.  One of the most prevalent excuses to which many managers have invested a great amount of mental and emotional energy seems to be around the challenging concept of multiple Agile teams working together on the same project (or product).  Surely, in such cases there needs to be some kind of imposed standard that all teams need to comply with in order to avoid chaos in the main build, yes?  In fact, this is the exact wrong approach to take.

We also seem to become confused at times by our own limited understanding of the words that we use when attempting to talk about things we are or are not trying and learning to do.  The more we learn about doing something, the more we are able to talk about it in practical terms.  Since theoretical discussions around semantics rarely result in appreciably improved behavior/results, we will endeavor here to address this subject with both brevity and caution.

Our old patterns of thought make understanding many words, including the word definition and the word done, problematic.  We tend to think of these words as implying static, rigid, absolute conditions; for example, the way we tend to think of the word definition in terms of the definitions of words.  We like to think that those definitions are relatively stable.  Indeed, there are some real benefits to this.  We can have conversations with people and assume that for the most part their understanding of the definitions of the words we are using are similar to our own.  But even with words, there can be more than one definition, which already makes the definitions of words less static than they often seem.  At some level, one might even ask – who actually decides on the definitions of words?  Is there an actual authority out there (not merely the self-proclaimed “official” authorities) that decides on definitions and hands them down to us?  Some may say “yes, indeed, namely the authoritative texts of the world’s religions,” for example.  On the other hand one could also say that the definitions of words have evolved through the ages (just as languages have) as humanity has received progressively more complex guidance from religious texts according to its evolving capacity (compare, say, the Bhagavad Gita to the Quran).  But that is another conversation.  What is important to acknowledge here is that the meanings of words expand and evolve over time given the capacity of the individuals who use them to develop new patterns of thought and that the energy required to do so is tremendous, even epochal.

An old pattern of thought construct around the word done is equally problematic.  A conversation limited by a rigid understanding of the concept of what done means, is and looks like can quickly take us spinning off into the stratosphere of “nothing is ever done.”  When there is a lack of trust and respect among people, as is generally the case in our society, and since ownership and ego are often entangled with limited and rigid understand, we then find ourselves in situations in which the limited and rigid understanding of a few with arbitrary power and authority take precedence over the understanding of others.  In other words, people in authority are expected to solve every problem and people that do work are expected to be robots.  Both are set up by this arrangement to fail.

Indeed, there is a real problem in trying to talk about things that we do not do, or that we do not sincerely try to do.  True learning, on the other hand, consists in people striving to be truthful and sincere working together  engagement in a continuous cycle of action, reflection and consultation.  Learning also requires us to be truthful – if we think we have all the answers, learning becomes extremely difficult, if not impossible.  If we are not at least trying to learn to define what “done” is to us, we will never be able to actually talk about it in a knowledgeable and meaningful way.  Furthermore, it will likewise be impossible for us to help anyone else learn to understand their own Definition of Done if we haven’t learned through real experience about how to understand our own.

As we engage in a real learning process, through action, reflection and consultation, new patterns of thought begin to emerge and perhaps even crystallize.  These emerging new patterns help us to bring concepts out of the stratosphere of semantics, rhetoric and theory back down to earth where we can actually act and reflect on them in order to implement creative new solutions to the problems of our world.

In her Agile 2007 presentation The Role of Leadership in Software Development (http://www.infoq.com/presentations/poppendieck-agile-leadership), Mary Poppendieck offers powerful insights into the history of patterns of thought around leadership and the emergence of Agile thinking out of the wisdom of Lean Manufacturing.

As with all Agile methods, Scrum is a framework for learning in which new patterns of thought that began to crystallize in Lean Manufacturing practices have been adapted and applied to software development practices.  It then follows that the Definition of Done in Scrum is consistent with a specific Lean Manufacturing practice, namely Standard Work.

In his book Workplace Management, Taiichi Ohno, the father of Lean Manufacturing, defines Standard Work as such:

“There is something called standard work, but standards should be changed constantly.  Instead, if you think of the standard as the best you can do, it’s all over.  The standard work is only a baseline for doing further kaizen [change for the better].  It is kai-aku [change for the worse] if things get worse than now, and it is kaizen if things get better than now.  Standards are set arbitrarily by humans, so how can they not change?

“You should not create these away from the job.  See what is happening on the gemba [shop floor] and write it down.”

Based on the assertions of the previous two paragraphs, we must conclude that just as standards should be changed constantly in Standard Work, so too should definitions change constantly in the Definition of Done.

How, then, does our work benefit from a Definition of Done that is always changing?  This is a deceptively simple question, as it is an example of a problem posed by old patterns of thought that can only be solved by new patterns of thought.  In order for the old patterns of thought thinker to be helped to form new patterns of thought, he must be accompanied by the new patterns of thought thinker to develop the capability to adopt new patterns of thought.  In other words, in order to really learn, people need to be accompanied by those who have more experience.  Such an exercise is far beyond the scope of any article and requires a completely different venue – namely the coaching relationship.  More about capacity-building and accompaniment later.

For now, suffice it to say that the point of having a Definition of Done that is always changing is to allow for kaizen – the Definition of Done, therefore, like Standard Work, is only a baseline from which we constantly change for the better.  In other words, the Definition of Done is the record of what we are actually doing now. It allows us to be absolutely confident that we know as much as possilbe about what we are actual doing now so that we can make real, concrete, and confident decisions about actual improvements to our work.

Actually doing the Definition of Done, as Ohno tells us is simple:  “See what is happening on the gemba [shop floor] and write it down.”  For many of us though, this simplicity is deceptive in that it is actually often very difficult – both the seeing and the writing.

The ability to see what is actually going on is clearly vital to the capability of defining done.  It is valuable, therefore, to examine more closely the sense of sight:

We have physical eyes that see.  What do our eyes see?  Light.  Is this what Ohno is talking about when he says “see what’s going on” – literally seeing light – or is he talking about a different kind of sight?  Clearly, what he is talking about is what we might call true sight, or the ability to see the truth.  We can think of truth, therefore as being like light.

Is it our physical sight that sees the light of truth?  This, of course, is impossible since our physical eyes only see physical light.  So what is the sense in us that allows us to see the light of truth – in other words, what is true sight?   Some may say that it is our sense of justice.  One must have a strong, developed sense of justice in order perceive truth, especially in environments like software development in which the truth can be easily hidden.

Writing down the Definition of Done with accuracy and clarity requires us to be both truthful and precise.  This is very difficult to do well in our present environments of opacity, defined roles, command and control management, fear of failure and general distrust.

Clearly, we can see now that the Definition of Done, challenging to understand in its subtlety as a concept, is far more difficult to apply effectively in reality and therefore fully realize its value in practice.

The concept that allows for the value of the Definition of Done to be realized is the concept of expanding the Definition of Done.  Expanding the Definition of Done in Scrum and Agile is the equivalent of kaizen in Lean Manufacturing.  In order to expand the Definition of Done, the actual Definition of Done needs to be well understood.  In other words,  “Where there is no Standard there can be no Kaizen.”

Ohno says:

“When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve ‘the best way.’  This is a big mistake.  Document exactly what you are doing now.  If you make it better than it is now, it is kaizen.  If not, and you establish the best possible way, the motivation for kaizen will be gone.”

This brings us back to the initial problem created by our old patterns of thought around our understanding of the Definition of Done – namely the misconception that at least some of the Definition of Done must be dictated by management in order to have consistency across teams working on the same large project.  The solution to this problem is challenging yet simple:  It’s irrelevant.  An organization is a living, breathing entity.  When management makes room for kaizen by not dictating standards, kaizen has more power to pollinate the entire organization and transform the way people think and work than imposed standards could ever begin to hope for.  Dictating standards, in other words, is limiting while kaizen harnesses the creativity of all.

Again, Ohno says:

“We need to use the words ‘you [the worker] made [the standard]’ as in ‘follow the decisions you made,’  When we say ‘they were made’ [for you] people feel like it was forced upon them.  When a decision is made, we need to ask who made the decision.  Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

“But in the beginning, you must perform the Standard Work, and as you do, you should find things you don’t like, and you will think of one kaizen idea after another.  Then you should implement these ideas right away, and make this the new standard.”

Changing our patterns of thought requires creativity, but who’s creativity?

Ohno:

“Years ago, I made them hang the standard work documents on the shop floor.  After a year I said to a team leader, ‘The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.’  I said ‘What do you come to work to do each day?  If you are observing every day you ought to be finding things you don’t like, and rewriting the standard immediately.  Even if the document hanging there is from last month, this is wrong.’

“At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them.  This gave me a good reason to scold the team leaders, saying ‘Have you been goofing off all month?’

“If it takes one or two months to create these documents, this is nonsense.”

People on the shop floor or the Scrum teams need to be given the freedom and authority to figure out how to do their work better and change the standards of their work as they learn.  Ohno was really first and foremost a master coach who knew how to accompany people to develop their capabilities to perceive truth and generate and apply their own knowledge and creative solutions to challenging problems.

Gary Hamel, in his article “Management Innovation” in the February 2006 edition of the Harvard Business Review, wrote:

“Only after American carmakers had exhausted every other explanation for Toyota’s success- an undervalued yen, a docile workforce, Japanese culture, superior automation- were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

In Scrum, the Team itself defines Done by what it actually gets done.  The ScrumMaster removes obstacles so that the Team can expand its Definition of Done (kaizen).  Scrum assumes that all Team members are dedicated to expanding the Team’s Definition of Done from Sprint to Sprint and that the Team will achieve this as long as organizational obstacles (such as managerial control fetish) are not impeding it from doing so.  When a Team is empowered in this way to expand its own Definition of Done (as well as empowered in other ways, according to the rules of Scrum), it will have the space it needs in order to grow into a hyper-productive Team.  That is to say that no one outside of the Team (i.e. management) dictates any part of the Team’s Definition of Done (a common management practice that results in kai-aku).  The Definition of Done is one ingredient in the remedy for curing our culture’s leadership disease – the failure to learn.

“…your failure is an internal disease…You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”  -Konusuke Matsushita

(Shameless Plug: we offer excellent Certified ScrumMaster Training and in it we discuss the Definition of “Done” in the context of people’s actual problems.)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb