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?
Time

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

----
References:

WHY are you trying to work towards Agility post - Link here
Agile Manifesto - http://www.agilemanifesto.org
Scrum Values - http://www.scrumalliance.org/code-of-ethics



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.

http://mike-caspar.blogspot.com/2011/01/infrastructure-knowledge-for-developers.html

Mike Caspar
Passionate About Agile

References:
.NET Cache  - http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx


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

-----------------------
References:

The Speed of Trust by Stephen Covey - http://speedoftrust.com/new/resources/book-promises/
Agile Manifesto - http://www.agilemanifesto.org

Retrospective - http://mike-caspar.blogspot.ca/2012/12/only-one-to-choose-choose-sprint.html
Trust - http://mike-caspar.blogspot.ca/2013/03/is-trust-binary-seek-to-turn-on-trust.html

OpenAgile - http://www.openagile.com
Scrum - http://www.scrumalliance.org,  http://www.scrum.org


Wednesday, August 7, 2013

Managers out there - Be selfish - Remove obstacles.


I recently had an interesting conversation with someone about a comment made to a Team:  "I removed your obstacle".

This may seem like great news on the surface.

It appears that at this company, the manager thinks it is the team's obstacle and not their own.

The reality is that if a team has an obstacle, although it may not immediately effect the manager, it will impact them.  This may be personal or financial.

Many change artists know that by showing someone how a change can help them personally increases the likelihood of acceptance.

I would argue that if I am a manager, by removing the obstacles for the team, it is actually a form of self-help.

The big realization that you are in it "together" is a fundamental mind-shift needed for a manager to switch from "manager" to "leader".  By helping my team to succeed, I am actually acting as a responsible leader.

For some reason, this message doesn't always come through as being helpful when we share it.  Perhaps this is due to our form of communication.  We may not be talking in the recipients' head space.

Many of us talk about "serving the team", "removing obstacles for the team".

Really.. is that what the manager is doing by removing obstacles!  Could we imagine they are also doing it for themselves? 

Consider the following message:


Managers out there....

Be selfish... 

Solve your own problems... 

Do this by removing obstacles for your teams.


Just a thought.


Please note;  This communication has worked well for me to explain the importance of removal of obstacles.  It has also caused me some grief.  Work out your own way of incorporating this message if it makes sense to you.


Mike Caspar
Passionate About Agile

Saturday, June 22, 2013

Safety for specialists on cross-functional teams.


For many organizations, cross-functional teams are something new (even those claiming to be using Scrum as a framework).

"The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity." 
Source: Scrum.Org Scrum Guide.

Consider the specialist who has found themselves on a cross-functional team in an organization that is unprepared for this reality and is wondering "Is my job safe?"

Clearly, this could be a frightening position for these highly valued team members.

Let's consider a few situations;

  • I want to do Scrum but am afraid for my job
  • I am willing to give it a try but I am skeptical
  • I hate Scrum and I don't want to work on something other than my primary skill

This post is intended for those who want to do or are willing to try Scrum as a Framework.

For others, perhaps Agile or Scrum is not for you. That's OK. Here's a post about this topic:  Cross-Functional Teams are not for everyone.

Please do not pretend the person's fears are inappropriate, especially in a new adoption or transformation.  

There can be a legitimate fear for team members in a company transitioning to Scrum (or any cross-functional team based framework).  You (like me) may believe in how Scrum can help an organization but that does not mean the organization is ready to do the mind-shift quickly.  This puts a specialist in an awkward position.

Consider a method I call 'EARS'.

Explain the purpose of Cross-functional teams. Explain the ability to "pull" or "absorb" the next most valuable work or "User Story" from the Product Backlog and have potentially ship-able software come out the other side of the Sprint.  This is not feasible without the appropriate complement of people to do the work.

Acknowledge that the current state of the backlog may not yet be in a "format" appropriate to cross-functional teams.  It may take some time until the organization learns to deliver work to a team in this new and in many cases "foreign" approach.

