Friday, December 28, 2012

Transparency - We weren't ready for that!

As many readers have experienced, working towards Agility can be challenging.

Many of us talk about technical details, process, C level executives, managers, change management, culture and a large variety of other things as to why becoming Agile is difficult for a corporation.

Perhaps the real reason is much simpler than we think --->  Transparency.

I believe it is possible that the reason Agility is tough to take in large corporations is Agile's approach to transparency.

Here are some examples (it is important to realize that in an Agile environment, all of the following examples might be very public within the organization).

  • The Product Owner does not know the value of the stories they are presenting to the team and the team rejects them.
  • The team realizes early on in a project that what they are delivering will give no value to the company and it becomes very clear the project has no ROI (Return On Investment).
  • The team cannot complete it's stories because it takes 3 weeks to get a user account on a server.
  • The team keeps track of interruptions and presents the information as a reason for losing 50% of their productivity (this doesn't include the cost of "context-switching").
  • The team reports that because of internal team member conflict (which they are working on), they estimate they lost 30% of this Sprint or Cycle capacity.
  • During the retrospective, the team has figured out that they have two senior level managers giving them opposing goals and report it as something they would like fixed.
  • The company is having problems with a product line and has reported to the team members they are losing market share.
  • There will be a corporate reshuffle and the team members are asked how they wish to re-organize themselves.
I know that there are many more examples that might come up for you.  Consider your own list.

I recall a comment from a previous customer who hit the nail on the head. He said to me after reading a published retrospective...  "We are not ready for this!"

I can't tell you how many times I've heard the phrases "Agile is about transparency", "We want transparency from the team", "We want to do Agile because we are looking for transparency".  Often the assumption is that the team is the one causing delays, acting improperly, slacking off, and the list goes on.  The common misconception is that transparency is only about showing what the team is doing wrong. 

Realistically, it is rarely the case that the team is the cause of all problems.  Of course, they may have some issues. That's part of being human.

What happens almost immediately during a new transition is that things start to become "transparent" and the real causes of delay start to appear.  This is immediately uncomfortable for people who weren't expecting it.  Perhaps in your case, the "transition" is only happening in one small part of the company.  Consider the effects of this transparency where it shows issues in other groups who didn't see it coming!

What can we do about this?  Why not warn them?  Why not give them some training and coaching?

transparency graphic
Why not be honest about the fact that the information coming out of the teams will at times be uncomfortable?

Please, take the opportunity to talk about Agile values in your corporations. If you do not know why Transparency is so vital, please seek out an Agile Coach, Mentor, friend.. Whatever it takes.

The Agile Manifesto has many references that would involve transparency such as "Business people and developers must work together daily throughout the project."  Previously, many problems would not have surfaced which this principle will expose.  

The Scrum Alliance Code-of-Ethics says the following ; "When we make errors or omissions, we take ownership and make corrections promptly. When we discover errors or omissions caused by others, we promptly communicate them to the appropriate individual or body. We accept accountability for any issues resulting from our errors or omissions and any resulting consequences."

OpenAgile has a simple idea about this. It simply indicates it's purpose as follows; "The purpose of OpenAgile is to create an environment in which people are free to express their true nature and capacities to contribute to the betterment of their organization."

By spending a bit of time on this, you can make your transition a bit friendlier.  Once people realize that transparency is expected and what it really means, the change will seem less frightening.

What's making it difficult for many corporations is that we haven't truly explained what will happen when information in the company becomes open and up front.

Remember, transparency is a two-way street!

by Mike Caspar
References : 
Agile Manifesto Principles -
Scrum Alliance Code of Ethics -

Sunday, December 2, 2012

Only one to choose - Choose the Sprint Retrospective or the Reflection and Learning Step of the Engagement Meeting

I've been finding this a recurring question for a while, so I thought I might share some thoughts on the subject.  People have been asking, if you can only do one thing from Scrum or OpenAgile, what would it be?

When deciding what the most important part of your Agile Framework is, think about the Retrospective (Scrum), or the Reflection and Learning part of the Engagement Meeting (OpenAgile).

This meeting is a focused way for an individual, team, community or system to improve through continual learning.

Many corporations who have adopted Scrum have started with procedural parts of Scrum such as the Daily Scrum or the Planning Meeting.  The teams "go through the motions", yet no significant changes are made to the way work is done.  Many team members simply don't grow as individuals this way.

Scrum's Retrospective Meeting is a meeting where team members focus on improvement of themselves, the overall system, or their processes.

Often, the results of the meeting are the discovery of system-wide obstacles. If adjusted, these changes will allow the team to work more efficiently.  Sometimes the meeting may simply expose friction between team members that needs to be worked on (not managed).

The OpenAgile Reflection and Learning Parts of the Engagement Meeting focus on learning about our environment, system, community, and each other. 

By focusing on increasing our capacity to learn, we allow ourselves to be open to new ideas and things to try in our global "system".  As a result, our ability to "be of service" to our community is significantly improved.

The words are slightly different but the idea is similar...

"Let's go back and look at the last period of time we worked together and learn from that.   Based on what we learned, we can do something different next time and see how that works out."  Improvement is incremental, not batched.

If you are a ScrumMaster, or Process Facilitator, consider doing things to make the Retrospective the most important part of your Agile Mindset.

This one simple meeting, has the ability to drive any framework, team, or system to improve quickly.  It also allows continual learning and improvement to continue.

If you really want to have some fun with the meeting as well, some self-improvements to consider includes reading Ester Derby's book, Agile Retrospectives: Making Good Teams Great or taking a course in Innovation Games.

For me at least, it's always great when this meeting is taken seriously by teams and by the company.  The leaps and bounds teams can make are incredible.  This is because they can quickly and easily see what new things they need to learn and what improvement they can make .. now.

Ignoring this important meeting is just way too slow.

by Mike Caspar

References : 

OpenAgile Engagement Meeting -

Sunday, September 16, 2012

Extreme emotion can be normal during a change to high-performance

When an individual reaches a point where they believe they will have to leave an old idea behind to accept what you are teaching them, they can become very openly emotional.

It is very important to realize that some people will have exceptionally aggressive or antagonistic responses as you stretch their mental model of what they understand.

In many companies, should someone becoming emotional, it is somehow forbidden and considered a bad thing.  This response invokes responses from managers of "we need to deal with this problem".

I find this intriguing.  For those of you that are trying to change mindsets away from a command and control environment to a self-organization model, I have some thoughts for you to consider before thinking that something has gone wrong.

All individuals have different knowledge and experiences to drive their ideas. Consider, that for many, they may have only experienced one company and one way, for much of their working lives.

When someone comes close to the edges of the box that makes up their knowledge, it can be common for them to realize they are coming close to a point where their “original” ideas are at question and they may have to leave them behind to move forward. At a minimum, some of those ideas will now be in question.

Previous ideas are a very big part of a person's reality, and has brought them through life to this point.  A new idea does not mean a person needs to abandon previous ones.  The new knowledge needs to be in addition to what they already know.

Remember; What the person knew before was not incorrect.

OpenAgile specifically addresses this by focusing on Learning through it's "Learning Circle" as part of the core framework.

Scrum allows learning through the effective experimentation of a team to try and accomplish and deliver a sprint goal and reflect on the results.

Other frameworks allow learning through constant experimentation and continual improvement.

An environment of trust is absolutely mandatory for this to happen safely. Trust in the team member and trust that the organization will act responsibly while the team member is in the vulnerable place are mandatory.  Without trust, many Agile frameworks will eventually fail.

Emotion can be high when coming out of  a "Mental Box"

If you are trying to help someone to learn something new, remember that extreme emotion is not always bad and is something you should expect.  Extreme emotional outbursts may mean you are making progress.

I think back to when I was a flight instructor.  As part of training, I would push people to the limits of their comfort levels and understanding. They were of course, willing participants, which is important to point out.

There were some parts of flight training that were frightening to many.  The learning was all fine until we would head out into the air.

When it came time to push them-selves to actually use this knowledge, often very abusive and aggressive comments would come from them. They were finally going to cross over the barrier to a point where they knew they would have to leave their old perceptions behind.    

As an instructor, I would allow them to vent, get angry, yell, or even in one case, punch me in flight.  

I learned that when a student reached that “final moment” when they would leave their inhibitions behind and move over the edge to do what they knew they would need to do, they would sometimes be very dangerous.  I learned how to defend myself in the event a student could not take this final step. 

I once had a student reach across the cockpit and put me in a headlock just as he changed his mind immediately AFTER we started to Spin*. Needless to say, this was frightening for the student (and for me!).  

When this happened, I could not panic.  I took control, recovered and allowed the student to talk it out for a bit.  He wanted to try again.  It took about 15 minutes of just flying around looking at scenery until he made the decision to try again.  He eventually did the spin. He is now a proud private pilot who owns his own plane.

After taking that step to realize the old ideas would not allow him to grow, he opened his mind to learn everything there is to know about the new. This is a truly rewarding experience for both the student and for the instructor.

When you are working with managers, team members, executives, project managers, CEOs, CIOs or whomever, remember that when they become very antagonistic and very angry, this may be a sign that they are realizing they are simply reaching the end of their “mental box”. An emotional reaction is a natural, human self-preservation instinct kicking in.

Don’t let it phase you, and most importantly, just be patient and let them work it out. Make sure their past knowledge is considered valid.  That knowledge can be built on.  It is not to be destroyed.

They will either cross or not-cross that barrier. This is not under your control.  It has to be truly up to the person reaching that point.  

For me at least, I find that if someone has finally reached the point where they are becoming aggressive and nasty about their ideas, this can be a good sign.  

Please note, in some cases, the person may just be reaching that point where they will "submit".  This is not a good place to be.  The signs and reactions are similar, so please be careful.  Make sure the individual is willing to participate in the knowledge transfer and growth.

Not everyone will cross over their barrier.  For many people, the past ideas are just too powerful or the person does not feel sufficient trust to allow them to take a chance.

Whether it be the idea of "command and control" vs "servant leadership", or the concept of "working for the team" vs. "working for myself", there are some pretty serious emotional barriers to cross when transitioning to an agile mindset.

I remember having a discussion a long time ago with a very successful businessman called George R. We were discussing what makes or breaks entrepreneurs. He told me "What holds people back is the fear of loss”. It has stuck with me for life. 

This can apply to fear of losing physical possessions of course. It is important to realize this can also apply to ideas.  

Whether you are trying to change and organization or simply help someone learn to work in a high-performance team, remember that many standard “self-preservation” responses are a good sign that you are making progress.  Don’t fear them.  Above all, remain patient.

I know the instinct when we see upset people is to assume we have done something wrong.  This is a normal response and might indicate you are simply doing everything correctly.

Good luck.

by Mike Caspar

References :

Spin - What is a Spin

OpenAgile -
Scrum -  /
Command and Control  : Wikipedia
Servant Leadership -
Self-Organization :  Wikipedia

Sunday, September 2, 2012

VS2010 DBML inadvertently helping teams learn to check in code more often

An important part of development in a team based setting is the ability to quickly and easily check in your code, have it built with something like Jenkins, Cruise Control, Team City or Bamboo, get quick results about the compile, integration tests, unit tests, and so on.  The results need to come quickly to be of any use.

I have seen .NET developers who are new to the ideas have trouble with the concept of writing small bits of code, making sure tests pass and then pushing them to the source repository in small batches (commits).  I should mention, this habit is not restricted to .NET developers only. This is just the topic of the post.

The habit seems to be to work all day then try to do a push at the end of the day.  This can cause some significant merge problems and inevitably, defects during the next compile/build/test cycle.

A team member will pull the days' changes into their workstation and find that nothing compiles.  This problem eventually turns into a habit of doing the end of day commit an hour before the end of work to deal with the likely problems with the merge.

Sometimes, this results in many hours of work being held off "for now" because it is simply too difficult to merge.  The team develops an attitude of "we'll figure it out tomorrow".

In Visual Studio there is an interesting "feature" for managing database interaction called DBML.  DBML is sort of control file or schema mapper to allow .NET developers to easily connect to data using one "connection container" or "data context".  I am sure there are some technical deficiencies with this comment. That's not the point of this post.

A team using the DBML concept will find that the longer they wait to push their code, the worse their problems will be.  The DBML is built in small little cryptic pieces (to the human eye) and becomes almost impossible to merge if two team members have changed it locally.

This means that when you attempt  a merge with Git, Mercurial, SVN, etc., you will find that you will have no choice but to basically keep one person's changes and tell the other person to start from scratch.

If you are in an environment where large amounts of data access are happening and your team is using DBML, you will be constantly changing this file and having merging problems.

Because of this quirk in VS2010, I have seen a team implement a rule "Whoever checks in their code first wins during a merge conflict". The result of this rule is that developers end up checking in often and in smaller batches to ensure their work remains the "keeper" during a DBML merge.

What I find intriguing is that this quirk is inadvertently changing the habits of .NET developers who used distributed repositories to check in their code on a more regular basis.

Mike Caspar

References :

Jenkins -
Cruise Control -
Team City -
Bamboo -
DBML Format -

Sunday, August 26, 2012

Does becoming Agile require Culture Change?

Recently, I have been seriously considering the question of Culture Change in relation to Agile. 

Please consider this example and decide for yourself.  Does this example require culture change.... Yes or No? 

The scenario.

An important part of many Agile frameworks is the concept of the team working on "the most valuable work" for the company or customer.  Another fundamental component is the importance of truthfulness.

You are working with a team that has discovered and acknowledges that the project they are working on will have little or no value to the company when they are finished.  When the project was conceived it made sense.  It no longer does.

The team does what they are trained to do and brings that information to their leaders.  The executives and managers, after carefully reviewing all the facts realize this is true and the project is terminated.

Praise is given and the team is moved on to the next project in the huge list of backlogged projects.

After a few cycles, iterations, sprints, cadences (depending on your preferred agile framework), the team realizes the same is true for their current project.  The project is again cancelled.

As a result of the cancellation of the two projects, several managers will not reach their department objectives for the year and therefore will lose bonus money.

End of Scenario.

Is the team successful?

Is the team successful from an Agile perspective?

If this happened in your organization, what would happen?

What needs to happen to allow the team to do valuable work?

Is a Project Management group being rewarded for finishing projects without consideration for corporate value of the projects?

Are teams rewarded for acting with integrity?

Are managers and executives rewarded for acting with integrity?

Are teams rewarded based on achieving results?

What if those results are no longer appropriate?

Are teams rewarded based on learning and improved capacity to handle future work?

In your own opinion, if the answer to these questions doesn't match your ideal, do you think that you will need to change culture to achieve your perfect answer?

More importantly, do you feel that your corporation wants to adjust what you have discovered? Why? Why not?

I personally think we need to consider this type of situation when deciding if becoming Agile requires culture change or not.  

I put this out there as a question to ask yourself for your own environment and reality.

Happy pondering.

by Mike Caspar

Thursday, August 9, 2012

Information Radiators and the Vogons!

I recently had an interesting discussion with someone while trying to go over the difference between an information radiator and an information refrigerator in an Agile context.

Providing visible and public information to the stakeholders and the company is an important part of Scrum, OpenAgile, or your Agile Framework of choice.

We were discussing the fact that their system where everybody diligently enters all their status updates, burn-down info, obstacles, and so on isn't seen by the Stakeholders or the rest of the company.  The information doesn't serve the intended needs because the stakeholders use a different system to receive updated information.

Then, it came to me.... Think about The Vogons!

In the book, "The Hitchhikers's Guide to the Galaxy", the Vogons are clearing a path through space and destroy Earth to make way for an intergallactic freeway.  Arthur Dent (the human in the story) is outraged that there was no warning before his planet was destroyed.

The response from the Vogon Commander is something along the lines of ..  "It was on display in the bottom of a locked filing cabinet in the planning department in the basement."

The Vogon commander implies that the information was communicated and that it was not the Vogon's fault if Earth didn't do anything with the information.

Make sure you are not a Vogon.  

Just because you post information into a Wiki, Tracker or electronic tool does not mean you are radiating information.

You may be putting information in the system in a format your group can retrieve or see, but that does not mean it is reaching your stakeholders.

Consider letting your stakeholders know what you can provide and then ask them what will help them easily see it.

Mike Caspar

OpenAgile -
Vogons - Hitchkiker's Guide to the Galaxy

Saturday, June 23, 2012

What's in it for me ? It doesn't hurt to put yourself in the other person's shoes.

I have been noticing something when talking with some fellow Agile coaches, and wanted to just pass along a "thought".

Although we cannot always provide an answer to the question "What's in it for me?", when we're talking about an Agile mindset, often we can and ignore the opportunity for an easy win-win situation.  This just requires a bit of a step back from being and Agile Evangelist, to thinking about change initiatives and how knowledge about that topic can help.

A good friend and Agile coach recommended a book by Kotter recently, focusing on organizational change. It got me thinking about myself and how I approach change.  A reference to the book is at the bottom of this post.

Ask yourself, "When I tried to explain the Review Meeting to that executive VP, did I talk about the process of how the meeting works or did I talk with them about how that meeting can help them?  Did I let them know what information they could learn from it, how they could achieve future vision, how they could make strategic plans based on the input and feel like they really know what's going on in their companies ?"

If you're like me, you've often gotten trapped talking about the meeting instead of the intended results.  I find that if I pay attention for cues in the conversation, I can usually catch myself if I'm careful.

When discussion Scrum's Review Meeting with an executive, if I hear myself say something like "the meeting works this way", I trigger myself to say.. "HEY, wrong conversation... that's for training... we're not training here.".  Think about your target audience (your customer).  

I then take a DEEP BREATH, ask the person I am talking to for a moment or a quick break.  I may even say, "Mr or Mrs. Smith, please bear with me.. .I've gotten off track.  I'm not providing you information that's really useful to you.  I will be back in two minutes after I clear my mind.  I want to give you information that is useful to YOU... That's more important to me.".  Be honest.  After all, you're human too.

Many of us find ourselves in situations where we are talking about how Scrum, OpenAgile or any of the other Agile Frameworks work.  We will also be sharing information with C Level executives who are seriously interested in learning more.  

The ironic thing is that many of us talk about how Agile is not about process and is about culture.  Then, when we have the first opportunity to talk to an executive, some how.. many of us end up talking about Process.. .What gives?  

This might be an interesting discussion for another post.  I think it might be related to the USUAL questions asked by a C Level Executive.  We are the ones who need to break our habitual answers.

There is a multitude of sources of information about how change works.  One part of most change initiatives is to put yourself in the other person's shoes and ask.  If I was them "What's in it for me ?". Better yet.... maybe ask them!

Granted, there will not always be something in it for them. It may just require sacrifice.  Nothing is perfect. 

Also, urgency for change has a big impact here and cannot be ignored. 

I find the majority of situations have something in it for the recipient of a request for change.  It seems pointless to me to throw away this 'gift' of a win-win by ignoring the possibility.  

As always, comments welcome.

Mike Caspar


Thursday, March 29, 2012

I am a Business Analyst. Where do I fit on our Scrum team?

Recently, I was chatting with a team member on a newly formed SCRUM team.  Her background is as a Business Analyst (BA).  They are not a customer of mine, just someone I know going through a transition at their company.  I'll call her Sally.

She was concerned that she didn't know if SCRUM was right for her because "In SCRUM there is no Business Analyst". Sally "didn't want to become a developer.  There is too much of a skills gap".  Her words, not mine.

I thought I'd respond to her here and perhaps share some ideas for others that might be going through the same sort of question.  Maybe these ideas will work for you or maybe not.  If more than one person can be helped by reading this, then great.  It's just food for thought.

On a SCRUM team, team members are expected to work on Stories (a piece of functionality or value for the company or customer) as a team.  This means that everyone pitches in to complete tasks to finish the story.  YES, this means you will need to learn SOME development skills. The reality is, if  you're truly working WITH the team, it seems highly unlikely that you wouldn't learn something, just by proximity and osmosis alone.

What should be said though is that if you feel that being on the team means you will become a developer, something is missing from your environment.  The team should be cross-functional.  This implies there are people with different backgrounds and skill-sets coming together to try and deliver a Potentially Deliverable product each Sprint.  It also implies that team members learn more about each other's skill sets.  This to me at least is part of the fun of being in a SCRUM environment.  I love to learn.

You (as a BA), help the team in many ways.  Firstly, you have a natural ability to notice that what is being created is not what the "customer" is looking for.  On an Agile team, you don't need to wait until the entire Sprint is completed to recognize this.  Your abilities are vital during Sprint Planning, during Grooming and during the complete development of every story.  You are a very important part of the product delivery.

As you are working on these stories together as a team, you have the same level of input into the stories as any developer on the team.  You need to be asking yourself, "Why is my team not working on stories together as my input is valuable?" Talk to your team about this.

There is more to software delivery than just writing code.  Agile Testing is a form of QA (that is imperative to successful delivery) and is actually closely related to your existing mind-set.  Perhaps you don't have the technical skills in that area today, but you'll soon discover that if you take the Testing position seriously, it can be more like what you naturally do as a BA than you might expect.

Yes, there are some specific skills to learn (some which might require some development type knowledge).  Professional QA is a career in itself.  I don't want to lessen QA career skills here, just trying to help with a possible solution for you.  The key here is for you to learn this WITH the team's help and for the team to learn from you.  You are in it together (or should be).

As a SCRUM team member, you still need to want to learn the skills of the other team members to become a more rounded person.

However, I  know that even if I spent a year in design school, I would still be just an OK graphics designer, and not an expert.  It's just not in me.

That being said, I still learn what I can about it. I have learned for instance that I should not leave only a 10% space at the top of the page without talking to the graphics person on the team BEFORE I decide to do that.  I have also learned that I should not assume that the page will be white and design everything up front based on this.  This is why we should work TOGETHER.

In a pinch, I could probably pull of reasonable graphic.  I wouldn't be afraid to do it if it was left as a task on a team I was on.  For me, at least, this is part of the fun of SCRUM.  I needed a graphic for this page, and managed to make the graphic on the right :->

Generally, when people say they don't want to try new things, it is because of their Environment, not that they don't want to learn.  This is where you should have your Scrum Masters and / or Coaches help the organization to change to give you the ability to feel comfortable with experimentation.  Experimentation and learning from mistakes is very important to becoming exceptional team members.  You need to be able to learn new things and inspect the results as a team.

Sally, I know you have a passion to help the customer and listen to their needs.  This is ideal for a SCRUM team.  The customer is a VERY important part of the process, and no amount of teamwork will be worth it if the customer won't or can't use the product when the team is done.  This is why there is a such an aggressive requirement to have the Product Owner or Customer's representative there during the very quick development cycle.

Sally, you've told me that the company has not agreed to provide Q.A. people for the team.  As you mentioned, the team is sharing this responsibility.  YOU however, have some very special skills that you already possess; The ability to see the customer's viewpoint.  This is invaluable to the team.  In a SCRUM team, "QA" or testing is a CONSTANT part of the process, not something that happens at the end.  Every screen, every bit of important logic, should be considered from the perspective of testing, both technically and from the user's perspective.  A development team member really shouldn't be writing logic without discussing it with others on the team to make sure that it can be tested and that it makes "business sense" as well.  Think of usability for instance and it's importance.

You already have the goals and aspirations related to quality for the customer.  It may be a natural fit for you to think of yourself as an Agile Tester and learn more about it.

In the book "Agile Testing, A Practical Guide for Testers on Agile Teams", Lisa Crispin and Janet Gregory have the following to say about Agile Testers;
Agile testers see each story or theme from the customer's point of view but also understand technical aspects and limitations related to implementing features.  They can help customers and developers achieve a common language.
Hmm.. Sounds like how BA's think to me.

As your team gets faster (if they work as a team and not individuals), they have the ability to create software Really, Really Fast.  Without the QUALITY part of the equation, your company risks making lots of BAD software, Really, Really Fast.

Since you find yourself in this position, why not consider learning more and just "assuming" the responsibility of improving QA practices on the team (with them knowing so of course).  You already have the emotional desire to think about the customers' desire for quality.  You obviously have SOME technical skills.

This doesn't mean you should be the only one on the team doing this.  Quality is still and should always be a complete team responsibility and you shouldn't become the only person who cares about it on the team.

Testing and the testing mindset is a very important part of software development.  QA professsionals will learn a bit about coding and coders should and will automatically learn about how to think more like a tester.

So, although you have some problems on the team, YOU have the power to work with your team to help yourselves out.  You've told me the team needs QA , and that you all recognize it as an impediment.  This has been going on for several months.  Clearly your management is not listening, which is truly sad.  Perhaps instead of you being frustrated, you could just start to do something else to help the team out.  Try out the book "Agile Testing from Lisa Crispin and Janet Gregory", and see if it inspires you.  Perhaps, try one or two of the ideas from it.  Maybe you'll surprise yourself how much you like it.

Yes, you will still do some occasional coding, but there's NO WAY the team should be delivering software that hasn't been tested at all during development and without the benefit of someone thinking about the customer's view-point from a technical perspective (someone like you are).

Another alternative for you is to pursue the Product Owner role in your organization.  That might work for you as well.  This would be up to you.

After you've tried all these things, you might still find that SCRUM is not for you.  No one ever said it was for EVERYONE, though a team of only pure development really isn't a SCRUM team either, which might be part of your frustration.

You should give yourself a chance to learn the "Agile Tester" idea and see if you can help your team out that way.  The team, and the company should really appreciate it, and you'll have learned some new skills, which could never hurt you :->

Maybe you'll even discover a whole new career path you never saw before!

You're in a big company.  If all else fails, you could always go to a non-Scrum team, or migrate into the Product Owner Role somewhere.  Your company is big enough that you could easily do this.

Another thought, though not pleasant; you MAY be holding the team back by not embracing the idea of cross-functional work, especially if they are all prepared to so and you are not.  I don't believe that's where your mindset is, but I needed to mention it.  If you simply don't want to work with others, learn and share with others, no amount of reading, practice or coaching will change that in you.

Anyone who tells you that Quality and the customer isn't an important part of SCRUM, is seriously missing the point. It's about delivering VALUE.  Software that the customer can't use; likely has no value, other than to your competitor.

Mike Caspar




Saturday, March 17, 2012

Continuing on the path to a "Test Driven Mindset"

In September, 2011, I made a post called "How to Introduce a Test Driven Mindset".  You can read it HERE if you're interested.

I had introduced OpenAgile to a small software development company with team members in Toronto, Montreal and India.  They have been using an iterative approach to development with continued improvements to productivity since then.  At the time, we talked about the concept of thinking in terms of "How are we going to test this" before writing code.

Many people (including developers) have a hard time seeing the benefits of thinking about testing as a way to save time in the development process.  Often, tests are created "after the fact".  Unfortunately, this is often what causes the biggest hurdle to learning the practice.  Trying to write tests for code that was not intended to be tested can be more troublesome than simply learning to create the test first.  There are ways to test legacy code.  I won't get into that here (at the end of this article, I'll put a link to wikepedia about mock objects or "mocking".

Back to the company that inspired this article...

It has been a tremendous help to the company to work on the highest ROI items first and to be moving forward toward their goal of potentially shippable software each cycle (OpenAgile uses cycles for iterations and encourages progress to be made primarily through Learning).

I have been visiting them for a few hours every week for a few months now, and have been reviewing problems they have been having with their application as they crop up.  They modify something and a problem re-occurs from code they fixed weeks ago, or even months ago.

As each cycle goes by, they have a larger and larger list of regression testing to do as the tests are not automated.  They find defects that they have fixed before because of a recent change.  Sound familiar ?

As I introduced the Mindset to them back in September, they knew exactly what I mean with my usual response; "Hey, you know EXACTLY how to improve this situation.  You just need to find a place to start."

I know it is very difficult for someone to immediately jump right on board the testing mindset. It can be a slow road and isn't easy to switch to if you're in fire-fighting mode... One step at a time is better than no progress at all.  

Often, the difficulty is that the idea of Testing is too abstract or not directly related to what the company does to have it make sense.  As defects from the past crop up, just gently bring them up as examples of problems that could be avoided with an Automated Test.

I find that nothing works better than real life examples.

Unfortunately, fixing old defects might be tougher to do as they were likely not designed to be tested.  Start with something easy.  You will find it likely that the team would prefer to start with something easy as well, so this will work out just fine.  You can even get the ball rolling by including the "FIRST" test into their testing environment or Source Control.  That test could simply be to make sure the testing environment works, such as 1+1 should equal to 2, or my favourite, Assert.AreEqual(true, true);

PLEASE be careful and prepared.  If things happen like they did for me at this company, one day they will take you up on your offer and want you to assist them to create a Unit Test.  You should be prepared to help them or, at least know someone who can.

It's a big deal that they are finally willing to give it a try.  Don't lose this wonderful opportunity to help the company out!

by Mike Caspar



Original Post -Sep 2011Introducing a Test Driven Mindset
Test Driven Development
JUNIT (Java)


Tuesday, February 28, 2012

Explaining "Why" is important.

Direction ?

As your Agile adoption grows within the organization, you are going to have to let people know the "why" of the changes that are taking place.

....Read more of my post at

What responsibilities does a Product Owner Have

Please note, the link below does not currently work (Dec 4, 2013).

I have been in touch with the creator of the post in question to let him know about the broken link.

My apologies for any inconvenience.

When the link is returned to normal, I will take away this comment.

Please note, I made this choice instead of having you get an invalid page message.



A fellow Agile Coach, Michael Badali recently made a short, simple post about his ideas about what a Product Owner's responsibilities are.


Saturday, February 18, 2012

Agile Team Knowledge Retrospective - “Feeding the machine for corporate review season”

The following article has been duplicated at as it will disappear from here eventually.

Please update any bookmarks as needed.

For many Agile Teams in large corporations, the teams are being confronted with “Review Season”. No matter how hard Scrum Masters, Coaches or Team members try and change the corporate culture in this regard, the team needs to SURVIVE.

There are many sources of material about why this is not a great practice for the building of high-performance teams, so I won’t get into that here. I’ve put some links at the bottom of this post if you want to read more.

The purpose of this post is to introduce an alternative approach that will allow the team to regularly reflect on its’ own progress (not just once a year, but when the team decides will work for them), and at the same time possibly (PLEASE read…OPTIONALLY) use that knowledge for their inevitable yearly review.

Yellow / Red / Green Cards
Yellow / Red / Green Cards
Please don’t get me wrong. I believe teams should be considered as teams and my preference would be to avoid such a situation.  The reality is that if your organization is transitioning from non-agile to agile or simply considers Agile to be for isolated teams, you will inevitably have to deal with this. It won’t go away until Agile becomes more mature OR it may never go away.

I started thinking about an alternative to just getting all my team members fired for saying NO and came up with this useful approach that seems to allow the team members to be comfortable and grow with each other, and IF THEY WISH, use that information as food for thought for their reviews. I cannot stress this enough. It HAS to be OPTIONAL for team members to use the information for their reviews. The TRUST relationship between team members MUST remain in-tact.

I originally used a method back in the early 90’s to help my team organize itself to complete a large project involving over 100 cities. We needed a way to improve each few weeks to make the project profitable. Self-improvement and learning new skills as we went was important. Every few weeks (usually 3) we got together to review how things were going and to decide what we needed to improve. What we did was take all the necessary skills, wrote them on cards, placed them on the floor and then had discussions about them from each individual about what we saw going on.  It was lots of fun.

I recently saw something similar during an Agile Coaching retreat I participated in with Berteig Consulting.

I had been struggling with how to deal with the inevitable yearly review that was to take place for some newly formed teams in a large company with very strict procedures in place from Human Resources.

I realized that if I combined my experience from the past and with the great reminder from the recent retreat, I could create an exercise that could allow the team members to learn about each other and themselves. At the same time they could receive some “food” or “information” about themselves as it relates to them in their teams for their reviews (that being the secondary purpose). I thought I would try this exercise from my past. It worked well in the 90’s for team, building. Why would it not work now?

The results were wonderful. The team members got to know more about each other, and how the rest of the team felt they could improve to help the team.  MOST IMPORTANTLY, it allowed the team members to express what the felt as INDIVIDUALS.

It was a great learning experience and I think could help many teams out. That’s why I’d like to share the idea here.

It is VERY IMPORTANT that you let the team know that what is learned during this Retrospective will be kept PRIVATE and within the team. Please be VERY open about the fact that you are doing this for the TEAM to improve and for them to learn about each other. Sharing the information is 100% OPTIONAL. DO NOT STAND DOWN ON THIS, or you will lose trust from the team.

Let’s assume you have a team which has been together long enough to start to know each other’s strong and weak points. They know what each team member can do for the team. The team will need to have Stormed already and be prepared to talk openly with each other.

I don’t think this exercise will work with a team who hasn’t gone through storming yet, but I may be wrong. I would simply be nervous to try it with a brand new team where trust has not been established yet. I think the results could be bad for team morale. Therefore, please be careful. If you do try it with a brand new team, please let me know. I’d be interested to know how that worked out (good or bad).

Here are the mechanics. Maybe you’ll find this will work for you.

Team Knowledge Retrospective:

A downloadable version is available in PDF format
by clicking HERE.

Supplies, Rules and Guidelines.
  •  For a team of 7-9, it would take about 1 ½ hours to do with proper discussion. For a team of 5, an hour may be fine. I haven’t tried with more people at the same time.
  •  No one is invited except for individual team members. NO MANAGERS!
  •  Make it clear “Our GOAL : Our INDIVIDUAL Contributions to Team Improvement
  •  Orange 4 X 6 Index Cards (approx. 20 should do). These are used to write “topics”
  •  One Red, Yellow and Green card for each team member. 
On the Orange cards, you’ll need to write some topics for the team to discuss. You’ll need to make up the cards the FIRST time. I suggest you don’t get a manager to write them the first time. They may want to control the cards to serve some purpose instead of just helping the team members to get to know each other. If you can, ask a Scrum Master or someone you trust to make the initial batch of cards. It would be best to ask someone who’s been coaching or WORKING WITH the team for a while as they’ll know what things the team might be struggling with or might be prepared to start learning. Just remember, it’s not about what can help the management, it’s about what can help the team grow (which in turn will help the management). I should note, if you have a good relationship with the managers in your area, DEFINITELY get some feedback from them if you feel it’s appropriate. That will have to be up to you.

Here is a starting batch of cards which might work for a Web Development Team.

Scrum/AgileNetwork ArchitectureFrench Language (I’m Canadian)
Product QualityGetting Business RequirementsDevelopment of System Scripts
Talking to ExecutivesGraphics DesignUser Interface Design
Style SheetsTest Driven DevelopmentMobile Device Programming
Business SkillsAccounting & Finance SkillsCommunication Skills
Public SpeakingOther Programming LanguagesSecurity Design
InfrastructureHigh Volume data storage and video transmission (CDN)Talking to End-Users
DocumentationAutomated Testing & Deployment

Spread these cards out over the floor in a way that the team members can easily walk around and look at them without bumping into each other. They should be close enough though so that they feel they are “in this together”.

A sample orange card
Explain to the team why they are doing this and that the results are TOTALLY PRIVATE and that it MAY or MAY NOT be something they will use for their reviews. It’s important to explain to the team that something like this could be used on an ONGOING BASIS and doesn’t need to be restricted to only once a year.

Let the team know that if they like it, they could do it regularly at their option.  It will not be mandatory.  This allows everyone to be open-minded.

Make it clear there will be 3 ROUNDS.

The first TWO rounds will be for each team member to talk for themselves while the rest of the team listens. The third round, the team member may NOT TALK. The team will talk and the single team member should LISTEN.  There will be a follow-up open discussion if everybody wishes.

Make sure everyone understands.

Then hand out YELLOW Cards. Ask each team member to write the cards as follows;

YELLOW – What new thing do I think I would like to learn that Excites Me that might help the team.

Make sure they write the word YELLOW in the event the cards get photocopied for future use.

Now, ask the team members to walk around looking at the orange cards on the floor for which card BEST represents them as individuals. Re-enforce that individuality is important in an Agile Environment to help the team. All team members are important. Allow enough time for proper reflection while the team members consider their options. Hopefully you have selected some topics which are appropriate to what you have witnessed as being their needs and desires. Remember, this is for the TEAM.

When each person is standing by a card, explain and remind everyone that the goal here is for “us to learn about each other and what our individual goals and needs are. It’s important for the rest of the team members to LISTEN, REALLY listen to what makes your team mates excited. You will learn a lot from each other (something like that)”.

Ask them to write the EXACT wording on the card they are standing over in the SELECTED:  field on the card.  Remind them that these cards are PRIVATE and the NOTES section is JUST FOR THEM.

Keep everyone standing. Start at the right or the left from your perspective. Your selections SHOULD be random and not individual, so left to right or right to left will be fair AND ACCEPTED). IF possible, start with someone that you know will be receptive to this process to start the process off (especially the first time).
Ask each person to explain WHY they chose THAT particular card, explaining to the others to “Please listen. This is important to your team member and can really help the team to learn about each other”.

