A story about Acceptance Criteria and a medical procedure to help your Agile team

The following story is designed to help get your teams thinking about the topic from the “How can we learn this together” approach.
There are many detailed books with different points of view about acceptance testing.  I created this story as a way for teams to discuss this in a common language and figure out what works for them.

While you read this, I hope you see many similarities to the Agile Frameworks of your choice.  Perhaps quizzing your team on how many they find might be fun? (a different topic).

Please don’t give me a hard time about the medical inconsistencies.  I’m not a doctor and don’t have a medical degree.  It’s just a story and is completely fictional.

Fade in…..  The patient walks into a moderately lit room with an uncomfortable black chair that looks like it’s 20 years old, sitting next to a medical examination table.  The patient sits on the little black chair to discover it also feels that way.  He is going to be the patient for a long series of medical procedures to solve some medical problems.  The patient knows it will take many surgeries to get to where he wants to be.

Surgeon: So, we’re going to remove your appendix this week.  The team is anxious to get rolling.

Patient : I’m pretty nervous.  I don’t really know what to expect and I know I have all these other operations that need to get done for me to be totally healthy.

Surgeon : Don’t worry.  We have a really good team.  We also want to make sure you are 100% satisfied with the work we do.  We know that you want to get some cosmetic work done in the future and you have other important surgeries to do, but for now, let’s focus on the appendix removal, OK ?

Patient : Sure

Surgeon : We want to make sure we have a common understanding of what you want from us.  So, we’re going to ask you a few questions OK ?…Can I get the team in here ?

Patient : Sounds good.

(introductions).

Surgeon : Well, for this to be considered a successful operation, what kind of things are you looking for?  I already know, that to me at least, successful means two things.  1- The appendix is out and 2 – you don’t die during the surgery.  Well, actually, the not dying part is part of every surgery we’ll do for you.  We’ll assume that every surgery needs you to live.

Patient : I’m glad you said that!!! Phew.. I feel better already.  And ya, I agree, it would really be a drag to do the surgery and not end up with the appendix out.  I agree with both of those things.

Surgeon : We need to put a caveat.  If we start and see that it’s impossible to finish for some other reason, we’re going to abort the surgery.  We won’t continue if we can’t be successful.

Patient : Yes, that makes sense.

Surgeon : So, we’re agreed then.  Let’s go ahead and get you prepped.

Anesthetist :  Not so fast, I need to speak.  We want to make sure you don’t have any allergic reactions.  Have you ever gone under?  Do you have any allergies ?

Patient : I’ve been under before, and have had no problems.

Anesthetist : Great.  Let me just record that on our surgery card.  We’ll need to know that we can make adjustments as we go if something bad happens.  Is that OK ?

Patient : Ya, whatever you need to do.. Go ahead and switch to another chemical if you need to.  I’ll be happy if you don’t kill me and you’ve done what you can if you notice an allergic reaction.

Patient : Since I’m on the topic, I would like to have a very small scar and not a big one. I am willing to pay extra for a smaller scar and therefore, for me, I won’t be happy unless the scar is small.

Surgeon : Well, that will make the operation harder and we might need to put off some work where we were prepping for your next surgery until a future date. The reason is that you can only be under a limited amount of time.  It won’t cost you more because the price of the surgery is fixed.  You might have to give something else up later.  Can you live with that ?

Patient : Yes, if I have a big scar, I won’t be happy. I am willing to pay the extra over the long run and maybe I’ll have something less done later.  I really don’t want big scars as we move forward.

Surgical Resident :  Hold on, that’s way too subjective.. What might be big to you could actually be a really small scar.  What does a small scar mean?

Here are some examples.  Which on of these is considered small enough for you?

(shows a batch of photos).

Patient : I’d like it to be at least this small.  (picks one).

Surgical Resident : OK, the scar will be under 30 CM in length and 1 CM in width.  Does everyone feel we can do this and this?

Everyone : Yes

Surgeon : Anything else?

Patient and the rest of the team : No.

