Category Archives: OpenAgile

Launching a New Product: #1 Question – Is this a Project or a Product?

Learn more about transforming people, process and culture with the Real Agility Program

Recently, it’s come to my attention that a friend is experiencing nearly insurmountable financial hardship. After initially offering to help out by sharing a few food items, I realized that a few items shared once is not enough. This inspired me to consider the idea of sharing food weekly. I decided to create a regular care package of sorts, until she got back on her feet again.

She agreed to pick up a care package from me weekly. And that’s how this social action initiative was born.

Once I knew I’d be doing this weekly, several logistics had to be sorted out. Where was the food coming from? Where would I store the food between pick-ups? When would it be picked up?

Interestingly, I don’t have enough food in my own cupboards to share with someone weekly. Fortunately, I know many others who are like-minded and highly value supporting and helping others so I began to reach out. Within days I had more than seven bags of food to share and it occurred to me that this would be my goal – 7 bags for 7 days. That should get her through the week.

It didn’t take too long for me to see that if I considered myself as the Product Owner of this product – a weekly food package – that there might be valuable Agile concepts and practices which could easily help support the sustainability of this initiative. 

Is this a Project or a Product?”


Immediately, an Agile Coach inspired me to think of this not as a project, but as a product. The main difference, he reminded me, is that a project has a start and an end. A product doesn’t have an end date. It can always improve.

At the beginning, I thought of this as a “project.” You know? A bunch of us getting together with the vision of sharing food weekly. It was our “Food Sharing Project.”

Before long, I realized that was an old way of thinking about work. When I thought about the food package as a product a lot changed. It became easier to see what was needed for this product to be useful to the recipient. The quality of this product became clear.

I also watched this video from Mishkin Berteig which encouraged me to think about the ways in which this package could be run with Scrum. (So far, I am the Product Owner. Now I just need a ScrumMaster and Scrum Team. You never know, maybe this will evolve some day!)

Then I read this article by Mike Caspar which got me thinking about acceptance criteria and the importance of consultation, reflection, learning and planning.

The key learning for me today is that when I think about this service of delivering a weekly care package as a product I see it’s likely it can continue indefinitely, always improving. That really excites me.

It is not a project, but a product and is being organized and delivered using Agile methods.

This is one way that Agile is being used outside of IT with great success.



Please share!

Video: Agile Social Action at a Neighbourhood Level

Learn more about transforming people, process and culture with the Real Agility Program

This post marks the beginning of a new Agile experiment supported by BERTEIG.

Quite simply, the idea is to apply Agile methods and principles outlined in the Agile Manifesto to a social action project at a neighbourhood level.

The objective is to use the empowering principles of Agile to help eliminate the extremes between wealth and poverty.

The approach is to pair up one family who has items to share with another family who is in need in order to provide a weekly care package including food and other basic care supplies.

The sharing takes place in the real world with the delivery of a package weekly but also corresponds to an online platform which allows for the sharing to happen at an sustainable cadence.

The initiative was formally launched three weeks ago and this video is the first which addresses some basic structures of the framework. This video is a bit like a one-person retrospective.

One of the principles of BERTEIG is to strive to create unity and to be of service to humanity. This socio-economic Agile experiment is a way in which BERTEIG is reaching out to help others and contributing towards the advancement of a small neighbourhood moving along the continuum from poverty to prosperity, materially and spiritually.



Please share!

Scrum Product Owner Training: Reflecting on Agile in Community Settings

Learn more about transforming people, process and culture with the Real Agility Program


rachelheadshotThe Certified Product Owner training I attended recently has me reflecting on when I first heard about Agile.

My introduction was in 2012 on one of those really cold, dark wintery nights in the now-famous Fort McMurray, Alberta.

Garry Bertieg had invited me to consult about a challenge we were facing in a community development initiative. I remember it being so cold and dark I didn’t want to leave the house. But I was curious about what innovative team-building technique he wanted to share so I went to check it out.

We weren’t dealing with a business issue. And it wasn’t tech-related. But it was complex and it dealt with many groups, many individuals, and many Institutions. He felt Agile methods could help.

He presented some basic concepts from OpenAgile. He had a large poster board, sticky-notes and Kanban-style columns showing how items can move across the board while in progress on the way to        “done”.Learning Circle - cropped He also presented the Learning Circle Model. I just made so much sense to me instantly. He remarked that he was surprised to see me so receptive to the material so quickly. It just made so much sense. This Learning Circle has formed the foundation of how I work ever since.

It was as though it combined the best of everything I had experienced in teacher’s college, in community development and in serving in community-level leadership roles for a decade.

I started applying what I learned from that 3-hour session immediately and I saw the results instantly.


At the time, I was operating independently, so I didn’t have a manager to run anything through, and I was running a neighbourhood children’s class, responsible for supporting more than a dozen volunteers, teachers, and other coordinators. The OpenAgile model was a perfect fit and I attribute a lot of the success of that neighbourhood class to the framework within OpenAgile.

