Saturday, December 31, 2011

Do not forget. When having Agile Meetings, Managers, Stakeholders and clients have busy schedules as well.

I wanted to make a post about a disturbing trend I've been seeing in different Agile environments.

Agile Methodologies give the team members a certain level of respect and Responsibility.

Team members are empowered to self-organize, reach out of their teams, arrange meeting rooms, and basically Get the Job Done.

Product Owners, Managers, Project Managers, Stakeholders, Clients, and many other people are part of regular communications with team members where there was none before.  This includes but is not limited to the Planning and Review meetings, constant email, voice and personal communication.  This may be a new experience for many team members.  In an environment where SCRUM or OpenAgile is NEW to the organization, this can be even more of a concern.

If for instance, your team has arranged a review meeting for a specific date and time, you REALLY should make a point of being there on time.  After all; you are expecting other people in the organization to show up so they don't slow you down.

If you are a Scrum Master, acting as an OpenAgile Process Facilitator, or simply anybody interested in Agile as a framework, please consider not showing up for meetings on time to be a serious Obstacle or Impediment to success.  

Those that are invited are supporting you and treating you with the necessary respect to allow you to work in an Agile Environment.  The same respect is due in return.

Leaving a VP, CIO, CEO or any stakeholder sitting in a room waiting for 30 to 45 minutes while the team members meander in is not appropriate (and not very wise) in ANY environment.  The difference when applying SCRUM is that this type of behavior, is MUCH MORE OBVIOUS and transparent to the organization.

Those same people you are making wait will some day need to stand in a room to fight for your rights as a team.  They may need to explain to another executive why they should make time out of their busy day to attend a team meeting and put other business off for an hour.

Agile is not an open license to treat others as though their time is not valuable.  The reason an Agile framework is successful is that it allows managers and those that used to "control" you to do other tasks which have their own significance and importance to the company or group you're in.  They are ALSO busy!

Mike Caspar

References :

Monday, December 12, 2011

The Pursuit of True Agility and Jazz Music

A manager I am working with recently sent me this link. I have seen this topic discussed before, but never so nicely worded. Thanks Charles.

It is a discussion about how Jazz music is different than Classical music and how that knowledge could help to understand Agility. Great post. I think we'll hang this on the wall somewhere in the team room. Read more

Friday, December 9, 2011

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

I have recently read a book my brother-in-law let me borrow titled First, break all the rules *1.

It is written based on results of a survey by Gallup of over 60,000 managers at 400 Corporations.  The book is based on written and actual in-person interviews.  It has an interesting concept regarding the difference between Great leaders and Great managers.

In short, the definitions are as as follows;

 -Great Leaders focus OUTWARD.  This includes thinking about how the group, business unit, section, division, corporation, community will interface, operate and thrive in relation to the external world as his/her group moves into the future.   The leader looks for upcoming obstacles, competition, market trends, and opportunities for growth within their realm.  That realm could be at any level down to the smallest business unit or small group of people.

Great Managers focus INWARD. This includes thinking about the personal interaction between the people and businesses in their care.  This might include providing feedback on ways to improve, recommendations for training, guiding career futures, and helping their unit work efficiently as a group.  In some cases, managers will have direct impact on what and how the employees under their care will grow and learn.

I spent some time trying to figure out how to map these ideas to the Scrum Master, Coaching roles and to the Growth Facilitator and Process Facilitator capacities of Open Agile and had some trouble with the mapping.

This got me thinking.

This MAY be the reason why corporations have such a hard time defining the roles and fitting them into their structure.

Where does the OpenAgile Process Facilitator fit?  A Process Facilitator is neither.  Well, maybe more of a manager? 

What about the OpenAgile Growth Facilitator?  Is that capacity more of a "leader"... Hmmm... doesn't quite fit.

The Scrum Master role is even more obscure in this comparison.

The Scrum Master is not managing anyone, yet still enforcing the rules of Scrum, encourages the improvement of skills and agile techniques and assists to protect the team members from outside interference.  These clearly appear at first glance to be Manager attributes.  However, the Scrum Master is not a manager.

The Scrum Master is looking outward for potential obstacles, working to try and grow Agile in the organization and working hard to try and teach others as to its’ goals and purpose.  These appear at first glance to be the role of a leader.  However, the Scrum Master is not a leader.

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

Interesting (to me at least) :-> 

Mike Caspar

Open Agile
*1                       FIRST, Break all the rules; Marcus Buckingham & Curt Coffman

Saturday, October 29, 2011

Be truthful about working in teams! It's not for everyone

I have been thinking about some of the conversations I've had recently and in the past with different team members and realized....there seems to be very little discussion and truthfulness about the reality that high-performance teams are not for everyone. Some people will just never like it, some will tolerate it, some will love it, and some will just simply move on.

So much time is spent on the rah, rah of how great it will be for everyone, we need to remember to pay attention to the natural reactions and concerns of those that have never experienced a high-performance team before.

Speaking as a developer myself, I remember how I started in I.T. back in 1984. Someone presented me with a problem, and I sat in my apartment by myself working my own hours, watching TV, working through the night and generally being a loner.  I do admit, I enjoyed those days.

My company grew and eventually I found myself working with different types of people; developers, marketing types, sales people, accountants, graphic artists and many more.

That's when I discovered something I enjoyed MUCH more.... Working in Teams! 

But what about those that are unsure about what to expect.

My advice... Be TRUTHFUL and LISTEN.

For those that have never worked in a high-performance team environment, the change can be frightening.  Allow new team members to talk openly about their fears and concerns.  Show them that you care.

The concerns may not be real to you but they are definitely real to them!

Consider the following situation;
·        You are working with a new team that has been told they are doing an Adoption.
·        They are comfortable working totally on their own and interface with other team members only when necessary.

Our natural tendency will be to try and minimize their negative feelings or concerns.
After all, we totally believe in Agile and really just want them to come around to our way of thinking.  Instead, allow the person to say what they have to say and then be honest with them.

Explain to them that “Teams are NOT for everyone, and ask them to PLEASE give it a try first and see how you feel about it in a year from now”.

“The goal of the company, me and everyone in the team is that you're here and enjoy it going into the future!  I am here to help you in the transition.”

The LAST thing you want to do is try and convince that person that their fears are not valid.  They are valid to them.  Explain that you are there for them to talk to at any time.
Explain that you believe in your heart that they will never want to go back to a non-agile environment.  Don’t be afraid to talk about your own skepticism when you first started with an Agile team.

I personally find that honesty and truthfulness about the situation is the best way to approach the subject.  The recipient will gain trust in what you say.  After all, if you are willing to be honest about possibly attrition, then they will realize you are being truthful about how things might be if they ride it out.

For me at least, the people who have argued with me the most about joining teams have become my biggest allies when a management change happened and the POSSIBILITY of breaking up the teams even came up in conversation.

My experience is that the honesty and rapport you built up with the person who was "worried", "not sure", "didn't think they would like it", etc. will be beneficial to both of you. The truthfulness you showed about their situation will help that person have a healthy, open-minded view to what will happen next.