Surgeon : Well, then, we’re a go.  Now that we all know what will be considered acceptable and a sign of success, let’s get prepped tomorrow morning first thing…

Fade out…

Fade in.. .the day of the surgery…. (beginning of the Sprint)… the patient is rolled in…

Doctor : OK team, let’s quickly review our acceptance criteria… Patient Alive, deal with allergic reaction and the patient expects a scar of under 30 CM and 1 CM in side.  I expect everyone on the team to help me make sure we meet these requirements.  Can everyone agree before I cut?

Team : Yes.

(Surgery is moving forward)

Surgical Resident : Doctor, if you do that just a little differently, perhaps you will be able to shave a few millimeters off the size of the scar.  What do you think ?

Surgeon : Great idea.. Thanks for that.  Why don’t you hold onto the medical gizmo while I do the next cut. Sure, that will make it easier for both of us to do this together.

Anesthetist : Hey guys, hold on, let’s just talk about this.  if you do that, his blood pressure will go up and you risk killing him.

Surgeon : Wow, thanks. I doubt we would kill him, but we’d probably have to do some extreme surgery which would definitely give him a huge scar. Let’s think about this.

(discussion takes place)

Team : Glad we figured out how to do that. We can safely do that without causing any risks to the patient in the future.  Let’s go for it…

(surgery continues)

Surgical Resident :  Hey Doc, we’re almost half way through the time for the drugs and allocated time for the surgery.  Can we all agree about how much work is left so we don’t keep him under too long ?  OK, we have about another 2 hours of work do here. We’re still good.  No need to worry.  Let’s update the surgical status board to say “surgery progressing appropriately” so his family knows everything is on track.

(surgery continues).

Surgeon : OK, let’s finish up.  Anything missing ?

Surgical Resident : Yes, don’t forget to take out that sponge.

Surgeon and Anesthetist :  Yikes!

Surgeon : Thanks for catching that.

Anesthetist : No kidding.  That wouldn’t be very professional and people probably wouldn’t think we’re very good at what we did if we left stuff undone and had to come back and fix it later.

(surgery is finished successfully and the patient gets rolled out).

… fade out

… fade in….   patient in recovery and the team comes to check on him.

Surgeon : So, the surgery went really well.   You’re obviously alive, your appendix is gone.  Only one last thing…..

(the doctor removes the bandage and shows the patient the size of the scar).

Patient : Wow, that’s exactly what I asked you for.  It hurts a lot, is that normal? I wasn’t expecting that!

Surgeon : Yes, that’s normal.  Once the swelling goes down, it will be even smaller.

Patient : Thanks Doc.

Surgeon : Thanks to the team. Everyone really worked hard to make this happen.

Patient : Ya, thanks team.

Surgeon : Oh, by the way, we had to correct an adhesion we discovered while working.  Not to worry, we didn’t charge you extra.  We charge for the amount of time we spend doing the surgery.  We just fixed it while we were in the area.  (yes, I can see the malpractice lawyers cringing.. this is just a story).  We knew it wouldn’t extend the amount of time for the surgery and we knew you would be happier with the results.

Patient : Thanks. The team is amazing!

Surgeon : Is there anything you didn’t like or any special comments you’d like to give the team for the next surgery?

Patient : Ya, I wish you would have warned me about how much it would hurt.

Surgeon (whole team nods) : Thanks for that.  We’ll consider that in the future.

…. fade out ….

… fade in ….   Medical Team room.

Surgeon : Well, that went very well.. any comments about what could have gone better?

(some discussion happens).

Surgeon :  Great, we’re agreed then.  For the next surgery and all the ones we do in the future, let’s have an open discussion with the patient ahead of time about the expected amount of pain so it doesn’t cause them alarm when they come out of surgery. It will be a better experience for them and improve our professionalism.

…. fade out….

Mike Caspar

 

 

 

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Skills Matrix and Performance Evaluation on Agile Teams

For a few years now I have been working with managers and executives to help them do Agile-compatible performance evaluations of their staff.  The method that has been most successful is based on a tool that comes from the book Toyota Talent called the “Skills Matrix”.  The basic approach follows these steps:

  1. Baseline the skills within a team for each team member.
  2. Set development goals and action items.
  3. Regularly review performance in relation to the development goals.