They MAY look down at their cards and start explaining, which should not be discouraged. The “lifelessness” of the cards is what helps here. They are just objects, not emotions.

There may be a tendency for the individuals to talk to you (as the coach or facilitator). Simply find a kind way or gesture to have them talk to their team members instead. You will need to let everyone know that there is a time limit for each team member. Make it long enough so someone can properly express themselves. 5 minutes should be fine.

If someone wants to pass, let them and give them another opportunity AFTER everyone else has spoken. They may surprise you (and themselves). Hopefully, by now the team members are already comfortable talking openly with each other.

When this is complete; do the SAME thing with the RED cards.

RED - What thing would I like to get better at that the team can help me with.

Repeat what you did for the YELLOW Cards.

Remind them to write RED for photocopy reasons.

Allow the same private reflection and discussion.

For round 3:

Hand out GREEN Cards with the following format:

GREEN – What does the TEAM think I can get better at or learn to help the team.

This time the process is VERY different.

Ask all the team members to SIT DOWN.

Ask for a VOLUNTEER if you can get one to be the FIRST person to try the Green Card.  Ask the first team member to STAY SEATED and ask the rest of the team to Stand-up.

The person who is SEATED should LISTEN VERY CAREFULLY and TAKE NOTES. They may NOT say anything. They are to listen.