Consider how much easier future changes will be when the person is totally aware they may be uncomfortable with them and is willing to give it a try.

Saturday, October 22, 2011

A thought about Verbal vs. Written Communication in Teams

The topic of verbal vs. other forms of communication has come up for me a fair bit recently with a friend of mine trying to keep an off-shore team working efficiently. His teams are using OpenAgile as a framework.

I decided it was time to make a post about the subject.

I came up with this example as a Flight Instructor when explaining to students about the difficulties that air traffic controllers face when talking to pilots on the Radio.  The controllers cannot easily hear inflection in your voice, so the words used are very important and need to be completely accurate and follow specific rules.

This idea is even more significant when discussing the idea of ‘documentation’ or ‘email’ communication between co-workers and/or team members.

Consider the following phrase which is purposely designed to invoke emotion.


Every person who reads this will read it differently!

Let me explain.....  Follow this explanation by saying each of the following OUT LOUD.
The learning will be better that way.

The () characters are the explanation of the different possible interpretation.

  • Put a loud or raised emphasis on the bolded word.
  • Say the rest of the words without emphasis.  
  • Leave a few moments before each attempt.

Here we go…....

I NEVER SAID YOUR WIFE WAS UGLY. (Perhaps implying someone else did)
I NEVER SAID YOUR WIFE WAS UGLY. (out right denial)
I NEVER SAID YOUR WIFE WAS UGLY. (although I may have written it)
I NEVER SAID YOUR WIFE WAS UGLY. (but I may have said someone else's is)
I NEVER SAID YOUR WIFE WAS UGLY. (but perhaps your dog is)
I NEVER SAID YOUR WIFE WAS UGLY. (I said she was beautiful)

As you can see, I may have had an intended purpose for my message to you.  However, your interpretation could be considerably different than what I had hoped for.

Agile Frameworks such as OpenAgile or SCRUM, rely on high-bandwidth communication between team members.

Consider this example next time someone tells you that written communication is as effective as in-person or webcam verbal communication between members in high-performance teams.

If you are in an environment requiring remote communications, make sure that the remote workers have access to high-bandwidth communications capacity within their teams.


Once in a while, I need to re-post this disclaimer.

Any posts or comments in this blog are simply MY PERSONAL OPINION and not to be considered as any recommendations or facts provided by any manufacturer, employer, client or associate.

Monday, September 5, 2011

How to Introduce a Test Driven Mindset

Recently, I was helping a friend of mine introduce OpenAgile into their environment. They are a software development house with some local and some overseas developers. I am occasionally following up with my friend to see how they are doing.

Their development has been going well since adopting Agile practices with the exception of a recurring problem with "returning bugs".

A bug will be discovered, fixed, and then several weeks later will show up again after some other modifications.  This is a sure sign that Test Driven Development is not happening.

Consider the following:

  • There is a master data entry screen called "Shipment Entry".  The first field on the form has a "Shipper" field that allows the entry of a Shipper Code.

  • If you press CTRL-N, you Should get a sorted list of Company Names ordered by CompanyName, paged 20 at a time, with a smaller selection if some of the characters of the company name have been filled out.  The resulting list should appear within 3 seconds.

  • Today you downloaded the code, recompiled and find that the drop down does not sort anymore.

  • You know that you have fixed this before.

  • Introduce the Test Driven Development Mindset.

    Instead of opening a ticket, sending an email, complaining or whatever your process is, consider trying the following and introducing something like this into your source / version control.

    Shipment Entry Screen Tests
    Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
    Shipper Field has "ABC", CTRL-N pressed List Appears (filtered to show all companies containing "ABC" in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
    Shipper Field has an invalid entry "INVALID", CTRL-N pressed Within 3 seconds, a pop-up appears indicating "NO COMPANY FOUND", the shipper field is blanked and the cursor is returned to that location. The popup disappears.

    If any developer works on that screen, before checking in, they need to do all the tests on the SHIPMENT ENTRY TESTS document to ensure they have not broken anything.

    Don't get me wrong. The idea is not to document the entire screen up front! Try to avoid designing the ENTIRE UI up front in this way. That has it's own non-agile problems. This is just an easy way to introduce future changes using a different mindset.

    In my example above, there is a field called "Mode of Transport". It currently shows a list of numbers which internal employees "KNOW" from years of experience with the application. When that number is selected, it gets converted into something like "MAIL", "COURIER", when it is printed on the final document. Your team has agreed to do work to have it show the appropriate labels in a drop down on the screen.

    Traditionally (non-test mindset), you would send out an email or open up an issue with a request for this change. Then, the cycle will continue again. As time goes by, you will always need to re-check this is working properly.

    Try something like this instead:

    When you have finished your planning and have decided this "story" or "feature" will be introduced to this cycle or Sprint, simply modify this document as follows;

    Shipment Entry Screen Tests
    Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
    Shipper Field has "ABC", CTRL-N pressed List Appears (filtered to show all companies containing "ABC" in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
    Shipper Field has an invalid entry "INVALID", CTRL-N pressed Within 3 seconds, a pop-up appears indicating "NO COMPANY FOUND", the shipper field is blanked and the cursor is returned to that location. The popup disappears.
    Mode of Transport Entry into Field Within 1 second, when entering this field, a drop-down list appears show full descriptions, sorted alphabetically by Mode of Transport.

    Granted, the tests will eventually become cumbersome. However, please remember that someone will eventually be testing these screens and find these bugs in a never ending circle. My friend found that every morning they were having to go through all the screens to see what "new things" were broken.

    Why not just try to get it right during your Cycle or Sprint ?

    In the above example, as soon as someone takes on this task, they will have a failing test (Red), they will do what they need to do to get the test to pass (Green), and then will adjust the code to be efficient (Re-factor).

    Although Test Driven Development is better done at other places in the code, this is a great way to introduce the "Mindset" into your team.

    Someone will eventually say "This is getting to be a hassle. Can we automate it somehow?", which as an Agile person is exactly the words you eventually want to hear.

    Maybe now, you can start to introduce it at the Unit Test, or Functional Test or whatever level is appropriate to your organization. There are some more formal ways of doing TDD such as Extreme Programming (XP).

    The important thing is that your company will have shifted to a Test Driven Mindset.

    The quality of your product will increase and stay that way and the need to go back and fix old bugs in a never ending cycle can soon be a thing of the past.

    Sunday, August 21, 2011

    Where should I sit?

    Inevitably, there will be some change to your team.  Someone will leave or perhaps you will have new members joining you.

    Either way, you will be asked the question "Where should I sit?".

    Do not take this question lightly.  You have the opportunity to make significant changes with the addition or departure of a team member.

    There are many different types of personalities in a team.  Because of this, you cannot realistically expect the same personal interactions between people sitting next to each other.

    More importantly though, it is your responsibility as a Scrum Master, Mentor or Coach to consider the positive adjustments which can be made during this great opportunity for change.

    A simple example to get you thinking about this could be....

    • You have a developer sitting at an end station with a slightly restricted view from the rest of the team.
    • This team member does not ask for help when he or she needs it.
    • You will be adding a developer to your team.

    Trying to talk to the developer who does not ask for assistance, may help.  However, why not consider using this opportunity to solve this problem in a different way.

    If the developer is moved to a more central location, they will not be as separated from the group.  Perhaps this would give them more opportunity to ask for help, increase their communication level with peers, and if you are lucky, the other team members will more easily recognize that this is happening an spur this person on to get them to ask for help.

    So, where do you put a new developer ?... Certainly not off at the end by themselves.  The new person will feel isolated, and will have a harder time integrating.

    The team is already a very close unit and has gone through the team development stages of Forming, Storming, Norming, and Performing.  With the addition of the new team member, this cycle will start again and will make it even harder for them if they are on their own at the end of the seating layout.

    Reminding the team of the four stages of team development before a new person comes on board can be a big help.  It reminds all team members of how hard it is to integrate new members and the likely result of the addition.

    Many people can get attached to their desks or workstations.  Therefore, moving people around in a traditional environment can be a painful experience.  In an Agile team, life is about change, adapting, adjusting to what is happening and making positive changes to improve productivity and enjoyment.

    As team members move locations, they will learn different skills and ideas from the person sitting next to them.  It will also be common place to adjust as necessary.

    Changing team member locations also helps change things up and gets rid of complacency.  A danger for an Agile Team is no longer attempting to make changes and progress because everything is "fine" or "perfect".  If you are hearing these things from your team in Review or Retrospective meetings, perhaps it is time to change desks just to get change happening again.

    There may be other personality or non-team type things you wish to address.  Instead of bringing that person into an office and talking to them, you could solve things by simply changing desk locations.

    Better yet.....  If you have a team that has embraces and practices Consultative Decision Making, why not ask the Team where the new person should sit to be most effective!


    Scrum Master - Scrum Alliance
    Consultative Decision Making -
    Open Agile Institute
    The four stages of team development

    Monday, August 1, 2011

    What if your first cycle ends up with Zero Story Points Completed?

    I recently introduced a small software development company to the ideas of Agile development, the culture of Agile, and of course some of the fundamentals of working in incremental steps.  We focused specifically on OpenAgile.

    They started their first cycle with great enthusiasm and with as much attention to detail as possible, but still ended up completing zero story points in their first cycle. Is this is a disaster ? The short answer... NO.

    The company has gone through two major releases based on non-agile methods with limited success. One of the owners of the company has been a long time friend and we discussed doing some Agile training with his employees to "see how they felt" about learning about OpenAgile.

    There were no commitments made to it. The idea of "Hey, let's learn about this and see if it's right for our organization" was the goal. All the team members were told that the company was considering (with emphasis on considering) switching to OpenAgile and would not do it if everyone didn't feel like it was worth the effort and made sense for them. It was stressed that OpenAgile is not a silver bullet and may not be right for them. The effort was purely exploratory in nature.

    As this company is in software development, Agile development easily made sense for them. They were so excited by the OpenAgile training, the developers and the owners decided to immediately abandon their existing plans for development and refactor.  The fact they felt they could do this shows true management leadership and support for the process.

    I have to congratulate my friend for his courage in supporting his team.

    The team determined that they were working on functionality which would not provide the greatest Return on Investment and decided to adjust their priorities accordingly.

    A great deal of our time was spent during the training on the ideas of Consultative Decision Making and encouraging openness between those involved in the process. All team members are encouraged to be open about their opinions during planning and if they find something wrong during the cycle, to speak out.

    I find that having management and stakeholder support and encouragement in the process is almost mandatory for Agile to work. Without the understanding from the owners of the company, the culture required to make it work will inevitably cause friction "around the edges" of the Agile team.

    We spent time on the concepts of ROI (return on investment) and how to apply it to estimating, planning, re-estimating, and selected work. In using OpenAgile, we want to work on the tasks that give us the biggest value over effort factor or ROI.

    We followed the OpenAgile syllabus. As an OpenAgile trainer and mentor, I had easy access to material to teach in an organized fashion.  Their environment is complicated by owners in multiple cities and developers in 3 different cities including an overseas component.

    Openness about the potential pitfalls of remote teams made a big difference to the attitudes of those taking the training and the final outcome. Learning OpenAgile, Scrum, XP Programming, or any Agile process is difficult enough without adding the component of two remote teams and overseas development.

    Many people leave their OpenAgile training realizing that it is a very effective framework and are anxious to get rolling. Because this company and the team decided to continue with OpenAgile, they started the preparations for the first cycle to begin the following week (after a long weekend break).

    The cycle started, cards were created as Story Points, and the work began in earnest. They had many surprises. I had been unavailable through their first cycle and had very little ability to keep up with how they were doing because of a new Scrum Team I was working with. In retrospect, I am glad I was not there to give advice. They did fine on their own :->

    In true Agile form, they figured out on their own what was going wrong and when I talked to the owner several weeks later I found out that they had already determined their mistakes.

    The team was actively taking steps to improve the next cycle.

    If senior managers encourage the right environment and let the team self-organize... you know what.. they likely will :->

    Things that went poorly

    • Two days into the cycle, some of their overseas developers went "to visit family". They did not realize at the time, this was local code for "going on holidays". I heard from the owner later that if they had not asked why they did not get responses to emails, they would not have known the other developers were away.
    • The Stories were Too Big. Because of the combination of the new way of doing things and the excitement about how much could get done as an Agile team, the team bit off more than they could chew.
    • Attempts at Test Driven Development did not go well.
    • The first two week cycle stretched to 3 weeks because the team didn't want to have Zero velocity as they felt this was a failure
    • One display bug crept into the first demo related to two different ways of refreshing data on the screen

    Things that went well

    • The team talked regularly about how they were doing and worked on regular status updates to determine where they were during the cycle.  This is also how they found out about the missing developers.
    • The owners and managers had an active involvement in helping to remove obstacles.
    • The team found an intriguing way to determine how many story points they could actually commit to in future cycles.
    • The team figured out how to deal with code sharing and peer review type issues related to being at opposite ends of the earth.
    • The team stayed together and focused on the goal of creating potentially deliverable product
    • They were able to successfully work on two simultaneous streams of work on different parts of the system.
    • During the demo, the team was able to demo functionality that could potentially be brought to a customer after only two cycles.


    I had a discussion with the owner recently and he told me they all sat down and realized their mistakes of their first cycle. They consider OpenAgile to be a success.

    The team was so worried about not completing story points, they considered it to be a failure to not finish at the appropriate time. You need to let newcomers realize that not completing all the story points of the first cycle may happen.  This can be compounded by added complexities of your working environment or project.

    Since they were pushing to get the points completed, they were sacrificing quality. They were rushing because they knew they had gone past the end of the cycle and it was causing more problems each day it continued. Thankfully, they stopped the cycle and decided to do the right thing and demo where they were and talk about their progress.

    They simply took on too much work, didn't account for all the other overheads of a new team setup and issues that would take place with their remote environments. This did not mean failure. They learned how to re-organize themselves for future cycles.

    With the support of the owner and a little bit of moral support from myself, the team realized they had accomplished a great deal already in their first cycle.

    They realized they need to put some better controls on the holiday schedules of the remote teams overseas or at a minimum find out what is expected in this regard.

    The team realizes it has a deficiency with Test Driven Development and is working on plans to allocate some time for training on this very important task. Perhaps their one bug from the first demo may not have been there with Test Driven Development in place. They will continue to work toward improving this.

    One of the great things to come out of their first cycle.... A potentially deliverable product within the first two cycles!

    When I reviewed this with the owner he told me the completed work is already faster and better than their previous system which took 5 years to write. Considering the remote component they are dealing with, this is truly great news for them. Their first cycle has produced software which can now simply grow organically.

    Some advice here which I shared with my friend.. Make sure that you have at least one story that can be finished in the next cycle, no matter how small.  Consider it of huge Value to the Agile process.

    You need to provide some positive feedback for the team members now.  This does not mean the team should agree to less work than they think they can accomplish. Simply encourage some work that can be completed to be included in the next cycle.

    For my friend, although they completed zero story points in the first cycle, they are happy to know that if they just adjust the size of their stories for more attainable results and use what they learned from the first cycle, OpenAgile will work out well for them.

    The concepts of Consultative Decision Making, Continuous Learning and the Learning Circle allowed them to truly excel and will allow them to continue to do so into the future.

    They are looking forward to shipping their new product in record time :->

    One comment that was made to me was something along the lines of "Hey Mike, this reminds me of when we used to work together in the garage when we started the company. We all worked together on whatever needed to be done. That's what made us successful in the first place.".... Hmmmm.

    Mike Caspar, CSM, OA2/5

    References: OpenAgile -

    Sunday, July 10, 2011

    Remember that Agile is about Quality and Business Value

    Recently, I had an interesting discussion with a companion about Agile Processes and the need for corporations, communities or groups to change their approach to planning and doing work.   We were discussing using OpenAgile as a Framework.

    The person I was talking to told me that their group (Artists) were already used to and embraced the idea of shared responsibility, self-organization, mutual respect and open discussion to get things done. OpenAgile (as well as Scrum) require open communication and truthfulness to be effective tools for self-organization.

    My friend then told me how it made sense in the Art Community but it would be hard for Financially minded people to believe in what Agile was about and that it would be even harder for financially oriented educators (ie: Universities and Colleges) to change their minds about teaching Agile processes as a primary part of the education system.

    Then it struck me.

    For many people, they hear FIRST about the need to share work, how the organization changes, how people are treated better and all the usual comments.

    I realized I need to change my approach with these types of people to first discuss how agile processes work to benefit Business Value and Quality. My 15 second elevator speech should start with these ideas and not the other way around.

    I don't know of any business leader, financial manager, non-profit CEO or educator that would think it to be a bad idea if I said to them "Listen, I would like to show you a way to do the most valuable things first, with exceptional quality while at the same time consistently getting better at it.  Oh, and as a by-product, you will also have more engaged, long-term staff.  What do you say ?".

    We must admit that OpenAgile (or any other Agile process) is not a silver bullet to be used everywhere for all groups.  I have however found that after teaching about iterative work and the IDEA of Business Value and Return on Investment, even a "non-agile" team can still benefit from some of the procedures or "routines" of a fixed cycle of learning and it's heartbeat.

    All of the new ways of doing things including culture shift, team based work, etc. would be unfortunate for a business without first remembering that the purpose is to provide Quality and at the same time provide the items that have the most VALUE to the organization.

    Quality is an inherited part of the process of going Agile. As more discussion happens and all people in the team have input into the process, inevitably, you should end up with a better result. The customer has more direct input into the final product as it is being created, therefore helping to achieve a result that everyone is happy with.

    The real goal to business is this Quality, and the way to get there is all these things that Agile asks us to do, through a continual process of learning.

    Business Value. This means different things to many people. Where you are using OpenAgile, Scrum, XP, Pomodoro, remember, the goal of all of these is to work on the tasks that will provide the company or organization to most Business Benefit First.

    When coupled with the idea of Return on Investment, the reasons are just far too compelling to an organization to ignore. After all, no organization of any type can afford to exert effort with no return at all in the form of artifacts of some sort.  Every organization is there to create some kind of result (value) in its' chosen field.

    Most organizations have many different opinions and reasons for considering one item more valuable than another. You will likely find that most people think ALL of their backlogged items are of equal value to a project or company.

    The idea of doing work based on Return on Investment takes some of the emotion out of this process to allow work that is clearly more beneficial to the group to take precedence.

    When a task is determined to be of lower value (not because of just value, but work for value) doesn't make it into this cycle, it MAY well be classified as a higher Value for the next cycle, and therefore, it's Return of Value / Work may be higher and bring it up the work scale through this process.

    There are several ways to accomplish this. One of the easiest is by breaking the item to be done into smaller pieces. It's Value will remain the same, but the work (effort) required to complete that smaller piece will be less.  Therefore, the new smaller task will have a higher Return on Investment and be done sooner.

    The idea is that true business value is what is provided first with many competing priorities. Most of us don't have the ability to just add two or three more teams when more work comes along, so there needs to be some logical process to deal with this.

    For my friend in the Arts who is wondering about the Financial Elite having a hard time doing a mental shift towards Agile processes instead of Waterfall processes, consider the conversation about Return on Investment and Quality of the Final product as your starting point. THEN let them know, "Oh ya. you'll also end up with less turnover and happier employees". :->

    Mike Caspar

    References :

    OpenAgile -
    Scrum -
    Pomodoro -
    XP -

    Sunday, June 19, 2011

    WHY? .... Such a valuable question

    Recently I was watching a situation with a development team where a very important question seemed to be forgotten... WHY ?  This got me thinking about the countless times I have seen work done for no apparent reason than it's "On The Wishlist", "We have a card for it", or "Because Customer Service Says So".

    Many times I have seen features get created where at the end of the release, the final user of the feature says, "Oh, we haven't needed it to do that for about 3 months now".  This part of the requirements is long gone.

    This brings me back to Waterfall Methodology and something I would expect to see. With it's linear approach to the Software Development Cycle, it is almost to be expected that there will be some waste of this nature.  It is just an expected part of the process if you have a long development cycle.

    However, using an Agile Methodology such as Scrum or OpenAgile, this should simply not happen. Agile methodologies are based on Communication.  This communication is paramount during the Sprint or Cycle but is absolutely mandatory during the planning meeting. A team cannot simply be given a list of instructions to follow.  The team needs to understand what their Goal is.

    In Scrum, the Product Owner is responsible for guiding the team as to which features should be queued up next based on Return on Investment (which generally means actually needed).

    In OpenAgile, the team has a similar approach of consultation with the "end user' and the planning of work based on Return of Value, and plan appropriately.

    Although in Scrum and OpenAgile, there is discussion about Return on Investment, Value, bug free code, Test Driven Development, etc. there often appears to be little discussion about the idea of why we are doing something.

    User Stories, if done correctly can significantly improve this problem because the "story" needs to have a goal as to who benefits.  We are doing this Feature for this "x" to get this benefit.

    It is however, the responsibility of a Team to ask "Why would someone want to do this ?", or "Why are we updating this information in the first place". Often, the insights are very revealing.

    Let's take a simple example.

    I the late 80's, I was working as a developer with a company where the company's approach was to provide the developers a "requirement" , choose a developer and send them off to do the work (pre-Scrum days).

    The developer was to modify a Stored Procedure to go through a table and update every 3rd record in the table to be 50% higher.  It was a fairly complex procedure and a developer at this company spent almost a week re-writing the procedure and getting it implemented. The development team sat down with the engineers and customer and developed a method of testing and verification, backups of the database were made and the implementation work began.

    No one asked Why.

    Several weeks later a similar request was made in a different part of the system. I spent some time with the developers and encouraged them to ask Why the first modification was made.  The answer was "That is what Sherry said to we should do.  The customers are yelling and this is what we need to do to fix it".

    Those of you using Scrum or OpenAgile are probably already cringing and thinking.. Gees... you could write a book just on this one paragraph alone.  I'll leave that for another day :->

    The actual problem was there was a different part of the system which updated the tables based on Quarterly Results.  This was the actual reason every 3rd record in the table was wrong.  That procedure was incorrect and shared by other parts of the system.

    If someone had not stepped in, this cycle of fixing the by-product of the defect could have gone on for many more months.

    I convinced the owner to change the procedures to allow the developers to ask questions as a team before work was queued up. I simply asked for this one simple right.

    A few months later, the overall bug rate of the application went down, customer complaints went down and the development team started to feel engaged and part of the process.  It was a different place after that.  People enjoyed working there.

    As part of the planning stage of your Sprint or Cycle, please consider asking questions such as

    -Why are we changing the Field Size from 80 Characters to 250 Characters ?
    -Why should the system need a procedure to update these types of records .. Doesn't the system do it properly ?
    -Why would we want to force through Credit Card Transactions without the CVV Code (the security number) ?
    - Why are we making a whole new authentication system ?
    - How did this become a requirement ?

    This type of question is not intended to be a confrontational thing!  Often those requesting the features may feel that you are being confrontational.  Remain calm, and make sure to let the requester know this is a standard part of your process and not a question of their power or knowledge.  The goal is to get knowledge, and not to figure out who is right or wrong.

    After discussing it with the person, you may find they do not have a true understanding of why they are requesting the feature or change.  It is possible the idea of what or how to do it will change just from the communication alone (which is when you want it to happen.. not after it's done).  The discussion may also allow the product to be better than they originally envisioned.

    OpenAgile has a term called "Consultatative Decision Making".  It is the idea that decisions are made based on consultation and discussion with all those involved that may have valuable input to making a decision.

    Scrum also values discussion and communication as a fundamental part of Development.

    The FIRST value of the Manifesto for Agile Software Development is "Individuals and Interactions over processes and tools"

    In the case of the example above, we chose to fix the stored procedure which was creating the bad data and wrote a one-time script to adjust the corrupted records. We never had to revisit this problem again.

    It sounds simple enough, but the basic premise of WHY is absolutely mandatory to this process or all decision making will be based on following instructions blindly with no sense of ownership by the team.

    Just a thought.

    Mike Caspar, CSM, OA2, ITIL v3, ATPL

    References :

    Scrum -
    OpenAgile -
    Manifesto for Agile Software Development -

    Wednesday, June 1, 2011

    Why is hardware being forgotten by development companies?

    This week I met someone while on a personal trip who is in the software business.  His company writes software for a very specialized vertical and from everything he said to me, they are an innovative company and do all the right things including empowering their teams to self-organize, regular training for the staff and generally a great working atmosphere.

    The company has still been struggling with getting their product to be "deeper" (his word) for their client base.

    I was again reminded of a post of mine from a while ago encouraging or providing cross-training or at least some knowledge to bridge the barriers between the software group and the hardware group (link at the bottom of this post).  In my environment, I've been fortunate to have a network admin sitting with our team.  It has prevented many potential problems.

    Having been involved in the infrastructure part of IT as well as development, I knew of at least a few products almost immediately that could make his product more compelling to his customers.  To my surprise, I found out his company was only looking at software improvements to their application.  He told me how they are continually developing new features but are not considering running on any new platforms.

    I mentioned a few technology (hardware) improvements he could consider and I know that by the time he gets home this weekend, he will have taken a look and passed the information on to his team.  These improvements could immediately add significant customer retention and usability to his product.

    From our discussion, it was also evident that his team would enjoy the challenge of some new platforms to keep encouraged about the future. I'm sure that by the time he reads this, he'll have some of these technologies in hand :->

    As Agile practitioners, it seems, we are so focused on improving our software development cycle, our specific development tasks, our daily or hourly builds, our programming skills, and how we create story points, sometimes we seem to lose track of the big picture... What is the customer going to use it on?  This should be fundamental to every developer's thought processes.

    Think to yourself,  "HEY, should we be seeing if our software could run on some of the new technologies out there such as Microsoft Surface, some of the new Wireless Devices, or even benefit somehow from new 3D technologies coming out"?

    I like to think that developers who are empowered with information about hardware can think of all kinds of ways to use it.

    If you're on an Agile Team or managing one, ask to learn something about the hardware in your environments.  Consider some "slack" in your Sprint or some work breaks in your Cycle to allow team members to learn something about new Infrastructure or Hardware products.

    Think for a moment if your company is writing software for the Web, the power of a deep understanding of how a load balancer actually works, or my personal favorite, the .NET Cache.

    Let it be the teams' choice of which products though. That will give the best motivation and most likely will be the most enjoyment for everyone.

    It will broaden your horizons and perhaps give your team ideas you never knew could even be possible.

    If we always just wait for a Marketing Person or Product Owner to come up with interesting ideas, where's the fun in that ?

    Mike Caspar

    References :
    My previous post - Infrastructure Knowledge for Developers
    3D example - Sony 360Degree viewer prototype
    Microsoft Surface - Microsoft Surface Web Site
    Slack - A good article about slack in XP by James Shore
    Sprint - Scrum Alliance
    Cycle - Open Agile

    Sunday, May 22, 2011

    A great example of agile style teamwork in a non-software environment

    I am regularly asked for examples of where Agile Practices could be used that are not related to software development.

    I recently came across this video and just had to share the link to it.

    The company encourages all team members to participate, keeps things time-boxed and makes appropriate use of subject matter experts.

    It's awesome to see what can be done in 5 days.

    Friday, May 13, 2011

    Teams are important when doing Agile .. Not just processes !

    (This is a motivational story about teams).

    Scrum, OpenAgile, Whatever your flavour of Agile, there are rules, procedures and guidelines to follow.

    Consider them as Frameworks to work with. Many ideas are different between them, and each Framework has different uses with an organization. There are however, a few things they have in common..Process guidelines, Cycles or Iterations, and an emphasis on Team Based work or Team self-organization.

    Over the years I have discovered that whenever Process is involved, there is a huge temptation to talk about processes and cycles and forget about the people who need to follow them. The Team. Without them, none of these things can take place.

    I am not talking about "calling" a team a team, but simply just "having" them.

    It seems like such a small distinction, but really, the results are very different. Some interesting books on this topic include; "The Orange Revolution" by Adrian Gostick and Chester Elton. , and The Wisdom of Teams: Creating the High-Performance Organization" by J. R. Katzenbach, Douglas K. Smith

    I started my company back in 1984 and never realized at first, just how important the contributions of more than one person could make to the outcome of a project. Over time I learned that teams are (to me at least), the only way to grow and keep customers happy.

    Learning and getting used to the ideas were not easy at first and many mistakes were made, but in the end, I am so glad I stuck it out and kept working on it.

    I was recently reminded of a team story I can share where my team truly performed beyond all expectations and wanted to pass it along as a sort of "just believe in it" kind of message to those that are interested.

    Here's the story....

    In 90's, I ran an Internet Service Provider Business. It came about because of a process I had realized would work for Ocean Transport Companies where EDI data could be transmitted along with normal email and be sent over the internet (the days of $ 800 / month invoices for 2400 Baud Connections to the Internet).

    Through the process of meeting new clients, I met the director the Canadian division of a worldwide Shipping company and sold him on the idea. He has offices in Toronto, Montreal and Vancouver with partners in those cities and was part of a larger worldwide organization headquartered in Antwerp, Belgium.

    Local partnerships were setup in countries where the company did business. At the time, they had approximately 115 offices around the world, in North America, South America, Africa, Asia and the Middle East. Canada was one of those "sub-companies".

    The services were working very well in Canada and eventually I was invited to attend a partners meeting in Miami to review the process with managers, owners and stakeholders from North and South America as well as the CEO , who was based in Antwerp, Belgium.

    I did a demonstration for the group members there and was presented a great opportunity. The CEO from Antwerp asked me "How long would it take you to get my 750+ employees in Antwerp so they can have internet email as a pilot project for the group ?". My answer to him was that I believed we could pull it off in a few days (which would result in it being completed before our 4 day meeting in Miami).

    Now comes the great part... Late that afternoon, I made a phone call to the junior support person and asked "Roy, could you please do me a favour and see if you guys can find a way to get the customers' network in Antwerp onto our system as quickly as you can. "Sure" was the response I got. That was the extent of our conversation.

    I could not have asked for a better team!

    The next morning while we were arriving at the pool ready to start the day, the CEO from Antwerp came out with a big grin on his face and showed everyone an email he had received overnight to his new internet email account through our service.

    It seems that not only did the installation get done overnight, but a large number of the Antwerp staff were already sending and receiving messages through the new service.

    I could never have pulled this off on my own and could never have had this happen if the team was not empowered to make decisions.

    I am a firm believer that if you give the employees the power to make positive contributions to the company, it's simple.... They will.

    Within a few months, I was invited to a two week meeting in Cape Town, South Africa with the owners and managers of all the other International offices and did the same review.

    Because of the success of the team and the implementation, we started on a large project to integrate more than 100 offices around the world.

    Our team managed the installation, implementation and integration of all these offices together with teams from the client's IT department. The entire system was implemented well below the original budget estimates and in approximately half the original estimated time.

    I eventually moved on to other things and am still great friends with the Canadian Director. The company was eventually sold to a larger organization.

    As far as I know much of the initial "design" is still in place and being used including their own EDI standard.

    Of course, as technology has changed, some of the mechanics of transmission have changed, but the project is still considered a success many years later and is the foundation for most of their current communication environment.

    I could never have accomplished this without such a great team who really was concerned about doing the best possible job for the customer.

    References :
    -The Orange Revolution - Adrian Gostick and Chester Elton
    -The Wisdom of Teams - J. R. Katzenbach, Douglas K. Smith
    -Open Agile -
    -Scrum -

    Saturday, April 30, 2011

    All you need is a bit of patience. Just be consistent in your message.

    As many who have tried know, an Agile Transformation in a company is not always an easy process.  Although most people at first are keen to participate in the idea of "changing" the company culture and working environment to "something better", many do not realize how much work it can actually be.

    For some of you, you will be fortunate enough to be in an "Agile" environment already.

    Perhaps you are using OpenAgile, or Scrum. You may be using a unique variation such as the Pomodoro technique.

    For those of you that are new to the idea of Agile Processes, no matter what your flavor of framework or tool, there is something you will not be able to avoid.  Politics.

    There is no getting around this.  Agile transformations are about change in an organization and not just change in one small section of the company.

    Although many Agile teams start as "pilot projects", even in such small situations, the effect on the departments or culture at the "edges" of even the smallest teams can start to cause ripple effects in an organization.

    The first secret is to acknowledge and accept that this is going to happen.  Life will be easier for you this way. The job of any one assisting with an Agile implementation is to provide honest information and advice to help those who will be directly or indirectly impacted.

    Don't think you will be able to just hide in development and not be noticed.  Be prepared with slides, web site links, and open to talking about your processes and ideas with anyone who wants to know.  You must be transparent and open about what you are trying to accomplish.

    OpenAgile for instance is defined as a "Learning System" because it deals with the realities that no one can work in a bubble and that more than just the "development team" needs to be involved in Agile practices for them to work.  The entire organization will be learning with you.

    Scrum has a well defined set of guidelines to follow in regards to the development process and is ideal for new software development projects.

    Lean is a more gentle approach to changing an organization in small, progressive steps.

    Don't kid yourself.  No matter how small the changes will be, there will be resistance from someone, somewhere, from where you least expected it.

    The important thing to remember is what your goals are. The goal of the framework is an open and honest discussion between all those involved in your organization and general culture shift to a blameless, team based shift in thinking.

    However, what is the real goal here? Happy customers, happy employees, and therefore, a profitable, progressive organization.  You must remember the purpose is not to make teams, but to make a good product for the customer. Sometimes, you may find it hard to remember.

    I recently read The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials) by Jon R. Katzenbach and Douglas K. Smith. It clearly explains, with examples, how an organization with the courage to change their culture can really benefit from an overall culture shift towards Consultatative Decision-Making and team work based approaches.

    Consistently, companies who simply "say" they have teams under-perform those that actually "just have teams".  One type of company has them by edict or decree, and the other just has them because the culture is that way.  The ones with the naturally team based cultures do much better financially. Hmm..interesting.

    Change is usually started by some kind of need to change because things aren't working out "the old way".

    Buggy software, unhappy customers, late releases...Whatever the pain, the results are always a "desire to change".

    Those who have the courage to admit they need to change, should be applauded.  If you are new to Agile and reading this, please pat yourselves on the back for having the courage to learn more.

    Now, it should be "easy" to stay on the path if you keep at it.  The act of Starting is the first big step. Congratulations!

    One thing you will find as you proceed is a continual list of "it won't work because of this", "it won't work because of that".  But, hey, you're not selling snake oil here.  You're talking about people in an organization taking control of their work and working together for the best solution possible for the company and it's customers.  Keep it simple.

    Agile processes are just that ... Processes..  They are not there to replace common sense. Agile is not a silver bullet to cure a company's culture.  That part of things is still a human thing and will take time.  Please don't think of Agile as a cure for a bad culture.  It is simply a way to help the culture to change.

    To me at least, what is important is a consistent message.  I believe this is the key to helping an organization to be an Agile one.

    Let's take the Daily Scrum (for Scrum teams).   I worked with a company where the Daily Scrum was considered a waste of time and a nuisance for those involved (at first).

    The daily scrum is a quick recap of where everyone on the team is.  For more information about the Daily Scrum, just do a quick search.  There is an abundance of information about it.  Try the Scrum Alliance for definitive information.

    At this company, the owners and senior managers considered the scrum to be a nuisance. The senior developer of the team found it to be a hassle.  Then, after a few weeks of doing daily scrums, any team member could be asked by someone passing in the hall what was going on and that person could easily tell them what the status of the project was.  There are many other advantages to the scrum, but that's not what this article is about. Maybe another time.

    When I first started at this company, there was a weekly "developer meeting" which at first was the only way to exchange information.  It was generally 2 hours/week.  The team was now doing daily scrums and having small "mini-chats" (for lack of a better word) occasionally when needed.  Team members knew from the Scrums what was going on and who needed help with what and then self-organized to solve their problems and arranged "mini-chats" as needed to help each other out.

    The "weekly 2 hour developer meeting" just became a thing of the past.  The team just stopped having them.

    Waiting until the end of the week was far too cumbersome for something they could get from a 10 minute scrum and occasional "mini-chats".  The team had unknowingly switched into a mode where they practiced regular consultative decision-making and regular re-assessment of their situation.

    Then a remarkable thing happened.

    One day, I was in a meeting, and the senior developer who at first was reluctant, banged on the window of the board room I was sitting in for me to come to the 10:00 AM Scrum which was 2 minutes away. I excused myself from the meeting and returned approx. 13 minutes later. The owner of the company said "Why do you do those daily meetings.  They are such a waste of time.  You have that big Developer Meeting every Friday".  

    My response was "I'm sorry, but we don't need to waste our time with that big 2 hour meeting every Friday anymore... We haven't needed them for a few cycles now".  

    What a remarkable experience!  In one quick step, and after considerable pain, not only was it evident that the senior developer embraced the Agile Scrum Meeting, but also the owner who was previously unsure suddenly came to realize that the team was far more effective than he knew and he hadn't even noticed the shift.

    The developer culture had changed to a more team based one without his knowing. All team members knew what was happening and Expected to be kept in the loop from now on.

    The key is, keep doing it ! Be consistent.  If you've implemented a standard Agile practice, stick with it.

    Be realistic though. There will be people who consider it to be "stupid" and there will be people who don't want to participate.  As a new implementor, NEVER humiliate anyone in the process.  Simply encourage open discussion and ask everyone to contribute.  At first, people will be shy or nervous about this.  Over time, it will be the norm to participate.

    The point is that as time passes, people and things change. The new processes will become Common Place and not so foreign and people will start to appreciate the fact their opinions are important and they have an impact on the bottom line of the company and the customer.  This is what drives people to be happy and succeed.

    Then, with a bit of luck and perseverance, someone in a different department will say "Hey, I think that seems like a good idea. Tell me more". "Do you think this Agile stuff might work in sales?" might be the kind of question you suddenly receive.  Do yourself a favor and be prepared for this with some links to a few Agile Methodologies at-hand!

    This is your opportunity to introduce the new "culture" into a different part of the company.

    With a bit of patience, others will come on board.  It will be a great experience for you once you have others helping out.

    The day will come when someone will try and remove an Agile process somewhere in the organization and team members will lobby for their cause.  This is the day you will know...  I have succeeded with step 1... Getting started !

    From here forward, it's just a matter of consistently trying to improve things one cycle or iteration at a time, and watching things get better for the customers, employees, and of course, the stakeholders.

    If I can give one last bit of advice.  Please do a bit of research before implementing something.  Ideally, you want the teams to come up with how to do their daily work, not yourself.  Let any process be the team's process, not yours. Of course, if you have a new team to Agile, you will need to help them get started.

    Consider your job as one of just guidance and coaching. That will work the best.

    Review your environment carefully before deciding about methodology and do some reading or contact a coach about the differences. Should you be using Scrum, OpenAgile, XP, Lean, etc? Think about it carefully.  They have different levels of organizational change and are for different applications.  Use Wisely. :->

    If you're courageous enough and have an experienced Agile team, why not ask the team which Agile Methodology will work best for them?  I personally enjoy learning something new all the time. :->

    Mike Caspar, CSM, OpenAgile Certificate Holder, ATPL

    References :

    Sunday, April 17, 2011

    Stress-Free Priority Meetings using Planning Poker Cards

    For many of you, there will be instances where Scrum or Agile is something a company is trying but does not really buy into or understand yet. I would like to start by saying.  There is hope!

    The  following story is about implementing Planning Poker in Priority Meetings at the senior management level using the OpenAgile's Open Learning System. Perhaps it could help you introduce Agile to different parts of your organization.

    For those types of companies, Agile Development processes can be introduced and progress made with very little effort on your part.  You won’t get the full benefit, but at least people will get to know Agile as a great way of making real progress in an organization.

    Consider the following situation.... You work for a company that has "heard" of Agile and is allowing you to implement whatever you can in regards to Agile for the Development Team "as long as it doesn't affect other parts of the company too much".

    If you're like me, you've likely heard this more than a few times.

    I recently had an opportunity to find a new way to introduce Agile Processes to senior managers who are not really familiar with the processes and also are not willing to put the time in to learn them.

    I'd like to pass on an idea about how you could possibly make some small headway in regards to Planning.
    Imagine you are working at a company where there are several owners or stakeholders responsible for the future "work backlog" of features for your environment.

    Generally, when planning sessions take place, it involves an aggressive battle over who will get what feature first, what is more important (systems, back-end, front end, graphics, this enhancement, that enhancement).. You all know the drill.

    I had many such meetings with the stakeholders of a company where I had the opportunity to introduce Planning Poker Cards to these meetings with great success.

    Here’s how....

    About once every 1 or 2 months, a “priorities meeting" was scheduled for a Wednesday afternoon.  After successfully implementing Agile process for the development team, it was time to help the rest of the company out.

    I prepared by doing a few things;

    - Prepared pictures of existing Scrum Rooms to show how developers and planning boards would eventually look (thanks to Mishkin Berteig of Berteig Consulting for providing additional examples).

    Of course, I made sure of standard things such as making sure the PowerPoint will work on the equipment in the meeting room. When it came time for the presentation, I knew it would work. It's hard to show how productive your processes are if you can’t get yourself properly organized.

    -I made sure I had a deck of Planning Poker Cards available.

    -I explained to the Stakeholders that I would like to do something to "take the emotion out" of the planning process and make sure everyone's opinion is heard and valued.  I explained how this process was intended to make the planning a very business-like process, and a way for us to quickly get through what was generally a long, several meeting process in one easy step.

    -I asked them to trust me (which remarkably goes a long way), and said, "I would like to show you this to try and move the meeting along, take out the emotion and have us end up with  the best ROI (Return on Investment) in future.  I asked if they would agree to give it a try.

    I made sure to warn them about the process of Forming, Storming, Norming, and Performing and mentioned that if they had interest they could look it up on Wikipedia.

    At first, there was little interest in learning or seeing the processes because of course anything about "Agile Stuff...has nothing to do with Senior Management", so it was all a matter of "Let's get down to it" as to not waste time.

    I took about 20 items from the queue and converted them to Index Cards and put them on the table.
    I asked them to find the least valuable item to get done (there are literally hundreds of backlogged items). This alone seemed like it might take a considerable amount of time, so I decided to take a slightly different approach.

    I waited for an index card that I knew I could get agreement on as being of fairly low value and had my starting point.  There may have been lower items, but this could safely be agreed upon by everyone as a low priority or low value item. This process works well as it's usually easier for people to agree on what's not important or valuable. I’m not sure why... But hey, it works!

    It took only a few cards and although the process was not in "strict adherence" to the no negotiation and no showing your cards rules, in this case it was VERY effective.

    The owners of the company prioritized BY VALUE several hundred feature requests in just over 2 hours. I think it’s astounding that by just letting them make up their own system with what I introduced to them, they also were able to self-organize, agree on a different approach, and be successful with their own way of doing things. All I needed to do was introduce them to the tools.

    A few times during the cycle, I needed to re-affirm the process was about VALUE only and not about how long these would take. This seemed to be a large stumbling block at first, but eventually it was accepted. I explained that the development team would be the estimated (Investment) part later.  We would divide their value (return) / by the developers estimates (investment) and the system would work itself out by providing a general Return on Investment Calculation.

    They asked me about what would happen with all the cards... And, now the opportunity to show pictures of Scrum Rooms or Agile Rooms presented itself.

    The managers were very happy with idea that they could "adjust priorities" many releases in advance.  This for them, was a big bonus.  I explained that once we have big boards with all the User Stories on them, it would benefit everyone.

    - Everyone in the company could go to the board and see what features were going to be coming soon.  This turned out to be extremely motivating for the Sales People.  The idea of knowing what at least was being Planned was exciting to them.  Of course, I explained to them and the sales manager that there were no guarantees of what would get done if at all, but at least they would know if any of their specific requests were even in the pipeline at all.

    - The senior management have always been wondering how the Development Team was doing.  This was the ideal solution.  A big giant board that everyone can understand at a glance easily solves this. Such a simple technique and yet so powerful!

    - An idea how the current release is going.  As Scrum or OpenAgile practitioners, we all know the value of this type of information is amazing.  To know how far in the cycle you are based on simply looking at the Board is so simple.

    - In the past, the development team generally knew what was coming up only 1 or 2 releases before it was time to do the work.  Knowing what's coming down the pipe avoids potential code conflicts, systems conflicts, marketing conflicts, and generally keeps everyone motivated and excited about the future.

    - An un-expected side effect which I was not expecting was that there was a developer who was worried about future work.  Seeing hundreds of cards in the queue of work solved that problem.  As we all know, lists  of future work can usually be never ending :->

    Teams can then start estimating the Work portion using the same system.  What you end up with is ROI (value over investment) for your queued up work.  The company may not live with it, but it gives a simple starting place for everyone to discuss openly.

    Another real benefit is that the emotional roller coaster of settings priorities is much less a factor with this type of process. Everyone has agreed as a team to the Value and everyone has agreed as a team to the Estimates, so there’s really nothing other than pure politics to stop the plan from working now.

    I was pleased that at the end of the first attempt at doing this, there was an overwhelmingly positive response.
    There were a few surprises.  For instance, one of the managers wanted to be in the Estimating meeting with the developers to Ensure we "get the right answers".  However, I needed to stand firm.  Again, I asked them to trust me and simply said "No, it won't work that way, sorry... I DO promise, though that  if there is something we don't understand, we'll consult you."... The Stakeholder was happy with that.

    In reality, all that manager was worried about was that we might consider one of their tasks less important or overestimate the intention and therefore overestimate the time it would take to complete, and therefore, lower the ROI on it.  That owner wanted to ensure that a very specific high priority project got put into the queue.
    It is after all their company.  We all need to remember that owners need to have some rights as well <grin>.
    In my case, I know that what might happen is that one or some of the items may end up overstepping the process due to factors outside the teams’ control.

    This is a reality of working in a smaller development environment... actually... in reality, many environments.
    However, I still consider this a major breakthrough for several reasons.

    1 - Even if a few items bypassed the process at least the several hundred other features and tasks did not.  Who can complain about that!

    2 - The owners were now in the "frame of mind" that tasks can be easily be classified as to value.
    At first it was difficult for them to specify value for large features because they believed they might be huge projects and they didn't want to send the team on a huge development task and risk losing other important features that were already in the queue.

    I explained to them to not worry about this as the ROI formula will actually make these projects less of an ROI at THIS time.  As they want to move the bigger cards closer to the upcoming release, we will break them into smaller pieces in the same fashion and eventually those parts of the system would be worked on as the smaller parts would have potentially higher ROI’s.

    This of course, made sense to them.  The key here is that huge tasks should be split into smaller tasks as they get moved on the Planning Board, Information Radiator or whatever you want to call it.  As items move closer to the release cycle, their value should naturally be increasing as well.  Then, upcoming features can be re-sequenced and prepared to get injected into the development process using another planning cycle.
    All the time, it's about Value for Work performed..... This is of course what being in business is all about.
    Some values are about taking care of long-term customers, some are purely political and some are just about making sure the system doesn't crash. Value is about the overall impact to the health of the organization.
    Planning cards make this a non-emotional event.

    I knew the system was working because a funny thing happened. Several days after the first planning cycle, I received notification of new Feature Requests from clients and our support department with some unusual coding on it.

    "The ABC type of customers are looking for this feature in the product;  It's something we really should consider doing soon... We've talked about it and think it should be at card level 8 or 13”.

    This to me was a great thing to see!

    For those of you who don't know;  Scrum or OpenAgile Planning Poker cards are purposely set up to have a non-uniform number sequence to avoid mathematical calculations and exact figures.  They are about relative value to other each other and not fixed numbers.

    The key is to keep it simple and remind everyone using the cards that this is not intended to be a perfect estimation.  This is a relative estimation of value or work.

    The fact that the stakeholders had started using this terminology showed that they not only understand that process but truly see its’ value.

    One complaint from the past had always been that everything has been either High Priority, Medium Priority or Low Priority.  Planning Poker Cards have helped them to take the emotion out of the Priority process and ultimately give them Many Levels of Value Priority in a simple way.

    Perhaps planning poker might help in your environment to help set priorities, not just for development but for any set of complicated project.

    Many of us think of Planning Poker as a developer only thing, but as you can see from this story it can be used as an effective tool for any process.  Give it a try and you might just be surprised at how stress-free of a process it can really be for your priority meetings.

    The read about the specifics of Agile Planning Poker, try Wikipedia.

    To find out more about OpenAgile and its’ flexibilities regarding release, or cycle planning, go to

    by Mike Caspar, CSM, Open Agile Certificate Holder