fbpx  

Scrum

, ,

Non-Agile Scrum

You may have adopted Scrum, and you may be following its rules quite exceptionally. Daily Scrums(stand-ups) take no longer than 15 minutes. At the end of Sprint Planning, you may have a solid plan for the upcoming Sprint including tasks, test cases…the whole 9 yards. You have a demo at the end of the Sprint and even a retrospective. Hurray! You’re agile!

Or are you?

Why do I keep hearing people say things like “I will never do agile again!”, or “I was on an agile team, it was horrible!”?

Hearing comments like these are very common. What’s happening here?

I think there are two things happening.

Scrum as a Silver Bullet

Companies typically implement Scrum because they are having significant problems with delivery, quality, or budget which makes for very unhappy customers and loss of revenue.

Why Scrum? Probably because they hear all the success stories from their peers…and it is the most popular agile framework after all.

The fallacy is that Scrum will “solve” your delivery, quality, and budget problems. That is not true…it will shed light on “why” there are delivery, quality and budget problems. It could be inadequate skills, too many hand-offs, too much bureaucracy, etc. These types of things would be the impediments that Scrum-ists talk so much about that need to be removed.

If you implement Scrum but do not remove the impediments it exposes, you aren’t really “doing” Scrum.

Non-Agile Scrum

Scrum is an agile framework, but all agile is not Scrum. It’s the same thing as saying that macaroni is a noodle, but not all noodles are macaroni. There are lots of agile frameworks, and Scrum is one of them.

Almost 100% of the time, when I talk to leaders and they say “we’re doing agile”, what they really mean is “we’re doing Scrum”.

The reason I think that this is important is that if you don’t make that distinction, you may miss out on what’s really important, the principles and values of agile.

Agile says nothing of 2-week Sprints, Sprint Planning, a Product Owner, a Scrum Master, etc. Nothing. However, the theory is that you follow Scrum, you are getting a great start on being agile.

Many teams will implement Scrum by implementing the roles, events, and artifacts. However, if they don’t understand agile, they may miss the point and end up no better than when they started.

When Scrum is implemented without an understanding of agile, and with the idea that Scrum in and of itself will solve every problem, you end up with non-agile Scrum. You may follow all the “rules”, but if you follow them in a prescriptive way, you are missing the point.

Agile Scrum

In my view, to have a truly agile implementation of Scrum (or any agile method), you need the following:

Self-organizing, cross-functional, empowered teams

This is indeed the most difficult goal to achieve. However, I believe this is the cornerstone of any agile transition. Leadership must change from a command-and-control perspective to one of support and empowerment of the teams. Since the teams are the ones who know best how to deliver, they should be allowed to do just that.

This does not mean that the team adopts the “wild west” style with no constraints. On the contrary, leadership provides those boundaries, and then the team will do anything necessary within those boundaries to deliver the best product possible. An example of some boundaries that I’ve seen are acceptable:

  • Use TFS for code management.
  • The team cannot spend more than $300 on software without approval.
  • The screens must be constructed adhering to our company’s style guide.
  • Don’t introduce new open source libraries, tools, systems, etc. without checking first if we already have something similar available. If you need to include a new open source item, make sure to add it to the corporate development wiki so others can learn about it.
  • Since we work with PII, no production data will be allowed in development environments. If it’s absolutely necessary to work with PII, the data must be de-identified.
  • All code must work on Edge, IE 11, the latest version of Chrome, Safari, and Firefox.
  • Make sure your code is tested using some kind of automated framework.

I think these boundaries are very reasonable. The team still has quite a bit of latitude to be creative. These boundaries not only have impact on the team itself, but also all the other teams.

