Sunday, March 30, 2014

Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it.

As many of you know, the Sprint Review or Demo is a fundamental part of the Scrum Framework. This "inspect" and "adapt" for the product is paramount to the ability to adjust and move forward.

If you are facilitating the discussion about when your review is going to be every Sprint, consider the stakeholders and their ability to show up for your review before making that decision as a team.

In my travels, I am often faced with a team that is trying to decide on the day and time of the week to finish off their sprints and do demos.  There is much written about the day of the week, morning, afternoon, over the weekend, etc.  There are many discussions related to what next; The Retrospective and how the retrospective timing is very important to a team's ability to grow and get better.

Consider that the Sprint Review is the one time that the Scrum Process specifically interacts outside the team with different parts of the business. 

The reality today is that if you are trying to follow Scrum in an enterprise, you will likely not fit perfectly into existing corporate systems.  

There are two approaches you could follow;

- Abandon the fundamentals of Scrum with the fixed cycle that is so important to its' rhythm.

- Stick with Scrum as intended and strive to find a time that works best for most of the people.  

Simply declaring "We are doing Scrum and stakeholders have to show on Friday's at 4:00 PM to see our demo or they don't care about us or our product" doesn't seem to me to be considering Scrum's Values..  Respect for starters.

Scrum is a Framework that helps to build Trust in the Organization.  The team has the ability to self-organize.  Think about this comment. It is also possible for a team to self-organize themselves into an antagonistic and confrontational part of the business.

There are many other considerations for the Sprint Review or Demo that relate to team dynamics, building of trust, feedback loops, transparency of progress, etc. A quick internet search will help guide you in that way.

If you are like me, you may have been asked to help a team determine a Sprint Length. Part of that decision includes deciding what day the Review will be and if it will be in the morning or afternoon.

I strongly encourage that you have an open dialogue with your teams about when your stakeholders actually can show up for the review.  If you are in an enterprise this can be even more challenging.  

When a team sets a review day and time that has no basis on the reality of their stakeholders being able to come, it is hard to say later "the business doesn't support us. They never show up for the demo".

I have included an example of where teams can go wrong. 

You need to focus on keeping the same day and time every sprint or you will lose much of the benefit of the "heartbeat" of Scrum. 

Consider the following scenario;

A team with one week Sprints decides to have Planning on Monday mornings and the Review/Demo on Friday afternoon at 4:00 PM.

Sounds OK right?

In an Enterprise, Fridays are typically the day that the following happen;
  • Executives and Managers are in meetings giving their "weekly status reports".
  • Managers are doing the "golf thing" as a part of their jobs
  • Leaders are networking at pubs
  • People are off early on Friday's due to "summer hours" allowing them to leave at noon on Fridays.
  • the list goes on ... 

Scrum is hard enough to do already without the added complications of not considering the implications of the selected time for the Review or Demo. It is important.

I believe in helping teams to consider what will allow them to be the most successful in their environments.

The reality is that many teams are in non-perfect environments and should do whatever they can to stick with Scrum as designed.

Team dynamics can be changed by the team's interaction with people "around the edges". Learn from that and do what you can to not have to change the basics of the Scrum Framework.  

At a minimum, it doesn't make sense to have your review at the EXACT time your Primary Stakeholder has no choice but to be in a weekly meeting in a remote office.  Doing so shows lack of respect for them and frankly, for yourselves.  You are practically guaranteeing that you are not going to get what was intended for this important Scrum ceremony.

The Sprint Review or Demo is your Primary opportunity to show your progress to stakeholders so they know real status and can be part of the process.  It is in fact, the intended time to do this.

I do not advocate changing the days due to an occasional scheduling conflict. Remember; you cannot please everyone all the time.  That is not the intent.  

If you are in a new environment, you have the ability to find out a bit about the corporate cycle before choosing your review date.

If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.

Please, for the sake of your team(s)....

When considering when your Sprint will end, 
think of the ability of your stakeholders 
to actually show up once in a while!

Stakeholders are people too.  They don't want to let the team down either.

