fbpx  

Andre Simones

Andre Simones

It’s Time to Deprecate Story Points

It has been known for quite some time in the agile community that estimation is waste.  And yet, I still see many, many teams spend huge amounts of time in story pointing sessions.  I’ve experienced people passionately debate whether a user story is 3 points or 5 points.  If that isn’t a waste of time, I don’t know what is.

I’ve stumbled across a pattern over the last 5 years or so that has probably always been there, but, hey, sometimes I’m a little slow (and, I’m not the only who’s noticed this by the way).  When I first noticed it, I was a little surprised.  Once I noticed it, I saw it everywhere.  But it made complete sense.

When estimating with story points, the purpose is to determine a velocity (total number of story points completed in a sprint) so that you could estimate how much a team can deliver within some period of time.  I was a big believer in this…it really worked.  It helped us be able to say “no” to more work during a sprint.  Drawing that line in the sand was awesome as we had real data to know where to draw that line.

While teams discover their velocity in points, I thought I would see how velocity correlated to number of user stories completed.  And then I found the pattern.  Teams consistently not only delivered approximately the same number of story points during a sprint, they also delivered approximately the same quantity of stories.  When I first discovered this, the team I was working with consistently delivered between 9-11 user stories every sprint.  I went back at least 5 sprints, and it was always the same.  I thought maybe that was a fluke.  So, I looked at other team’s (on the same initiative) product backlogs.  The same thing.  Consistent number of stories every sprint.  

Afterwards, when I worked with other teams, I noticed the same thing.  It’s extremely consistent.  And it made complete sense.  When you decompose user stories to the point where they fit into a sprint, you will find that some stories you thought were tiny are a little bigger, and vice versa.  Ultimately, it “comes out in the wash”. 

I do have one caveat.  If, for some reason, your team(s) have a tough time decomposing stories and the size of them vary wildly, then this may not work so well.  However, instead of trying to estimate better, you should put your efforts into learning how to decompose your work into smaller batches.  There will be a much bigger payoff.

Having experienced the widespread and consistent pattern, maybe it’s time to deprecate story points.  I know what you’re thinking, “what about long-term planning?”.  Long term planning smells like waterfall.  However, it is completely reasonable when a customer asks, “when do you think this will be done?” or “how much can you complete by October?”.  Ultimately the answer is always “we’re not sure”, but that doesn’t always fly.  There are other ways to provide a target (or a guesstimate).  But, alas, I’ll leave that for another post!

What do you think?  Is it time to deprecate story points?

Create Agile Leaders First

Agile has been around for quite some time now. The big dogs, Scrum and Extreme Programming, have been around since the late 90’s, just a little over 20 years! Wow how time flies.

I’ve been teaching classes on Agile for quite some time now…just a little over 10 years. Early on, it was really just a Scrum class, but over the years it has evolved quite a bit to include Lean, Kanban, Extreme Programming, etc. depending on what is best for the organization.

Most of the time when I teach classes it’s for a company that’s already started their agile journey, as most claim they have. So going into each class I have some assumptions, primarily that management has a basic understanding of agile and understand their role in the transition. I also assume that the teams have some rudimentary understanding of the basic principles of agile.

However, during the classes I typically hear these kinds of comments/questions throughout.

  • Our Scrum Master is on at least 5 other projects.
  • We don’t have a Product Owner.
  • We have to track our time on every story, how do we do that in Jira?
  • We spend about 3 months creating a requirements document. Why do we need a Product Backlog?
  • QA is on a different team.
  • Management won’t let us add new stories until it goes to the change review board.

And the list goes on an on. Obviously they either started off on the wrong foot or they have lost their way.

How can we avoid this? Or, how can we course correct? The magic ingredient is to create agile leaders first, before you create agile teams. The best way to kill an agile transition is to ignore the role management must play.

Now, this isn’t an all or nothing proposition. I’m not saying “every manager must become an agile leader in this entire organization before we start working with the teams”. Heaven forbid. We need to approach the agile transition in an agile way of course! For example, if a specific division is chosen to start the journey, let’s begin by having some workshops and coaching with management in that division first, then we will weave in the teams. If you start with the teams while ignoring management, and tell the teams to “go forth and be agile”, management will not understand their role and will unintentionally become impediments. That’s where you get all the “Agile Sucks!” rants online.

Now, if a company approaches me for training to “make their development teams agile”, I let them know that they must start with management. I also let them know that training alone is not enough. Ignoring these two things almost guarantees failure.

So, what do you think? Should we start with creating agile leaders first or is it okay just to train up the teams, ignore management and call it a day? I’d love to hear your thoughts!

, ,

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

 

