Real Agility Program – Leadership Transformation Team

One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

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

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

Using planning poker cards to estimate larger amounts of work (projects)

You have been fighting for the right for your SCRUM or OpenAgile team to do the right thing and allow the TEAM to estimate the work for a project instead of having a PM, senior manager or Committee just make something up for team.  Congratulations…

Then you realize.. Oh, Oh.. Now what ?  How am I going to pull this off ?   You will find all kinds of interesting material on the net with complex formulas and calculations.  There are some well written and recognized books about this topic that can help.  *Agile Estimating and Planning by Mike Cohn is a great place to start.

What is important is that the TEAM should estimate the work required to complete a Sprint (or a Project).  The people doing the work, really know best how long their work will take.

Please remember though, estimation is just that, and should not be cast in stone.  The reality is that at this early stage (or even 1/2 way through a project), there are still many unknowns.

I have used the following approach with as many as approximately 20 team members at the same time.  Maybe it will work for you.

The following procedure assumes you already have a team or teams that are familiar with their velocity and capabilities.

Here’s how it works….

At this early stage, their may be some stories, but likely everything is in Epic or Theme sizes.  Perfect.  You don’t need too much detail.

The Product Owner can give a brief overview of the vision.  You might find it useful to have stakeholders there to listen in and answer questions at this early stage.  This will help them to have an idea already of what obstacles they will need to be removing for the team in the future :->

Then, let the team use what they already know….  Planning Poker Cards.  For an overview of the process, here’s a link for a documented procedure from Mountain Goat Software.

Just change the scale of the cards to be 10 times more.  A 2 would become 20, a 20 would become 200.  The team members already know this system.  It will be easy for them to learn.

So, if your usual numbers are  1,2,3,5,8,13,20,40,100, use the same cards for team voting.  The values would just be 10,20,30,50,80,130,200,400,1000..

You will quickly get an overall estimate for each Epic with numbers from the team.  Just add up the numbers to get an overall number and divide it by the overall velocity and you’ll have some idea of how many sprints of work are left.

More importantly, you will also have started the process of communication among the team members and the Product Owner.  The Product Owner will already know which parts of the project may present challenges to assist them in their overall product planning.

Planning Poker Card Values Image

Card Values Transformed

As estimates really are just that, don’t get excited if the numbers aren’t what you deem to be perfect.  You will have an idea based on existing velocity of the “broad estimate” for the project.

Nothing fancy, works quickly, and gets everybody thinking about the big picture.

NO, it is NOT perfect.  That’s not the idea.  Spending too much time on this won’t necessarily give you more accurate results.  I find that letting everyone know it’s not perfect, removes a lot of pressure and keeps things moving forward.  People will STILL do what’s right and give their opinions on issues that really matter to them. Don’t worry about that ! :->

The hardest part is to keep things moving forward, especially with a larger group.  Be prepared for this or this will take far too long.

You may find that the numbers are Not what you expected and may be higher than you had hoped for.  Think about it this way.  If today, the team is telling you based on what they CURRENTLY know that the project will take 6 months to complete, what is the point of saying, NO, the exact amount of scope will get done in 3 months? As agilists, we know better.  Besides, at this point in time, we really don’t know what the work actually is yet.

Try and avoid having only developers, or only a certain group, and please don’t exclude testers or BA’s.  The idea here is that since you are working cross-functionally, you should be getting a cross-functional vote. Depending on your group size, you may have a hard time getting your WHOLE team involved.  Just resist the temptation to only have a few people.  You’re really missing the benefit.

This process has also worked for me half way through a very large project for a new team (it was not possible to do this at the beginning).   I was fortunate to be in a company that had a great attitude towards the results and used the information obtained to re-align their corporate objectives based on the teams’ input about how long epics would take.  That was a great experience and allowed for a very successful project delivery!

Listen to what the team is telling you!  They have all given their input this way.  There is no reason to think they are wrong about the their capabilities or the capabilities of the company to keep up with them.  The team will also automatically factor in the environment they work in and the corporate development culture.

I’ve successfully used this technique with a group as large as approximately 20 people from a variety of teams working on the same project in the same room with a Product Owner and 2 Stakeholders.

That same team also estimated approximately 6 months worth of epics in just under 2 hours. Longer than that would not likely have produced better results.

The goal isn’t to create procedures here, but to find a way to allow the team to estimate work instead of schedules being handed down to them.  More importantly, it will start the goal of communication between the Team and the Product Owner.

Maybe this approach will work for your team.  If you try this, please let me know how it worked out for you either way.

Mike Caspar

References:

Mike Caspar – Mike Caspar’s Blog

OpenAgile – http://www.openagile.com

Scrum – http://www.scrumalliance.org

Agile Estimating and Planning by Mike Cohn

*Agile Estimating and Planning by Mike Cohn


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

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 Markham November 23-25,2011

We have an upcoming three-day agile training seminar in Markham on November 23-25, 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=988401 

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

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