Re-assure the person that it is normal for them to be called upon to do work outside of their primary skill set for the team. The reason they are there is because they have a valuable part to play in that team's success.  After all, they might not be there if they were not good at their primary skill.  James Heidema recently made a great post about this concept.  Click here to read Jim's post..

Sit quietly and let the person think about what this means and answer any questions... Truthfully.

The reality is that if the management is not in alignment with the concepts of Scrum and cross-functional teams, the team members's job may be at risk.  At a minimum, it may be that Scrum is at risk.  People are perceptive.  No matter what you say, they can see for themselves what is happening around them.  

The best you can do is confirm to them the intentions and mechanics of the Agile framework you are using.  I find that often, just knowing it is normal in the framework is enough to already put someone at ease.  Most people want to make sure they are contributing effectively.

You may offer to open up channels of communication with their superiors to find out where they stand.

Don't make up information about what the company thinks!

If you do have management support for cross-functional teams, put extra effort into ensuring work comes to the teams are "slices" through the system that "Need" the complete skill set of a team.  It won't always work out that way, but the discussion needs to take place.

You cannot just build a cross-functional team and continue to give that team work in a traditional way.  This will ultimately fail.

If you are a change agent or consultant, please address this during your transformation or change.  People need to know they are safe in a cross-functional team environment.  This is especially true as the teams and organization learn to work with a cross-functional mind-set.

If someone comes to you with a fear about this, be smart about it .  Use your EARS.



.................................................
References.

Cross-Functional Teams in Scrum -  Scrum Guide



Sunday, May 26, 2013

Scrum is about Business. Do not be afraid to talk business when talking Scrum.

The situation...

The team has 4 days left in a 10 day (2 week) Sprint.



Person with some "Power": "I want to get this special feature done right now by inserting it into the Sprint because it is important for my division."

Scrum Master: "I am sorry, but we don't allow new work into the Sprint."

Person with some "Power": "Are you telling me that you don't care about this valuable work.  (usually not in a very nice tone).  Scrum is not very flexible".

Scrum is a Framework for delivering Complex Solutions.  It does not solve problems, but one thing is clear.....  Scrum used properly is about Business.  Actions by people in "Power" can have significant negative impact on the expensive group of people called the Scrum Team.

Scrum teams are EXPENSIVE to maintain (especially if distracted).  Don't be afraid to acknowledge that fact!  I once worked with a team who knew exactly what they cost each Sprint as a total including burden (other company costs including building, legal, etc.). It certainly changed conversations.

If your team is not allowed to focus on their current goals for the company, warning bells should be going off.   The team is too expensive to allow this to continue.  The team is already focused as a whole on what has been deemed as the highest Return on Investment from customer feedback to the business.

Please note, Return on Investment (ROI) does not have to be about Money. Return on Investment could be about many other factors.  (A post for another time).

A potential response to the situation above... (Yes, I know, easier said than done).


"Sure. As a Scrum Team, we work by ROI (Return on Investment) and we are highly aligned with business needs. The cost of the team of being redirected is material.  They are a very Expensive resource as a team.

We wouldn't be doing what we are unless it was important to reaching our Goal.  We are serious about it and serious about protecting the company's money.

For us to be diverted, we would let the Customers and the Business know that this work is more important than what we are currently focused on.  We'll Cancel the Sprint and re-plan.  Based on the size of our team, that should only cost about $12,000.00 all-in.  


We will leave it up to you to explain to the stakeholders who are waiting for our current deliverable.  


An alternative is to ask the Product Owner to put it as the first thing on the list for the next Sprint.  That's only 4 days away.   We're happy either way. I'll leave it up to you.  We'll just need to publish the reason for the cancellation if you choose that path."


This direct approach assumes that the team is actually following Scrum themselves and doing what they agreed to work on. If that is not the case, think carefully about what problem you should address first. 

The example assumes your teams are not just working on whatever they want to or something that was just assigned to the team in a haphazard way.  

If someone is assigning work to individual team members that is a whole different problem.  PLEASE Call an experienced Agile Coach or Consultant who has courage immediately. 

If the conversation would not go well in your organization, I believe you should be asking yourself (or your organization).

- Why are we doing Scrum?