Writing Good User Stories (Hint: It’s Not About Writing)

My first experience with Agile occurred due to my quest to write better User Stories.  As a new software development manager, I realized that the team’s biggest problem was estimating.  I found the book Agile Estimating and Planning and it changed everything.  It set us down the path of creating User Stories instead of using the CRD (Customer Requirements Document) that we had previously been using.

INVEST

 

Over the next decade, I focused on writing good User Stories.  I became an expert on INVEST, using it to determine if a User Story was well written.

 

 

One of the most critical aspects of a User Story is it’s role as a place holder for a conversation.  As a reminder, a User Story is made up of a Card, Conversation, and Confirmation.

User Stories 1

Somewhere along the way, teams have forgotten about the Conversation.  Teams almost exclusively focus on the mechanics of User Stories.  Why?  I’m not sure.  Maybe it’s because the mechanics are what everyone is worried about.  Mechanics are concrete and familiar.  They are closer to the old way of doing things.

The risk when focusing on only mechanics is that your User Story becomes a contract.  You are leaving Customer Collaboration over Contract Negotiation from the Agile Manifesto in the dust.

I hear teams say things like, “The Product Owner isn’t writing well defined User Stories so we can’t start“,  or “We have a hard time completely defining and documenting our User Stories in the Sprint Planning session“.  My response to these statements is: “You aren’t supposed to”.

While watching some YouTube videos on Story Mapping, I stumbled across an interview with Jeff Patton.  Here, he gives a brief history of how User Stories started:

.

Watching this reminded me of what User Stories are supposed to be, not what they’ve become: contracts.  It’s easy to ignore the Negotiable part of INVEST.

Here is how to write good user stories:

  1. Focus on the value to the customer: why they want to perform some task, not just what they need to do.
  2. Don’t strive to define every possible scenario in a User Story in the planning session.  If you do this, you are eliminating conversation that needs to be occurring for the rest of the iteration.
  3. Don’t assign the responsibility of writing User Stories to one person.  Writing User Stories is a collaborative effort.  It’s best to include the whole team.
  4. Don’t be a slave to a User Story format, i.e. “As a …. I want … so that“.  It’s a great place to start, but if there is a way that works better for you, go for it.  A User Story is just a placeholder for a conversation.
  5. Do not treat a User Story as a contract.  It will change throughout the iteration as the team gets feedback from the Product Owner, SMEs, Stakeholders, etc.  This is Agile.
  6. Run every User Story through the INVEST litmus test.  It works.  It may be hard at first, but it gets easier over time.

There are a lot of articles out there about writing better User Stories with great information about mechanics.  However, many imply that the only conversation required occurs during the iteration planning session.

Let’s set this straight:  The conversation is over when the User Story is done.

If your team could use help writing User Stories, contact One80 Services.  Our existing course, Agile Requirements & User Stories might be something you find helpful.  We’re also available for customized training and coaching – just drop us a line.

Talk to Us Today

Agile Failures: Just in Case

A huge form of waste (leading to Agile failures) many people don’t talk about are those features we build “just in case” we might need them some day.

I think that those involved with building a product often forget that everything we build costs something. Nothing is free. Who’s paying for it? The customer.

Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.

blog image 2There are certain phrases that I listen for such as, “it would be cool if…”, “someday we might want to…”, “what if a client requests …” etc. Some Product Owners want to build to accommodate edge cases that are often so ridiculous that they would never happen.

What gets really tricky is when there is only one SME in the product group, and no one else really knows that domain. In those cases, that SME acts as the Product Owner and has the power to create work that may actually be of little value and may lead to the snowplow trap.

The only way to get around this is to fearlessly and relentlessly ask “why?”. In these situations, there is typically a touch of fear that compels the team to simply accept directives rather than asking probing questions.

Agile Failure funnel effectA good way to think of this is to envision a funnel.  Only so many widgets can fit into the funnel at a time. If you need for a specific item to go through the funnel, something else is not going to get to pass.  This is very much like building a Product.

Only so many pieces of functionality can be built.  Eventually the project ends or funding is eliminated and you are left with features that did not get built, while ‘never to be used’ functionality was completed.  Some of the functionality that was not built may have had business value and\or high ROI. This is waste and is often perceived as an Agile Failure when in-fact it is a Product Owner prioritization issue..

There are some ScrumMasters (and Project Managers) that typically stay out of those kinds of details. Yes, the team is self-organizing. Yes, the team has to learn by making mistakes. However, the ScrumMaster has to be involved enough to not allow the “just in case” methodology take hold. If it’s allowed to happen, you will find that what you have delivered in the end is not of the highest value.

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