The rest of the team will wander around the cards discussing what THEY think the BEST card for the person sitting down is and WHY.

They have 5 minutes!  The team members may ask if there is a special format.  The answer is NO. It is up to the remaining team members to discuss amongst themselves what would be the most appropriate card to select and how to determine this.  The ACT of discussing it amongst themselves will force open discussion amongst the rest of the team members as to what they should select. This MAY start off slowly. Don’t worry. Simply count down every minute to let the team know they must come to a consensus. As the time counts down there will be more and more comments (both positive and negative) from the perspective of the other team members. Encourage the person sitting down to only listen and those that are talking to talk AMONGST THEMSELVES and not to the person sitting down. Under one minute, you MAY need to remind them in smaller time increments.  The team will eventually select something after a considerable amount of open discussion (which of course is the goal).

The GREEN card is a very important part of the process because it allows team members to know what things they can improve or learn from the team's perspective. The time-boxing is important to keep the team focused on POSITIVE discussion and improvements. Some negative feedback may come out, but it will be done with the intention of giving positive feedback to fellow team members.  Remember, the time-boxed goal is something positive.  The conversation should quickly return there.

Please give the “sitter” a chance to write all the notes they want.

Explain that AFTER we are done, each team member can talk about their experience if they wish.

Now, each team member takes turns sitting down and LISTENING to what the team has to say as cards are selected for them.

Some team members may learn of new skills that their team members think they might be good at or should learn that they were not aware of or never considered before.  The results could be total unexpected, which is part of the experience.

What is important here is that the individual has been given their OWN voice twice and been able to listen to the TEAM’s voice once. It seems to be a very happy mix.

When the selection has been made the standing team members explain why they chose what they did to the person sitting down.  You find it easier to just have them say "We have chosen X".  Remember, the person sitting down has already heard the team talk about why.

I find this part of the exercise to be the most intriguing and amazing. In some teams, the members will select skills that complement each other. In some teams they select a skill that the “sitter” never expected. In some cases, members will select based on what the person sitting down originally said they had interest in during the first two rounds.

They all really get to know each other as individuals!  The team learns how their individual desires and capabilities add up to help the whole team.

A few notes:

The reason for writing the EXACT names on the cards is to avoid specifics and to allow for future comparison. Eventually, it should be up to the Team, Scrum Master, or Coach to come up with some new cards if they feel it would be appropriate.

Likely, your managers will want to get involved in this. Deal with that the way you wish. My preference would be to obtain some input from the management and include their ideas IF it would be to the benefit of the team. For me at least, it’s about what the team needs. The management does have needs though as well which should be considered. If you can do it, it might be a good idea to ask for input (if not at first, but for future sessions for sure).

A card such as “Working more overtime” is of course inappropriate. If the manager knew they were trying to break into a new “Wireless” domain in the market, a card such as “Wireless Networks and Technologies” might be a great idea. Maybe no one will pick it. This is also not a bad thing. Perhaps the management needs to know that "Wireless Networks and Technologies" aren’t important to their staff and the company needs to do some education into the corporation’s future path. The message has obviously not been communicated properly. It’s just important the cards stay consistent for a while so there is a point of comparison for TEAM MEMBERS.

There may be some unintended positive results.  The team, Scrum Masters and Coaches now have a “common vocabulary” for discussing team member motivations and ideas.

I found that after this exercise was complete, if I was sitting with a team member and wanted to help them to proceed, I could FIRST ask them “What was your Red Card if you don’t mind me knowing?” It was a great way to make sure that I was in touch with what the individual’s goals actually were instead of mine.

Encourage the teams to do this often. It allows them to really get to know each other as team members and improve as a team.

A happy by-product of this is that they have the OPTION of using that information for their yearly review process to make it less painful for themselves (and their managers).

I hope this method helps your teams to become more effective and to get to know each other better as individual contributors to the common goals of the team.

Mike Caspar, CSM, OA2

Links and references:


Download Instructions as a PDF: Download PDF

Berteig Consulting:



Yearly Reviews and Agile :

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

This document may be reproduced in-tact without modification and retaining the attribution to Mike Caspar, 2012.