Archives for Apr,2015

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

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

The team is not empowered and self-organizing.

Team members are working on too many projects, resulting in excessive context switching.

Management is committed to command and control (related to #1).

The customer or customer representative is not involved.

Processes are not allowed to evolve.

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

Those leading the agile implementation have not been properly trained in agile.

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

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.

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.