If you are fortunate enough to be in an environment where everyone comes together to see the review and demo as part of what is going on normally in the company, then this won't apply to you of course.  

However, if you are in a "transitioning" or "imperfect" environment, ... have the discussion.

Mike Caspar
Passionate About Agile


Monday, February 17, 2014

Who says we are not high-performing?

"Let me help you to achieve high-performance" the coach says.

"Who said we are not high-performing?" is the response.

Since 1989 when I started to build my first team, I have experienced some huge variations in performance and quality. I mention these two factors specifically for a reason; Having one without the other isn't really high-performance is it? This is of course my take on it.

When we determine if a Agile team is high-performing or not, are we clouding that decision based on our own view of the world?  Is it appropriate?  On the other hand, Is it appropriate to ignore our past experiences?

With almost every transformation or adoption comes a point where a team starts to declare. "We are high-performing". Others in the company do not agree.

The difficulty is related to the reality that people see through different "lenses". We all have experiences that shape our vision of the truth.

Stephen Covey writes in his book "The 7 habits of highly effective people",
Valuing the differences is the essence of synergy-the mental, the emotional, the psychological differences between people. And to key to valuing those differences is to realize that all people see the world, not as it is, but as they are.
I have worked with teams who truly feel that in their context, they are high-performing, while others see "mediocre". Who are we to take that away from them?  Perhaps they worked hard to get where they are.

I believe that motivated people can truly accomplish great things. To me, helping them find that extended reality is part of my job. My experience tells me it's possible.

The thing is... That is "my vision" of the world. I admit that as a person I can have pretty high-expectations of people. It's partly my upbringing and skills. It's part of my driving personality toward excellence.

My view of the world is also biased by the fact that I have worked with some truly exceptional people. Because of that, I tend to see unlimited potential in others. I feel blessed to have seen what can be done with the right mindset.

Consider; What happens if the people I am working with are already 200% or 300% more effective than they were a year ago, or simply since I started working with them.

What if they already have gone well beyond what they knew in the past and are consistently delivering value? When do those people have the right to call themselves "high-performing"?

Is it when some chart says so?  Is it when some manager says so?  Or worse... is it when I say so.  Gees...  I hope not.

I believe that high-performance is an attitude, not a number.

 It is a desire to improve,
a desire to push oneself beyond your abilities, 
to constantly learn new things,
 and to work toward mastery in the delivery
of value to the customer.

The following principles clearly state what is important in an Agile context and should be factored into the determination of high-performance for an Agile Team.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Continuous attention to technical excellence and good design enhances agility.

If a team is delivering large amounts of code but is not addressing the above concepts, are they high-performing? 

If the team cannot "continually deliver valuable software" because the code is so badly written that even the smallest changes make the team fear any changes, are they high-performing?

If the team works fast but never pays attention to "technical excellence and good design", are they high-performing?

Too often, I see a quest for Story Points or a manager pushing to meet a "fixed schedule" without the most important discussion taking place.  "Are we delivering real or lasting quality to the customer"?

Realize that the concept of "high-performance" depends entirely on the people, organization, culture and how much "Agility" is embraced.

For me at least, no Agile team can call themselves high-performing if what they create doesn't serve the client's current and future needs. That to me is just "doing work quickly"... A sad substitute for actual high-performance.

Remember, in some cases; your teams may already consider themselves high-performing.  They likely see through a different "lens" than you do.  Treat them like human beings and realize they may have already achieved what they consider to be their nirvana. 

I have experienced some extremely technical team members who are masters at their skills... Yet, what they deliver to the customer is just horrible. I have also worked with what would be called a "mediocre" skill set but what they have delivered, the customer truly enjoys. I ask you... Who is the better performer?

Double check your determinations about "high-performance" and ensure you are not factoring your own "view" before determining if a team is a high-performing Agile team. 

Keep it simple; use the manifesto. It may show you which teams truly are high-performing and which ones are not. The results may surprise you and show that your "personal lens" is skewing your decision.

Mike Caspar
Passionate About Agile