Of course, the details matter.  The OpenAgile Center for Learning has published a brief overview of how to use the Skills Matrix and a convenient A0-size pdf that can be used as a template for a team’s Skills Matrix.  I highly recommend using these to get started.  If you are a manager, ask your ScrumMaster or Process Facilitator to arrange and facilitate a team workshop to do the initial population of the Skills Matrix, rather than doing it yourself.  Once that is done you have a baseline and you should take regular digital photos of the team’s Skills Matrix for record-keeping and as a backup in case of disputes.  You should also let the team know that you will be basing performance reviews on how they improve their skills.

The development goals that team members set then should be made such that every team member understands that they have a responsibility to diversify their own skill set and assist other team members in doing this.  As a manager, you should review each team members’ goals for development and provide mentoring support when needed.  At the end of a fixed period of time (quarterly is a reasonable period), you will review each team member’s development relative to the baseline and the goals set.  Of course, normal guidance around performance (or lack thereof) can be given at these regular reviews.

I strongly recommend reading “Drive” by Daniel Pink as an important adjunct to understanding how to do performance reviews for individuals in an Agile environment.  In particular, individual performance reviews should not be tied to bonuses.  If bonuses are used at all, they should be measured and delivered purely at the team level or organization level without measuring individual contribution.

Of course, Agile team performance can’t simply be measured in terms of skills alone.  Performance must also be related to bottom-line results.  This part of performance measurement is separate from the development of the team.  Another aspect of Agile team performance is how well they are doing Agile itself.  Depending on the Agile method you use, there may be various tools to help with this (I would recommend our new product the Scrum Team Assessment as one possible consideration).

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Be able to explain WHY.

Every once in a while I’m reminded of the very important question: WHY?

If you are considering SCRUM, XP, Lean or any other Agile Framework, or if you are considering using OpenAgile which is an Open Learning System, you will be changing the organization.

Many people think they can do “Agile in a bubble” and therefore not interact with the rest of the organization.  You will likely find that you will quickly run into obstacles to using the Framework.

Just the iterative process alone will change the way stakeholders interact with teams, meeting rooms are scheduled, vacation schedules, communication requirements, team spaces and/or seating, the responsibilities of stakeholders, and even the interactions between team members and other departments.  Because of this, working towards Agility WILL change your organization.

You may start out with an aggressive framework such as XP(Extreme Programming), or something a little more gentle such as Kanban or Lean (which let you start out as you are and visualize your process).  However, please don’t kid yourself; you will eventually need to change the way things get done in the company.

 

Which WayWhether you are the OpenAgile Growth Facilitator, a Scrum Master trying to introduce Agile from the grass-roots, or if you are the CEO or CIO trying to introduce change from that level, you will eventually need to address the WHY for the change.

Managers and employees alike need to know why they are being asked to leave their comfort zones.  In some cases they will be going against everything they have learned in the past about people management or how they should work.  They need to know the reason.

 

Whatever level you are in at your company, please be ready to explain why you are making the change to an Agile Environment.  Something like “to be more efficient”, isn’t really going to cut it.

  • Is it to be more competitive against other companies breaking into our market and you need to change quickly to stave them off?  To give this message, you would need to let people know that you are concerned about this.  This is part of the Transparency of Agile.  If you know this, but are not willing to pass this on to your managers or teams, you will have struggles when managers don’t know why you are changing their environments.
  • Is it to stop the high level of turnover in your company ?  You will be changing to a more team-focused environment which might seriously change the way Project Management or even H.R. does things.  For this also, you will need to explain your changes to help you get support.

I could think of many other reasons.  You should have your OWN reasons.

If you started an adoption or transformation a while back, it’s a good idea to restate this every once in a while (if even for yourself).  It will remind you why you are continuing to improve and learn every iteration.

Asking yourself once in a while will also allow you to improve your message which will likely change slightly over time as the market and your environment changes.

