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, 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  -

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.


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

Scrum - Scrum Alliance,  Scrum.Org
OpenAgile -
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

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