- Why can we not allow the team to focus?
- Why are teams not working on the highest value items already?
- What can I do to educate people and/or executives about how and WHY we keep the Sprint Focused on the current goal?
- Should we be using OpenAgile or Kanban ? (there are more Agile Frameworks)
- Are we being honest about the costs of diverting a Scrum team?

Scrum does not fix problems.  It's rules are designed to expose them

Although it may be tempting to just ignore those rules, realize they are there to protect the investment the company is making in this very expensive team.

By not using them as designed, you are potentially wasting money.  The problems caused by changing the teams' focus are compounded by the cross-functional nature of the team and the work they are already engaged in.

Mishkin Berteig has been posting a series about Scrum Rules and why they work on AgileAdvice.com.   Here are some links for you if you're interested...

Sprint Review
Sprint Planning Timebox
Why is each Sprint the Same Length


If you really should be using Scrum and your company would prefer not to re-organize to allow this very expensive team to do the highest ROI work now...

Perhaps Scrum has already exposed a Material problem.  Think about it. Maybe it is working perfectly.


Mike Caspar
Passionate About Agile

.....................
References:
Scrum - Scrum Alliance,  Scrum.Org
OpenAgile - http://www.openagile.com
Kanban - Kanban for Development

Sunday, May 12, 2013

Scrum does not have answers for not following Scrum


Over the years, I have participated in, listened in on and watched many discussions about Why people have problems with Scrum.

This is not another post about the WHY of Scrum in an organization (which cannot be ignored!).  It is possible that the appropriate thing to do might be to avoid using Scrum if the organization does not want to use it.  

This post is based on the assumption there is Willingness to do so and a Sense of Urgency.  I will review some concepts based on this assumption.

Consider the following examples;

  • We are doing Scrum but don't have Product Owners
  • We are doing Scrum but don't have a Scrum Master
  • We are doing Scrum but we don't want to do the Sprint Review
  • We are doing Scrum but we don't have cross-functional teams
  • We are doing Scrum but we don't want to have fixed Sprint Time-boxes
(there are of course, many more)

I will use the Sprint Review to expose some thoughts on the matter.

The Sprint Review is a fixed time at the end of the Sprint. Team members can show what they have created as a team during the previous iteration.

Some of the benefits of the Sprint Review include but are not limited to;

For the Team;
  • A sense of accomplishment and reward
  • Motivation knowing that management and other teams are excited about their work
  • Real feedback as to how to improve the product
  • Ability to share their progress with others in the company
  • An increased overall level of understanding between teams
  • Shared ownership between the team and the stakeholders improve relations between teams and stakeholders 
For the Product:
  • Constantly evolving product based on inspecting what was completed by a group of peers and then adapting to improve the product based on that feedback
  • Early removal of risks by attempts to deliver a complete slice of user functionality as early as possible and preferably every sprint.  
  • Attacking technical risks by focusing  on the highest ROI (return on investment) items first reduces overall product risk while building "product knowledge" as those risks are mitigated.
  • A true status of where the product is by demonstrating finished functionality that can be used.
For the Company
  • The ability to have a focused ceremony towards the specifics of what was just created and to have a shared vision of where things might go from here.
  • A Cadence or "heart beat" where people know they will have an opportunity to learn what has been created without having "fear that they missed something".
  • A common place for all involved stakeholders and team members to see what teams are up to.
  • The ability for team members, and stakeholders to have one place to gather all the information they need to have a true idea of where they are at.
  • A forum to present obstacles the team is facing to all stakeholders in a targeted way.
  • To show other impediments to the efficient delivery of complex software.

To continue our scenario;

A senior manager decides that they will "cancel the review for now" because of one of these perceived problems....
  • Product being delivered or shown gives no value to stakeholders
  • Product has many bugs during the demo
  • Team is not showing enough functionality because it is too small or not-cross functional.
  • Product is not aligned with stakeholder vision and is upsetting to them
Scrum has done exactly what it is supposed to do.  It has identified obstacles to the efficient delivery of software and is expecting that you actually correct these things.


Problem: Product being delivered or shown gives no value to stakeholders