The 7 habits of highly effective people 
The Agile Manifesto

Sunday, December 15, 2013

Lean Start Up versus Entrepreneurial Spirit

Something has been bothering me for a while about the Lean Start-up revolution that seems to be happening. It's not so much about Lean Start-up but of some of the interpretations I have been hearing from peers.

My inquisitive nature and desire to constantly learn keeps me asking more.

The intent of this post is not to disparage a movement that clearly has business value and at a minimum asks people to be responsible for their decisions and not to over-create before receiving feedback.  

Actually, my goal is to support that movement as a good approach to initial product development by asking some experts in the field to openly consider the effects on Entrepreneur Spirit. This open dialogue to me can only add credibility.

One part of Lean Start-up that I have been hearing regularly is that you are "trying" something out before investing too much money into it.  This is a natural evolution of some of the concepts we work toward on a regular basis. For instance, the idea of "not following a plan" from the Agile Manifesto, or the experience of a constant feedback loop.

Some people have been telling me that a sort of "market trial" is done to see how people will react, and if the response isn't good, the start-up is stopped as being unmarketable and then terminated.

This has been a new "change" I've heard as an evolution from something that used to be about receiving early feedback and making appropriate adjustments. I used to hear about "delivering what people want".  That has recently changed in tone to "killing something before it starts".

Please consider that it might not always be the right thing to do to simply kill an idea because of initial feedback. I am "nervous" about the notion of allowing initial "market" feedback to negatively effect Entrepreneurial Spirit.

From what I have read and from peers I have spoken with, it is more about creating as little as possible to get initial feedback to decide what to do next. Awesome! 

I know that Lean Start-up is so much more, but just as in the Agile movement, there are "versions", I am concerned about an ongoing interpretation of using it to "determine start-up viability".

I think if this was the only approach in our history, we would not have many things that exist today;

Penicillin, the telephone, and the airplane are ideas that immediately come to mind. The way some people are approaching Lean Start-up as a "kill a product after feedback", these inventions would have never continued into reality.

I wonder, with this interpretation, would we have stopped making progress as a society? Imagine if this approach was used for Galileo or DaVinci's ideas?

As much as I appreciate the concept of non-waste, I am concerned that people will "blindly" follow a framework that (from some recent explanations I have received) appears to discourage risk-taking at the onset.

I believe that entrepreneurial vision should not be ignored.  Many entrepreneurs are willing to lose it all for their dreams and to give them a go.  
Please, do not try to take the entrepreneurial mindset from our society! 

If an entrepreneur did not have the willingness to risk it all "on a hunch or belief", that same entrepreneur would have a hard time helping other people to share their passion. This blind ambition and drive are an important part of life.  Without that drive and only "facts", it would be hard for an Entrepreneur to be willing to risk as much as they do.

Perhaps, instead of trying to avoid the risk of failure, we should focus on making it safer for this type of person to take risks. This is after all part of the philosophy of embracing agility. We value failure and learn from it. Actually, we encourage it to some extent.

I learned a long time ago that "fear of loss" is one of the greatest anti-motivators to innovation. 

Needing to test all your hypothesis first and ignoring your vision to what seems to be sort of a "group think" exercise.  People who blindly follow this idea will be left short of true innovation. I do not believe this is the intent of Lean Start-up.

I would be sad to find that no one ever risks anything anymore as we move forward. Instead of removing all risk, let's focus on helping people to work together to share in the risk or make it less painful for those that have risked and lost. I admire the person who is willing to lose everything for their dream.

Shared failures are important to life and evolution.  

I have done things that I know a Lean Start-up only approach to my ideas would have told me would never work. I know this for sure! Against all odds (and advice), I have been fortunate to have lived in a massive house in the country contrary to what I was told by initial market suggested would happen. I have also lived in my car for the same reason.

Ask yourself...

"Do I know anything in the market today 
that others would have said will never sell?".

Although I find the concept of Minimal Viable Product to be paramount to removal of waste and absolutely value the prospect of early and constant feedback, I have a personal problem with using the initial feedback to totally kill an idea. 