Please, go home TONIGHT and ask yourself WHY are we transitioning or continuing to work towards being more agile.  You will need to answer this for others more than once as you continue on your journey.

If the answer to yourself is “this is our last chance to make sure we don’t disappear as a company”, that revelation is a good one as well, and you will know why you need to stand strong on the changes you are making.  Either way, it all starts with the same question.

Please make sure you always know the answer to the question “Why?“.

References:

OpenAgile, Growth Facilitator
XP (Extreme Programming)
SCRUM
Kanban, Lean

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Performance Reviews and Agile Teams – Link

Mike Caspar (who sometimes contributes here too), has written an excellent article on a method for Agile Teams to gather data that could be used for performance reviews.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Evolution of Agile Methods

I had the great honour of participating in two sessions of David Sabine’s excellent “Agile Questions” show – check it out!

Show One: “Should/can agile methods be blended?

Show Two: “As Scrum teams evolve, do they become OpenAgile?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Facing the facts early on. Risk Mitigation can be a powerful motivator.

Recently, I was able to witness a remarkable event in a company that is relatively new to Agile. They have several teams at about Sprint 12, with several new teams just starting up. Many of their processes are waterfall based.

A failed waterfall project was moved to an existing Agile Team.

In the second Sprint, the Team (feeling trust in the organization and the process), came to the Scrum Master and said, “We’d like you to talk to management. We are not sure this project should be using the platform we develop on. We think another team’s platform may be more appropriate”.

The company had spent time developing a “specification document” for this “project” before Agile was introduced. There were detailed specifications as to how the product was to be created and which platform to use. NONE of this was done with the benefit of asking those that would actually be doing the work.

The project was initiated before learning about applying Agile. One developer was tasked with following the specification. After 2-3 months of frustration, the developer left. This left the company in a bad position. Not only was the project incomplete, but there was also no knowledge transfer. The project was basically stopped.

As Agile was now the new target way of doing things, the project (and new developer hired through the previous process) were added to an existing SCRUM team. The team is using one week Sprints.

After only two Sprints (two weeks), the team had recognized the futility of the approach that was “specified” and took this to management.

Traditionally, large organizations staff for projects. In an environment such as this, how could team members be expected to be truthful and honest about the state of affairs? It would mean the end of their jobs or contracts.

The key here is to allow teams to stick together. Not only will you avoid losing all the efficiency the team has built up, but you will also allow them to be truthful about their situation.

If you are a manager reading this, ask yourself. “Do I want to know that things will go wrong at the beginning of the project or wait until 5 months have gone by to be told, ‘We knew it would never work”". Or even worse… “We knew the product owner was asking for ridiculous features that had no Return on Investment for the company, but hey, you hired us for this contract. We just follow instructions”.

As it turned out, the project did continue with the current team, but with some changes to the specification. The parts of the system that were going to be problems in 5 months were re-evaluated and were removed as they really did not have any real value to the company. It was then decided to stick with the same platform.

Discussions did occur regarding moving to the alternate platform, but were deemed unnecessary after open discussion between the teams and the managers involved. Realistic expectations were set based on value to the company.

Sometimes features are absolutely mandatory for the product. This cannot and should not be taken away from the process. What we gain here is that we are able to have a discussion about necessity. In the end, the business has to decide what is valuable, not the development team.

In a case like this, ask yourself, “If my team is very against this, maybe I should at least think about it”.

The company is working in a very short iterative environment, they quickly recognized a flaw in the system design and dealt with it after only 2 weeks into a several month project.

Working incrementally allows the company to “Inspect and Adapt” on a regular basis. This has to include the question, “Does this still make sense?”. If you need to go backwards, let it be to reverse one or two Sprints of work, not months, or even years.

Fortunately, for the company, the product will come out on time, with appropriate technology based on Return on Investment, and likely with significant cost savings over the initial design. This will also allow the team to get started on other high value projects. Talk about win-win.

This project could have gone to another team. It would not have been negative for the first team. The next project would have just come down the pipe for them.

The early signs helped adjust the “expectations” and everyone is moving forward with a clear understanding that they are on a more appropriate path going forward.