A common response: "Well, we'll just stop the review because we're not showing value each Sprint.. Let's come back to the reviews when we are ready"

Possible Response: To deliver value to stakeholders each sprint, hard changes need to be made to the way software is created.  This is the point.  The goal is to adjust practices and procedures to learn how to deliver working software with a high (and reliable) delivery rate.  

It is fundamental that feedback be given by stakeholders early.    

Problem : The product has many bugs during the demo


A common reaction:  "We will have to stop the reviews until we learn how to make reliable software.  We don't want to show our real progress to our stakeholders".

Possible Response: As teams learn to work in a Scrum Timebox, they need to learn new ways of coding, testing, communicating, code check in, pairing, documenting, etc. etc.  This is not easy.  They will make mistakes and have problems (especially at first).


Show the teams support as their skills improve.  Removing the need to show progress may only increase the amount of time until code quality improves.  Let everyone share in the success as you move forward.

Once the teams finally have it, it may be hard to get a rhythm going again, especially after previous reviews did not validate that mistakes are OK.  This gives a perception that reviews are only to show successes.  It needs to be safe to try new things and fail.

Problem:  Team is not showing enough functionality because it is too small or not-cross functional.


A common reaction: "We need to cancel the Sprint Review because the team is not delivering enough functionality each Sprint to warrant a review.  It is a waste of time".

Possible Response: To do Scrum effectively, you need cross-functional teams that have the skills necessary to finish a deliverable completely.  By embracing this idea, it aids in the removal of complexity by changing the traditional mindset of large build-up needed before coding can begin.   

If a team is not delivering enough during a Sprint because it is too small or does not have cross-functional team membership, Scrum will continue to be noneffective for the organization.

Even worse...When this problem eventually gets fixed, there will be no cadence and process that people are comfortable with to support the efficient exchange of information when it is really needed!  The learning will have to happen when a very expensive resource (a whole team) is looking for ways to communicate, inspect and adapt and has to start training the organization about reviews.

Please note, even a small team can create havoc for the future of the project without any peer and stakeholder feedback.  The size does not remove the need for the feedback.

Problem : Product is not aligned with stakeholder vision and is upsetting them

A common reaction:"We need to cancel the Sprint Review because the team is building the wrong things and we need to make sure that doesn`t happen.  Let`s stop the review so we have time to get more appropriate stuff done".

Possible Response: This is what Scrum is supposed to do.  We want to know now that what is being delivered is not the appropriate product and re-align the teams and product to what is expected.


By eliminating the vital feedback in a shared, focused setting, all the communication is moved into underground or other meetings without a clear vision by all those involved.


Some of us have been accused of  "not trying to be a good team player" or "not working with Scrum to make it work in the organization".

The organization thinks Scrum is a Silver Bullet that should just work as a "tool".  This is sadly, a contributing factor to this issue, but let's stay away from that discussion for now.

Scrum exposes problems.  It does not fix them.  Removing an event from Scrum because it shows a problem only serves to move that problem underground and hide it.

By removing the Sprint Review as intended, here is what you could end up with;

 (Remember, these will all be replaced with other non-focused ways of communicating or achieving these, therefore creating a double-burden on the company.  The Scrum framework itself consumes a large amount of time.  Not using the Scrum events as intended is a huge form of waste).
  • Team members who do not know what other team members are working on 
  • Stakeholders will hold meetings to find out status because of lack of knowledge
  • Mistrust between Scrum Teams and Stakeholders
  • A lack of heart-beat or cadence for people to become comfortable with
  • An uneasy feeling for team members as they do not know if what they are creating will pass peer scrutiny and feedback at some later date
  • Team members wondering if the management and stakeholders care about them or the product and a resulting lack of motivation
  • A feeling of us vs. them
  • A realization by team members that there is actually little support for Scrum at the management level.
  • A Scrum Master who becomes ineffective as information cannot be properly transmitting using the framework
When presented with the above list of problems, some of us try to find "alternate" ways to accomplish things "to be good corporate citizens" ... What we are actually doing is adding more overhead and burden to the company.  We are actually causing harm.