Please, let's not turn this truly awesome idea (and the intent of Lean-Start-up ) into something that kills creativity and innovation by accident.

I personally couldn't live with myself if I never failed at anything. It keeps me alive and improving. 

Also, there is the inevitable reality that an entrepreneur will likely just ignore us all anyways and do what they think it best in light of the information that's out there.  The reality is that this might all be moot anyway :->

Let entrepreneurs be entrepreneurs! We need them....

Especially the ones that are willing to fail no matter what others tell them!

Mike Caspar
Passionate About Agile

Wednesday, December 4, 2013

Project Manager as a Team member in a matrixed Enterprise Organization

The following idea is based on experience in several non-perfect matrix environments where the concept of complete organizational change could take many years (or never happen).

Does this mean we should simply give into the environment or should work with the existing culture and environment?

I am not recommending any changes to the way Scrum (or your Framework of choice) works, but am opening up an "idea" for people to consider.

I was recently chatting with someone about the role of a Project Manager in an enterprise Scrum roll-out.

Firstly, let me say that having a Project Manager "run" a Scrum Project is something I do not feel comfortable with if the organization is trying to work towards Agility. Let's get that clear right now. That being said, I've helped some organizations (large matrix ones) to introduce Scrum into their environments (including values and principles, not just process) and Scrum has worked out well for them.

I still hear from team members that have yearly votes about continuing with Scrum as part of their internally created process.  They work their own way and continue with Scrum, don't have PMs running their projects, and decide for themselves how they will organize and work. The organization has made sufficient adjustments to allow this to continue.

In Scrum we build a Cross-Functional team of people who can deliver a potentially deliverable working increment.  What if the organizational structure does not support this?

Do we bang our heads against the wall, or worse (in my opinion); just capitulate and change the framework immediately because our jobs as coaches are on the line?

Yes, we are trying to change the way things get done.  However, in an enterprise, this takes time.  What is not often discussed is that the original organization changes slower than the agile teams will.  This will clearly create conflict. 

Remember, this slow organizational change is likely part of the "Why" you are there in the first place. See my post about "Why" here.

The Agile manifesto says "People and interactions over processes and tools".

Well, let me remind everybody....  Project Managers are people too!

They have some very unique personality traits and skills that can benefit their teams (especially in Matrix organizations).

So, let's keep this post simple;

What would happen if a Project Manager was on a team as a Team Member using their unique skills and abilities to maneuver, build relationships in the matrix organization?   The team will have tasks that involve things like "Get marketing to review the content".  It's not really an obstacle for the SM to deal with.

Remember, the Project Manager (in a traditional organization) has the "keys" to be able to visit marketing in the first place.

I have worked with a team having a PO, SM, and simply "Team members".  One of those team members was a "person who was a Traditional Project Manager in their past life" who has the rights and privileges in the organization of a Project Manager.