On the Non-Agile Scrum Teams, I’ve seen boundaries such as these:

  • Every team will have a physical board with the columns “To-Do”, “In Progress”, “Done”.
  • Every team will write every requirement in the user story format “As a __ I want to __ so that __”.
  • Every team will perform code reviews Friday afternoon at 2 PM.
  • Each developer will create a design document before they code. They must review this document with the architect before coding begins.
  • Each team will schedule their planning session for no less than 8 hours.
  • Each team must post their retrospective notes on the Sharepoint site.

Hopefully it’s obvious that these kinds of “rules” take the wind out the team’s sails and kills any hope of creativity. These rules are somewhat arbitrary and ultimately if your team has rules such as these and are doing Scrum, you’re not doing it right. Understandably this is not a problem with the team. It’s a problem with leadership not understanding the concepts of self-organizing teams and empowerment

Dependencies

If you find that your team is not able to deliver any working software at the end of a Sprint without waiting on another team to perform a task, you most likely need to rethink how the team is formed.  Dependencies and hand-offs kill team productivity, predictability, and morale.  Here’s a great read on options to structuring teams – Feature Teams

Prioritized Product Backlog

This one appears to be pretty straight forward.  However, it surprisingly is not very common.  The Product Backlog is what anchors the team.  This describes the software that the team must deliver.  If there is not a clear Product Backlog, the team has idea what to deliver, and chaos ensues.

Below are the attributes of a well formed Product Backlog

Valuable

The Product Backlog contains items that are valuable to the customer.  This does not include technical tasks.  Technical tasks are included in the Sprint Backlog (a topic for another post).  There is a tendency to include technical tasks in the Product Backlog.  When this happens there is no clear understanding or traceability as to what is actually important to the customer.

Transparent

The Product Backlog must be available for anyone and everyone to see.  There should never be any surprises.  During the Sprint Planning session, the team should have already have pretty good idea of what’s coming up.

Consistently and Frequently Maintained

The Product Owner and the team must consistently maintain and refine the Product Backlog (it’s mentioned in the Scrum Guide as “Product Backlog Refinement).  It must be ensured that the team knows exactly what the next most important item is to work on.  Refinement includes adding additional detail when necessary, adding/refining estimates, and ordering.

Exists at All Levels

There should be some definition of “valuable deliverables” starting from the corporate vision.  Now, at the higher levels in the organization, it isn’t called a “Product Backlog”, but it really serves the same purpose.  You may have a Product Roadmap, Product (or Project) Portfolio, etc.  You get the idea.  What the team works from is the “Product Backlog”.  There typically is “line of sight” from every item in the Product Backlog all the way through the Portfolio or Product Roadmap.  

“What” exists at all levels is dependent on the size and complexity of your company.  Some companies may only have a set of Product Backlogs at the team level. Other companies may have a complex set of roadmaps and portfolios.  The point is that they should exist where appropriate and there should be traceability all the way to the Product Backlog item.

One Product Backlog Per Team

Quite frequently I see multiple Product Backlogs per team.  They may have a “product” Product Backlog, a “bug” Product Backlog, a “small requests” Product Backlog, etc.  That causes confusion for the team.  How does the team know what is next if there are multiple Product Backlogs?  They don’t.  

Summary

If you’ve been doing Scrum for a while and aren’t seeing the benefits, take a look at your teams and your Product Backlog.  Are the teams self-organizing, cross functional and empowered?  Can they deliver working software to the customer without depending on other teams?  Is there a Product Backlog?  Is it actively maintained?  Is there only one Product Backlog?  If you answered no to any of those questions, then there’s work to do!

This stuff is easy conceptually but hard to implement.  If you’d like help making your Scrum more agile, please feel free to contact us here.  

 

Scrum Does Not Have a “Sprint Zero”

Sprint Zero:  Sprint Zero is the time used to plan and set-up the foundation needed before a team can execute their first successful iteration. Sprint Zero deliverables may include: identify stakeholders, build the team, training, create high-level architecture diagrams, and set-up environments.

It’s become quite common for Scrum teams to begin by planning Sprint Zero. I’m not sure if you’re aware, but Sprint Zero is a bit of a debate topic at times.  I’m often asked what my stance is when it comes to Sprint Zero, and I struggle a bit since the real answer is this:  it depends.

I know it seems like answering with “it depends” is totally punting and not helpful. However, up-front pre-implementation activities vary greatly depending on what is being built.

1) Large Mission Critical Enterprise Applications

Assuming this is creating something that didn’t exist before, or re-building something that is legacy, I would start with a small core group of “key” people. An enterprise architect, a business leader (Product Owner, perhaps) – the person who owns the vision of “why” we are doing this, possibly some key stakeholders, etc. Ideally no more than 5 people. In this case, this small core group would determine the answers to the questions you ask and then figure out the best way to execute.

Activities would include: determine how to and then get started on setting up environments, technology, CI strategy, training, change management, etc. This small team would also come up with a strategy on how to assemble Agile teams.

I would not call this a sprint zero. As has been said before, it’s not a sprint as defined by Scrum, so let’s not pretend it is.

2) Small – Medium Projects Using Existing Technology

As you all know, these come and go. This is the steady stream of new feature requests that come from the business. It may take just a couple sprints to deliver, or it may take 10 sprints. The number of sprints is irrelevant in this case. There is still no need for a sprint zero. Just spend some time creating the product backlog and start. Business as usual.

3) New Product or Start-up

I have been involved in quite a few start-up ventures as a Scrum Master or as a developer. We start small with a vision (that’s typically been baking for some time) and a quick technology conversation, then we start executing. We have passionate people who all are trying to achieve the same goal. Yes there’s “up front” stuff, but it’s super quick…as in hours. In no way would I consider it a sprint zero.

Ultimately, I would love to eliminate the term “sprint zero” from our nomenclature. Upfront activities (other than release planning) should only be reserved for contexts where complexity, breadth of impact to the enterprise, and cost are all high.

For agile training check out our list of courseware, we would enjoy helping you on your agile journey.

Contact us today

 

,

Scrum Masters-Learning the Mastery of Scrum

Learning to be a good Scrum Master is hard, but how does a new Scrum Master learn the the mastery of Scrum?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome-again, open and engaged. The thing they all had in common was that they wanted to be better and they wanted to learn Scrum. I was one of group that introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my teammates were the ones that really knew what to do anyway…so why not give them the tools and empower them and help them to focus on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After those first (great) experiences, I became an agile coach. Now it was my turn to help teams transition to Scrum by educating the team, Product Owner, and Scrum Masters. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

There are three options/approaches to helping others become Scrum Masters.

Scrum Master-Agile Coach leads

The Coach Leads

With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and assists. Then, after a while (depending on the Scrum Masters comfort level), there is a switch, and the coach becomes the observer/helper.

 

Scrum Master-Agile Coach observes

The Coach Observes

Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.

 

Scrum Master-Agile Coach Advises

The Coach Advises

In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise and hear situations from a third party perspective. The new Scrum Master and coach meet regularly to go over gotchas, smells, and issues, etc. This approach works well for Scrum Master who just need to bounce ideas off of a Coach or validate their approach.

 

Scrum Master-Agile Coaching

Coach? What Coach?

This is how I learned. We didn’t have a coach. But, we were completely empowered to do what we needed to do to be successful. And, there was buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. It is rare to work in this kind of environment and going down this road can lead to great success or bigger failure. Choose wisely!

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option?  It depends on the experience of the new Scrum Master and the team. It also depends on who the coach is in the organization. If you are introducing Scrum and have hired an independent consultant (coach),  #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if the organization is backsliding, then #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 fits the bill.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So if you do decide to do it on your own get some formal training from experts or start reading. Read, read, read, and read some more. Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Many people post awesome information and articles that are thought provoking and free.

If you are looking for Agile or Scrum Master training check out this link for amazing Agile Training

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?

Talk to Us Today
post =