Whether it be to protect our jobs, lack of management understanding, lack of organization desire, etc. just give in, we often have no choice but to "give in".

I too have been in the position of "comply or get out".  I have been fortunate that I keep repeating the same message again and again, and most often (not always), the appropriate people eventually see the light (or let me go).

The worst thing you can do is make up some "alternate" way of doing things.  You are allowing the dysfunction to go underground and actually hurting the company.  Yes, easier said than done, I know.

When forced into a situation that is not right, it will eventually come back to you as a problem to "solve" later. It will be in the form of "Why doesn't Scrum let stakeholders know what is going on?, or "Why are we not getting the value out of Scrum we were expecting?", or "Why do we still have to have status meetings when we are using Scrum.  I thought this was supposed to go away?".

This post is not to address the "Why are we doing Scrum discussion.  I have plenty of other posts about that.  Here are a few if you're interested.
When trying to do Scrum without Willingness and Urgency, you may not get what is expected, so please consider your options before going down that path.  I truly enjoy the Scrum Framework (in the right place and circumstance).  In the wrong place, it hurts (everybody).   

Scrum does not solve problems.  Please do not pretend it does.  Acknowledge that it helps only after the impediments it finds are removed.  Consider the Scrum Code of Ethics when thinking about this.

Try this on for size next time you need to explain why something isn't working when part of Scrum is being ignored.  

Then, at least everyone will be talking honestly.  Instead of making up a solution; Give this a try...  (say it with me)....

Scrum does not have answers for not following Scrum
Mike Caspar



by Mike Caspar
Passionate About Agile



Disclaimer May 2013


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.

Thursday, April 18, 2013

Scrum exposes problems. It does not fix them.


I regularly hear people making statements such as "If we do Scrum, it will solve our problems".

The reality is in fact, it does exactly the opposite.  Scrum helps to expose problems.  In some way, you could view this as purposely creating them.

Let me explain.... The Scrum Framework is deceptively simple.  If followed properly, it will quickly show impediments to the development process.  As work continues, it will expose an increasing number of obstacles.

Scrum does not fix a company or a system.  The fixing needs to be done by the company, team members, management and leadership.

By exposing impediments, Scrum allows the removal of obstacles to the development process.  Due to it's time-box nature, it improves the focus of the teams and organization to fix those problems.

By removing those obstacles, it allows the team to go faster.

Think of a balloon filled with helium with several layers of straps and barriers keeping it down.

The balloon wants to climb, but cannot because of barriers holding it back.

Some people think that the measure of "velocity" can be used to "push" a team to go faster.  This is the equivalent of just pushing harder on the balloon to have it try and force the straps out of the way.

In a Scrum context, we realize that pushing the balloon harder to go up when a strap is holding it down only stretches the balloon to it's limits and will eventually cause it to explode as opposed to climb.

Work to remove the straps holding the balloon back, and it can be free to climb.

As the balloon climbs and more barriers are removed, it can start to move at it's natural rate (flow).

The problems Scrum expose need to be addressed.  Only then can the performance of the team increase.

If Scrum shows you something that is hurting the development process, you need to adjust the process to remove the delay to the team.

Having the team changes its' way or worse; trying to change Scrum so you do not have to deal with the information, only serves to allow the straps to remain secure.

Trying to adjust Scrum to allow the "straps" to stay in place and just keep pushing will not fix the problem Scrum has shown.  What is intended is the direct application of pressure to remove the obstacle.

Please don't tell people that Scrum fixes problems.  Remember, Scrum exposes them.


by Mike Caspar
Passionate About Agile



Friday, March 8, 2013

Is Trust Binary? - Seek to turn on the "Trust Bit"

I believe Trust Is Binary.  

To me, Trust cannot be partial.  You either trust someone, or you don't.

You can be in a state of distrust until you hit a certain point and then you flip the 0/1 bit and come to a point of trust.  

You may even trust someone completely and then have them do something to lose that trust.  It's a 0 or 1 thing.....  Binary.

Eventually a person that you distrust to some degree may do something to help you switch back to trust. 

You cannot say "I trust you partially". 

Perhaps I have been naive in my life, but to me, when I trust someone, I do so explicitly.  This approach has caused me some disappointments.  That being said, the occasional problem caused by this will not override the benefits of trust in others.


Market conditions, family situations, boredom, incorrect skills, or a multitude of reasons can change outcomes.   Things do and can go wrong, but I know it is RARELY because I have mistakenly given trust.  

To tell someone you trust them and then to give them only partial trust is untruthful. You don't really trust them.  Be honest about it.   

Trust is Binary

This brings up an interesting dilemma.... Where do you start?   

Do you start from a position of trust with everyone?  Any experienced business person knows this might be unwise.  Or is it?  Do we knowingly get into business deals where we know we cannot trust the other party?  Isn't that relationship destined to have problems?

Trust is such an important thing that I have gone out of my way to deal with people and companies I feel I can (or want to) trust.

Consider the "Agile Prime Directive" as it relates to Retrospectives and Reflection... 

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
--Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

An interesting statement.  It simply requires "Trust".   

It doesn't say we "sort of understand".  It doesn't say we "partially believe".  It says "truly believe".  PERIOD.

The assumption is that trust is existent, and is Binary. It is either there, or it is not. A one or a zero.

Life is easier when your peers can learn and solve problems together instead of worrying about trusting each other.

Consider this the next time you do a Retrospective or Engagement meeting.  Ask each other, "Do we trust each other?".  Being honest and truthful about the answer might take a lot of pressure off everyone, even if the answer is no.  At least you will know where you really stand, and something to look forward to when trust can be achieved.....

"Seek to turn on the Trust Bit".  (corny I know.. had to say it) :->

by Mike Caspar
Passionate About Agile

--------------------------------------------------------------------------------------
References:

Agile Prime Directive --Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

Thursday, January 31, 2013

Agile Coaches need to put more Focus on the Future, Not the Past


I recently woke up in the morning after thinking most of the night about how to help two new internally appointed Agile Coaches to become more effective in their organization.

The new coaches were unable to cross the "history vs. future barrier".  In other words, they had a habit of  "rewinding the past negatives" instead of crossing the line to "talk about the positive future".  This was caused by years of history where they work.

History vs. Future Barrier

This morning it hit me (quite by accident when reviewing and old post).

The following approach should help:

We should remind them directly that they will be Coaches, and with Coaching comes a certain level of Responsibility.... One of the biggest responsibilities is the one to be Positive and find some light when things look bad.  Of course, sometimes directness and brutal honesty are needed, but let me not get diverted..

Remind the new coaches that "being negative" won't help their team and is inappropriate for them.  Caution! If handled incorrectly, it could appear that you are asking them to be untruthful... this is not the intent.

You could ask them; "Do you think telling the team there is no way they will complete the project on time over and over again is something a coach should be doing?.   How do we know there aren't people on the team who feel differently?  Do you think it's good for morale?"

Personally, I might explain that the Mental Energy for everyone could be put to good use in getting the first Feature out the door.   There is of course (a given)  the need to report important information to the company and be truthful, but that doesn't say anything about the need to be negative.

To me, it's more about negativity.  If the people who are supposed to be motivating others are constantly saying it can't be done, well.. probably, it won't be.  The fact is, we are using an Agile Framework and we BETTER be delivering value after 1 or 2 Cycles or a different discussion needs to happen.

I would explain that.. hey.. the reason external people are so aggressive is that they don't see anything until near the end of the project... change the visibility and tone of information and the aggressiveness will eventually go away.  

Focus on what's important.. Helping their teams deliver value (and quickly) (not as in push them but focus on value delivery).  

At the same time, an improvement in the External communication or information radiators will surely help. If Information Radiators are maintained with care, professionalism and are truthfulness, teams will not NEED to tell anyone they won't make the "complete scope".  The information shown will allow the management to be part of the "solution" and will significantly reduce stress for everyone.

I thought it might just share my thoughts about this for those that are interested.

Agile coaching is a big responsibility.  If you are learning to coach, you must learn to leave the Negative Past behind and focus on the Positive Future.


Mike Caspar
Passionate About Agile