For some of you, you may say "No, everything has to change".  I say, Yes, ideally, things will change over time. To just say "All project managers must go", is removing a very important skill-set and personality type (I'm not talking about filling out charts) that will be missed in an organization in transition.

To expect the organization to just "click the switch" and have other parts of an enterprise org respect the role of the SM immediately is not likely to work effectively.

In the scenario I describe, the SM, PO and Team all work together (as expected).  In a matrix org though, the PM could be a team member and add REAL VALUE during a transformation.  In the process, the PM would also learn some new skills and ways of thinking which could benefit them, the team and the company in the future.

You could still be following the Scrum framework (it is not specifically defined as to who can be on a Scrum Team, just that they need to be able to deliver an increment and be a self-directed team).

This of course would be transitional, but I may be realistic to expect it to be YEARS in the making as the organization changes to not need the traditional PM role as much and as walls and silos are broken down.

Not realizing there needs to be a half way to me at least seems like you are setting up your transformation to fail right from the start.  Enterprises don't just turn on a dime. This is why they need a way to "transition" to a new way of thinking.

So, consider an experiment; What if you just did Scrum the way it was designed and allowed the Project Manager to take on tasks on behalf of the team as a full-fledged member of the team.  They would not have the ability to assign tasks. They would however be extremely helpful and not feel like an outcast.

As long as you are considering the Agile Manifesto and guide yourselves by Scrum's values, you can't go wrong.  Scrum's values are...
  • Commitment
  • Courage
  • Focus 
  • Openness
  • Respect
As you consider this idea...

Remember, Project Managers are People too!

Mike Caspar


WHY are you trying to work towards Agility post - Link here
Agile Manifesto -
Scrum Values -

Wednesday, October 30, 2013

Scrum - A framework to facilitate the creation and maintenance of trust.

What if we changed the definition of Scrum as follows? (I'm not actually advocating this, but wanted to get the idea out there). 

- Scrum -

A framework to facilitate the creation and maintenance of Trust.

With the abundance of articles out there about how this procedure works or this process works, how teams should evolve and how corporations should change for the future, trust is something I feel is missing as part of the discussion.

Many of us have seem Scrum (or Agile) adoptions fail and succeed. I don't know about you, but for me, the successful ones have been the ones where effort was put into creating and maintaining trust.

For the more "procedural" of you out there, let's talk about one specific example; The Sprint Retrospective

The team reflects on what happened in the previous Sprint, or maybe to think about how progress is being made toward a more long-term change such as improving team knowledge, or upgrading a system's testing capacity. They then contemplate a way to move in that direction. 

A team that embraces the idea of trust maintenance, will let others know what it plans and will communicate what it is trying to accomplish (or learn) as a team. The team is open and transparent and showing responsibility.

The retrospective is a continual improvement step that the team is taking toward making their lives (and the lives of their organization and customers) better.

You may think of this just as a procedure, but consider for a moment, the importance of the retrospective for building trust.

Many consider the trust between team members. But what about other forms.

Put yourself in the shoes of an executive who is wondering..  "Is this Scrum stuff working? How is it helping my business?.

Then, you'll realize, a team that takes the Retrospective seriously is building a considerable amount of corporate trust.  It shows that the team can, and is willing to be self-organizing, self-healing and does not need to be "pushed" or "controlled". If left to it's own devices, the team will always try to improve.

Why not try thinking like a business person who is making a transaction. You are doing self-improvement and letting the organization know you consider this important. In exchange, you are building up your currency of trust in the bank at the company. You are continually working to maintain the trust level.

After all, if you are on a Scrum team, you are likely working in or for a business. Showing you care about the business can't hurt your credibility. Can it?

The Scrum framework creates this as part of its' design.  It allows (facilitates) an environment where trust can be created and maintained.

Think about the different processes in Scrum and ask yourself...

 "If we do or do not do this part of the framework,
how will it change trust with our partners in our environment?".

You might find this helpful in learning why some parts of the framework exist.

Other frameworks have different approaches, but I think after consideration, you'll realize that all the noise can easily be filtered through by considering the element of trust when trying to decide if something is worth doing.

I regularly hear Agilists talk about "People and Interactions" as being the most important thing to them. How is it then, that these same people do not consider the implication of the creation (or destruction) of trust in their environment when deciding to make adjustments to what they do?  

Changes that are made at the team level will affect the level of trust in the rest of the organization or the teams' interaction with their "customer". 

Consider for a moment that if you embrace Scrum's approach, your team will be "closer" to the customer.  How can trust be ignored?

For me at least, If you filter all the hype and noise and just think of one thing, it makes learning an Agile Mindset (not just Scrum) easier.  

In the end.... When making decisions, what we really need to be considering is the creation and maintenance of trust.  

Perhaps this is something that could be discussed in a Retrospective :->

Just throwing it out there.

Comments always welcome.

Mike Caspar
Passionate About Agile

Monday, September 2, 2013

Infrastructure and software knowledge needs to be shared between teams.

I recently found myself discussing a favorite topic of mine and felt the need to share again.

Do not consider your Infrastructure and Software to be different and distinct.

The infrastructure needs to grow with the changes in your software.  At the same time, you are asking for problems if you develop software without considering the user environment as well as the infrastructure you have.

It is hard to consider this when your teams are heads down working on their own "side" of the equation.

Some examples....

- A development team spends almost one month trying to solve a speed and crashing issue with IIS and Microsoft SQL.  When they talk with the "IIS person", they find out that a simple change of one settings stops the server from crashing twice a day.  Sharing of technical knowledge helps.

- A team (together with a product owner) invent a "really cool" application that uses large images to "properly express their ideas".  The technical glitch...  A large portion of the customer base does not have high-speed internet access and refresh their browsers constantly.  The system runs slow and has performance problems.  Always consider the actual environment of the end-user.

- A DBA is asking for a massive upgrade to a system when the "cure" is to have the development team start using the .NET CACHE() class appropriately.   Not all "infrastructure" problems need hardware solutions.

I am not suggesting a large amount of up-front Waterfall type activity.  I am simply suggesting more Communication between Infrastructure and Development if that is your reality.

Ideally, you could get someone with infrastructure experience and privileges onto the development team  and work toward a more cross-functional team situation; even better.

Consider finding some way to allow the "Development Team" members and "Infrastructure" to exchange knowledge face-to-face once in a while.

I was going to put some ideas here but realize they might cloud the issue.  If you consider your own environment, you will find a way to proceed that works for you.

They key is to be deliberate and specific about having infrastructure and software communicate.

We almost all agree that better communication and knowledge transfer is a good idea, but when is the last time you or your team actually did something about it!

  Ask yourself... 

 "What have I done to help infrastructure and development share technical knowledge and information?"

Better yet, ask your teams how to accomplish this.

The software won't work without the infrastructure and the infrastructure needs to be appropriate to the customer's needs and the software running on it.  They cannot be separated.  This also holds true for "the cloud".

For those that are interested.. Here's my post from 2011 about this topic.

Mike Caspar
Passionate About Agile

.NET Cache  -

Monday, August 19, 2013

The Sprint Retrospective and the creation of Trust.

I have made previous posts about the importance of the Sprint Retrospective (part of the engagement meeting in Openagile).  See... an example here.

There is another compelling reason for the Retrospective I have not shared on my blog; The Retrospective's value in the creation of TRUST.  We talk about it indirectly through various team exercises and games.  I wonder, do we specifically talk about the topic of trust?

Many people know the Sprint Retrospective as a time when the team reflects about how they are doing in relation to the Agile Manifesto, how they can improve their skills, how they can better communicate with others, or basically anything to help them "function".

I was recently reading Stephen Covey's book "The Speed of Trust" and it got me thinking..... Are we as coaches, Scrum Masters, or Process Facilitators putting enough emphasis on the importance of Trust?

Covey has an interesting formula (please don't turn this into a rule for a team to follow), where he factors in a "tax" for lack of trust at varying degrees.

The formula simply applies a negative multiplier or "tax" where trust is not present, or a positive multiplier or "dividend" where trust is present for specific topics.

Having met many companies since I started my consulting company in 1984, I can comfortably say;

You can have the best product, the best skills,
the best team members, or the best facilities, but ....
If you lack Trust, the game is over.

Trust is directly related to the speed that an organization can change or get work done. As a result, there appears to be a direct correlation between the level of trust and the cost to the organization.

For those of you who are focused on the Lean/Kanban mindset, consider the effect on time-to-market where people are permitted to work based on "trusting them".  With some effort, the difference in time to market with or without trust might be quantified.  Just a thought.

The Agile Manifesto also makes reference to this concept.  "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."  The key word here is Trust.

Stephen Covey suggests that trust can be created or lost.  This is a concept I share... more..

During your next Sprint Retrospective, consider having a specific "Focus" on internal and/or external trust if you feel comfortable trying this.  It might give surprising results.

Mike Caspar
Passionate About Agile


The Speed of Trust by Stephen Covey -
Agile Manifesto -

Retrospective -
Trust -

OpenAgile -
Scrum -,