For those of you out there trying to convince companies (or yourselves) that Agile is an effective framework, don’t be afraid to talk about “RISK MITIGATION“.

Think about it this way; The company wants to know early on that there will be a problem, not near the end of the project. This is part of the purposeful transparency of any Agile framework.

Mike Caspar
Mike Caspar’s Blog

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Master, Process Facilitator, Growth Facilitator. Managers or Leaders or Neither?

“I now can see why Corporations have such a hard time identifying the Scrum Master in their organizations. Scrum Masters basically don’t fit either category, yet most corporate hiring is done based on hiring of “leaders” and “managers”.”

For the complete text click here

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Project Management + Certified ScrumMaster (CSM) + Certified OpenAgile Team Member (Level 2) + Kanban – Halifax December 14-16, 2011!!

Last 3-Day Intensive Training of 2011!

Don’t miss out on this unique seminar, where Berteig Consulting  will be offering a practical view of three important Agile methods.  The training includes both theory and hands-on training!

OpenAgile - used for general agile project management and agile teamwork including projects and organizations doing any kind of work

Scrum - used for software new product development and IT project management

Kanban - used for teams doing operational work

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

WHO SHOULD ATTEND?

This course is for team leads, project managers, functional managers, and anyone who is interested in improving the performance of their teams and organization.

Click here more information!

Register Now!!

 

 

 

 

 

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

ScrumMaster + OpenAgile + Kanban training in Toronto December 7-9,2011

We have an upcoming three-day agile training seminar in Toronto on December 7-9, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

For more information: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

to register:
http://www.regonline.ca/Register/Checkin.aspx?EventID=988417 

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

ScrumMaster + OpenAgile + Kanban training in Waterloo November 9-11,2011

We have an upcoming three-day agile training seminar in Waterloo on November 9-11, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

For more information and http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Why we SCRUM: Achieving Hyper-productivity. Presented by Myplanet Digital and Berteig Consulting

On Friday, October 28th at 1pm join Paul Heidema from Berteig Consulting and Shanly Suepaul from Myplanet Digital as we discuss what Scrum is, how we use it at Myplanet Digital and how Scrum can help your team.
 
Scrum is the lifeblood of Myplanet. When executed properly it empowers teams and individuals to stay motivated and achieve excellence. Most importantly, Scrum allows us to continually learn and improve our people and teams.
At Berteig Consulting, we are experts at using agile methods such as Scrum to transform people, process and culture in order to produce high-performance teams and organizations. From ScrumAlliance.org: “Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless.”

Sign up here: https://eval.webex.com/eval/onstage/g.php?t=a&d=924723906 


Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

OpenAgile Team Member training in Markham November 17-18 th, 2011

We have an upcoming Agile training in Toronto on November 17-18th, 2011.  This is a special Agile training because it is an OpenAgile Team Member training – which is the most widely applicable Agile method!  This two-day training seminar is designed to help you use OpenAgile principles and processes to improve productivity, efficiency and quality in your team, project and operational environments. This is the official OpenAgile Team Member training and provides the basic skills and knowledge to work with OpenAgile as a team member.

For more information and to register visit: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

ScrumMaster + OpenAgile + Kanban training in Toronto October 26-28,2011

We have an upcoming three-day agile training seminar in Toronto on October 26-28, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

For more information and http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Introduction to OpenAgile Half-Day Workshop – Nov. 4, 2011 in Toronto

For those of you who are in the Toronto area, you might be interested in a half-day session being put on by Berteig Consulting: an Introduction to OpenAgile.  There are two sessions scheduled for Friday Nov. 4 – one in the morning, one in the afternoon.  The price is $50/person and at the end of the session, you will be fully prepared to write the OpenAgile “Readiness” certificate exam.  The session is being held at the Hilton in downtown Toronto.  The session agenda is as follows:

  1. Welcome
  2. History and Purpose of OpenAgile
  3. Foundations of OpenAgile
  4. Overview of OpenAgile Processes
  5. OpenAgile Capacity-Building
  6. Benefits of OpenAgile
  7. Case Study: Suncor
  8. Q&A