Agile won’t work on [fill in the blank]

I have four kids ranging in age from 21 to 10. For some reason, people without children really like to give my wife and me advice on how to raise kids. Usually they will provide analogies using their favorite pet. Or they will tell me about their second cousin twice removed who “just had a baby”, and here’s what they plan on doing. I just politely nod and say “thank you”.

Find out if Agile will work for youSo what’s my point? I also tend to get a lot of advice regarding agile development and how it won’t work on certain projects. I’ve heard it won’t work on complex projects, big projects, geographically disperse projects, mission critical projects, non-software projects – you name it.  Everyone who tells me this has either a) never worked on an agile project or b) worked with a poor implementation of agile.

Instead of politely nodding and saying “thank you for your advice” as when I’m given child-rearing advice, I’ve recently decided to politely challenge these ideas with questions such as:

“What experiences have led you to that belief?”

“Why can’t an offshore project implement agile methodologies?”

Below is a post that I saw on LinkedIn:

As with any project management tool, it is situational. If, like in many software development environments, there are one or two key people involved in each and every task, Agile tends to break down. In this case, there are better methodologies to employ. Like any concept, I think the rub is that no technique fits all situations.

This was written by someone who has clearly either never worked in an agile environment, or has suffered a poor implementation.

I responded:

“There is a very broad spectrum of agile methodologies out there to cover any situation. Being agile also means adapting the process to fit your needs as it’s an empirical inspect & adapt approach to managing projects. For instance, typically Scrum & XP are implemented together. Scrum only addresses project management practices, while XP addresses development practices.

The failed agile implementations I have seen were caused by one or more of the following:

  1. The team is not empowered and self-organizing.
  2. Team members are working on too many projects, resulting in excessive context switching.
  3. Management is committed to command and control (related to #1).
  4. The customer or customer representative is not involved.
  5. Processes are not allowed to evolve.
  6. There is no dedicated product owner, i.e. someone responsible for the ROI that the team can go to (getting rid of the multiple boss syndrome).
  7. Those leading the agile implementation have not been properly trained in agile.

Agile works on huge complex mission-critical projects

Agile breaks down when the organization is not ready to accept its principles. If the organization is not willing to change from command and control to servant leadership, empower the team, assign one product owner, and get the customer involved, then it will fail.“

If you feel that agile just won’t work on _____, I encourage you to find out for yourself. There are plenty of cases where agile has worked on huge, complex, mission-critical projects.

Below are some examples of successful agile implementations where I’m sure many would have said “agile won’t work”:


Talk to Us Today

,

Scrum Does Not Tell You How to Build Stuff

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

Talk to Us Today

Your Scrum Team Might Be Too Big

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I believe that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

1.  Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.

2.  Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.

3.  Keep everything the way it is. This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Talk to Us Today

Why I Would Never Go “Enterprise Scrum”

I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP.  I would have completely supported this several years ago.  Now, I am completely against it.

In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories.  One characteristic of these methodologies is that they have very specific rules.  You can’t add to, change, or remove any of the rules.  Why?  Well, because you wouldn’t be “doing” X methodology!!!

People have a habit of dogmatically following whatever methodology management makes them follow.  Now let’s say we are doing “Enterprise Scrum”.

This means that you are performing the following ceremonies:

  • Release Planning
  • Sprint Planning (every sprint)
  • Daily Scrum (every day)
  • Sprint Review (every sprint)
  • Sprint Retrospective (every sprint)

And, you have the following roles:

  • (1) Scrum Master
  • (1) Product Owner
  • Team (self-organizing)

And you will have the following artifacts:

  • Product Backlog
  • Sprint Backlog
  • Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)

So we’ve gone enterprise Scrum.  We’ve introduced this “by the book” Scrum.  However, we’ve also preached “inspect and adapt”.  But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles.  Can you add to them?  Sure, but you can’t “change” them.  And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.

What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint?  Blasphemy!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.  Really?  What if the team, Scrum Master, and Product Owner are all cool with it?  Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum.  In reality, this is perfectly okay.  However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in.  There will even be people who will not want to add techniques because “Scrum doesn’t say so”. Do those people truly understand the essence of Scrum?  No.  But they will cause disruption and waste

What if you don’t want to do iterations?  What if you want to deliver continuously instead of iteratively?  No Iterations?!?!  Blasphemy!!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.

You know all of this could have been avoided?  By NOT saying we are going “Enterprise Scrum”.  I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis.  Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.

Please don’t misunderstand my intention here.  I am not bashing Scrum.  I LOVE Scrum.  I always use Scrum when I execute projects.  However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was. I was very thankful that Scrum was not the required standard.

Talk to Us Today

post =