At the time, I knew nothing of Scrum, Kanban or even the way Agile first evolved from IT software development. I didn’t know any of that. But I started working with Agile methods then and continued until now.

Certified Product Owner Training Took My Understanding To a New Level

Last week I had another agile-style life-changing experience in the Certified Scrum Product Owner training lead by Mishkin Berteig & Jerry Doucett.

I entered the class with an open mind, willing to learn, and eager to apply the learning in whatever ways are applicable in my current circumstances.

At a very foundational level I gained a new understanding and appreciation for the role of the Product Owner in creating the product backlog. I understand that is key.

I also enjoyed the simulation exercise of creating a product. The team I worked with at the table was excellent and worked so well together. At one point, we made this Product Box which demonstrated our vision for our product.Product Owner Simulation - Product Box Example

It was extremely valuable to also understand the way the Product Owner collaborates with  the Scrum Master for the best possible results.

Since I am not currently working with a Scrum team, there are some parts of this learning which are not immediately applicable.

However, the training was exceptional and I came away with a much more thorough understanding of the Product Owner’s role as a whole.

It was a phenomenal experience with an excellent facilitator team.

I’m enjoying the opportunity to learn more and more about positive ways organizations are changing every day, both inside and outside of corporate environments.




Please share!

OpenAgile – Evolving Forward

Learn more about transforming people, process and culture with the Real Agility Program

“Truthfulness is the foundation of all the virtues of the world of humanity”

Many people can see some validity or value in this statement, but it may seem strange to them to incorporate this component into business practices or corporate culture. After all much of what is common practice does not reward or encourage those who choose to be truthful.

But as Bob Dylan so aptly put it, “the times they are a-changin’”.

The environment, our capacities as human beings, and our tools to interact with the world are constantly evolving and growing. Yet much of what we do today is based on assumptions about human nature arrived at hundreds or even thousands of years ago when we had less knowledge and understanding about the world and ourselves. Along with the rest of the universe we are evolving as a human species, as such it only makes sense that our higher understanding and knowledge inform our decisions and practices, so we can keep progressing forward.

OpenAgile recognizes the true nature of humanity and how it can work to create a remarkable world in every endeavour. Scientific discovery is revealing this truth about our nature as well, as the video below so wonderfully illustrates.

The Empathetic Civilization

Be Open, Be Agile, Be Free.

Please share!

Real Agility Program – Recommendations (Assessment and Playbook)

Learn more about transforming people, process and culture with the Real Agility Program

Recommendations IconWe have already written about how Leadership and Delivery Teams operate in a Real Agility Program.  It’s time to look at our Recommendations component: getting started on the right path for Real Agility.

Recommendations = Assessment + Playbook

In the assessment portion of the Recommendations component, we gather information about the current situation at an organization.  This includes everything from detailed practices, processes and tools, to strategies and organizational culture.  This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility.  The Assessment includes an online portion, an on-site portion and an off-site portion.  The assessment work naturally leads to the development of the playbook.

The online assessment requires that each person throughout an organization complete an online survey about corporate culture.  It includes three major sections: existing challenges, sense of urgency, and level of teamwork.  This cultural survey is the foundation of understanding how to be successful with Real Agility.  Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization.  This includes high-level information about the structure of the organization, client and vendor relationships, and staff.  Additional surveys may also be administered to understand other aspects of the organization.  For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.

The onsite portion of the assessment combines in-person interviews and workshops with staff and managers.  Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile.  The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof).  Typically we need a meeting room committed to our consultants for doing interviews.

The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results.  We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc.  We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results.  Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.

Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online.  We also have a number of proprietary tools.

The playbook maps out a path to a successful Real Agility transformation.  It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility.  The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams.  The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results.  Two critical questions that are answered in the Playbook include:

  • What Agile method or methods should we be using and why?
  • What organizational change approach should we take and why?

We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along.  The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.

Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.

Please share!

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

Learn more about transforming people, process and culture with the Real Agility Program

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.


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





Please share!

The Skills Matrix and Performance Evaluation on Agile Teams

Learn more about transforming people, process and culture with the Real Agility Program

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).

Please share!

Be able to explain WHY.

Learn more about transforming people, process and culture with the Real Agility Program

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?“.


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

Please share!

Performance Reviews and Agile Teams – Link

Learn more about transforming people, process and culture with the Real Agility Program

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.

Please share!

Evolution of Agile Methods

Learn more about transforming people, process and culture with the Real Agility Program

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?

Please share!

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

Learn more about transforming people, process and culture with the Real Agility Program

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

Please share!

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

Learn more about transforming people, process and culture with the Real Agility Program

“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

Please share!

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

Learn more about transforming people, process and culture with the Real Agility Program

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.


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!!







Please share!

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

Learn more about transforming people, process and culture with the Real Agility Program

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:

to register: 

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

Please share!

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

Learn more about transforming people, process and culture with the Real Agility Program

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 register:

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

Please share!