Register now for the Introduction to OpenAgile morning session.

Register now for the Introduction to OpenAgile afternoon session.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

OpenAgile is not (just) Empirical

A few weeks ago, David Parker and I had a conversation about some of the differences between Scrum and OpenAgile.  We hit upon one really interesting thing: Scrum strongly emphasizes that it is a purely empirical approach to doing work… and OpenAgile does not make that claim.  In fact, OpenAgile, while it includes empiricism, is definitely not an empirical process framework.

Ken Schwaber has long been adamant about empiricism with his phrase “Inspect and Adapt” which is the core of Scrum.  All the artifacts, meetings and roles of Scrum are meant to be supportive of the inspect and adapt approach in a product development environment.  A Scrum self-organizing team inspects and adapts on the product it is building.  It inspects and adapts on the obstacles that arise as it does its work.  It inspects and adapts on all the organizational processes, technical tools, team dynamics,… everything!  This is Good.

But Scrum, in its pure empiricism, also lacks something.

OpenAgile has components of Scrum’s empiricism.  Certainly, OpenAgile owes a great deal to Scrum.  The concept of “Systematic Learning”, one of the foundations of OpenAgile, is similar to Scrum’s empirical framework.  The process structure of OpenAgile is also similar to that of Scrum with short cycles of work delivering value on a regular basis.  The main difference comes from a simple concept: Guidance.

In OpenAgile, guidance is a critical component of systematic learning.  Guidance allows someone outside the team to intervene.  This might be a manager, a stakeholder, a family member… anyone who sees things from an “outside” perspective.  It might also be someone within the team pulling in guidance: asking for advice, doing a web search, reading a book, or even meditating in the hope of inspiration.

In Scrum, there are some very strong boundaries around outsiders providing guidance.  No changes mid-sprint.  All requests for work go through the Team’s Product Owner.  The ScrumMaster “protects” the team from outside interruptions.  ”Chickens” cannot participate in the Daily Scrum.  The team self-organizes with individuals volunteering for specific tasks.  Team members discard all organizational titles when working within a Scrum team.  All of these boundaries support a pure empirical approach to working.  They also provide a form of safety for the team.  This safety is deemed necessary with the implication that stuff from outside the team is dangerous.

In OpenAgile, guidance comes to the team through the conduit of love.  Yes… love.

The team develops a love for its work.  This love then opens the team members to guidance.  Think of the opposite: if I hate my work, I’m not likely to be interested in taking any advice about how to do it better.  If I love my work, I will always be seeking ways to improve it.

Of course, love is not binary.  It’s not on or off.  In that continuum, the more an OpenAgile team loves its work, the more receptive it will be to guidance.  The more receptive to guidance, the more sources of guidance will be “safe”.  And the less reliance on pure empiricism will be necessary.

Let’s be frank: pure empiricism, in its most extreme form, means that Scrum teams would re-invent things that may have already been invented many times before.  In the Scrum community, the most obvious example of this is the Agile engineering practices that come from Extreme Programming.  Scrum teams seem remarkably resistant to adopting these practices at the outset… despite the fact that eventually most Scrum teams working in software succeed or fail based on their eventual adoption of these practices.  Scrum teams are often left without the guidance that XP practices can help them.  Instead Scrum teams seem expected to re-discover XP practices on their own.

For what it’s worth, I don’t think that Scrum is fatally flawed.  In fact, I think that in some environments, where teams truly are unsafe, where people tend to hate their work, where dysfunctional bureaucracy is deeply embedded in the organizations culture… in these environments Scrum is actually the right place to start.  Scrum is great for product development in high-crisis situations: save your product with Scrum!

OpenAgile, by accepting guidance into its framework, allows teams to progress rapidly when they can leverage other people’s learning.  Scrum does not dis-allow this, but it sets up an environment where the team culture tends towards the “Not Invented Here” syndrome.  OpenAgile puts teams on the other path: the path of allowing for greater and greater learning from others.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail