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.