Agile Transformations… Top-Down or Bottom-Up Support?

When organizations and teams begin an Agile transformation, there is typically one person or group that is leading the charge. Does it matter if the push towards Agile is coming from the top or the bottom? Below, I will briefly discuss each and talk about which I think is more important.

Bottom-up support

By bottom-up support, I mean that the team is excited about and supports the use of Agile. Perhaps a developer came from a startup where they were lean and used Kanban. Maybe someone heard about Scrum, researched it and convinced the team to try it. Either way, having buy-in at the team level is great because these are the people actually doing the work. They are the ones who live and breath it every day. They use the process and identify ways to improve it.

Top-down support

By top-down support, I mean that the leadership team is excited about and supports the use of Agile. Perhaps an executive heard an Agile success story or learned about Agile at a conference. They want to get the product to market faster so they can get feedback from customers. They want to adapt better to changing requirements. And they want motivated teams that enjoy coming into the office.

Which is more important?

To build a good product, you need good teams. Bottom-up support brings a lot of commitment and accountability among team members. Typically, the team is very responsive, willing to experiment, learn and adapt their process. Team members are passionate because they are empowered, allowed to be creative and make decisions about how to do their work. However, bottom-up support is not always enough. To continue to feel safe and become as high performing as they can be, teams need leadership encouragement and support. Not to mention, leadership needs to continue to pay the bills, hire Agile coaches and remove organizational impediments so that teams can be successful.

Top-down transformations can be exciting but also seem imposed. Exciting because when leadership is on board, the team will feel empowered and there is a better chance that the cultural changes necessary for a successful transformation will take place. Imposed because not all team members want to be Agile – it’s simply not for everyone – so there can be pushback. However, after a while, most teams prefer Agile, so leadership needs to communicate the benefits and explain what specific problems Agile will help solve. Agile is fast paced, collaborative and requires accountability, so leadership needs to provide conditions where the team can thrive and succeed. Many times, explaining the reasons for Agile, communicating support and getting out of the way is enough.

So, which is more important? I’m not sure that one is more important than the other. They both provide their own value and go hand in hand. I believe that a combination of both is best.

Eventually, an Agile transformation that started at the team level will need leadership support. And equally important, a transformation that started at the leadership level will need buy-in at the team level. If leadership shows that they are willing to provide support and be patient during an Agile transformation, the team will feel safe and empowered to reach their full potential.

Which do you think is more important… top-down or bottom-up support?

Location, Location, Location – Working with distributed teams

Location is important for Agile teams

Working with distributed groups is not an ideal situation for an Agile team, or any team for that matter. However, there are certain steps that can be taken to maximize the effectiveness of distributed teams, and I’ve outlined ten below.

Step 1 – Relocate

Relocate your distributed team so that they are no longer distributed.

Step 2 – Minimize locations

Minimize the number of locations for the distributed team. For example, I was on a team with people in six different locations at the same time. I’ve also been on teams where people were located in only two locations. Two locations is preferred over six because the coordination is much easier.

Step 3 – Limit time zones

Match the time zones as closely as possible. I have worked with team members in China, India, Belarus, Russia, Lithuania, Mexico, Uruguay, Colombia, Argentina, Brazil and different states in the USA. Having team members in Chicago and Mexico City is easier than Chicago and India because the time zone is the same. With distributed teams, you want to maximize the amount of overlapping work hours.

Step 4 – Get everyone together

If you’ve got a group of distributed team members in the same location, have them get in the same room/area for meetings. I was part of a distributed team where all but two people were in the same location – same building, same floor, all sitting right next to each other – and despite this, they all stayed at their desks and dialed into the call individually. Find a conference room or use the speaker phone, but have everyone get together for meetings.

Step 5 – Emphasize communication

Form your distributed teams with people who are good at communicating and want to communicate. Communication is paramount, and when team members are distributed, it is even more important. I have been on teams where people simply did not want to communicate with one another, and it makes the team less effective. Having good communication and collaboration will help the team function at a higher level.

Step 6 – Use tools

Identify tools that make communication and collaboration as effective as possible. Having everyone on the same call is a start, but that is pretty basic and rudimentary. If possible, use webcams so you can see facial expressions and body language. There are many tools available for calls (Hangouts), estimating (Planning poker), retrospectives (IdeaBoardz), etc, etc. With that being said, identify a backup for when the tool you’ve chosen doesn’t work. It will happen.

Step 7 – Get to know each other

If the team is new, take the time to introduce yourselves and learn about each other. It will make working together easier and more fun. You can use various games or simply go around the group and answer some questions (hobbies, interesting fact, favorite travel location, etc). If the team is already formed and doesn’t know each other very well, there’s no better time than the present to get started. If your company is willing to pay for it, fly the team to the office. Face to face meetings will help create bonds and relationships that will increase the team’s effectiveness.

Step 8 – Facilitate

It is all too common for one or two individuals to dominate a call. It is also common to have little or no participation on a call. This is where the Scrum Master (and the rest of the team) needs to identify this pattern and help correct it by engaging everyone in the discussion. This may mean soliciting information from a quiet team member or possibly guiding the discussion in another direction. It can be challenging, so have patience and stick with it.

Step 9 – Implement a buddy system

I have seen this work several ways. (A) If you have one distributed team member, assign a watcher who is in charge of monitoring that person. Is the person trying to chime in but not getting the chance? Did they get disconnected from the call or maybe they are frozen? Are they sleeping? It’s the watcher’s job to keep an eye on this. (B) If there is a large distributed group, pair up with a buddy and help identify the same issues as mentioned earlier. Work to keep your buddy engaged in the conversation. It’s easy to forget about the people on the phone, so make sure it doesn’t happen.

Step 10 – Be creative

Different techniques work for different teams, so mix it up. Try new things. Experiment. Inspect and adapt. Be Agile. If it doesn’t work, try something else. One of the worst things you can do with a distributed team is accept a lower level of effectiveness without trying to make it work.

These are just a few ideas – there are many more out there. Please let me know if you have any tips on how to improve distributed team cohesion, communication and effectiveness.

User Stories – Size Does Matter

Agile User Stories


No matter what team I’m a part of or what meeting I’m in, the topic of smaller user stories is regularly broached. The reason? Because it is really important. At the same time, smallerizing stories can be quite challenging. However, as challenging as it can be, it is well worth the effort. Here are some reasons why I think it is beneficial to create small user stories.

Small user stories are more clear

When stories are large, there is more information contained in the description and more acceptance criteria to be considered. Sometimes this can be too much to wrap your head around. For example, when there are about three stories worth of information contained in one story, it’s harder to understand the scope and chances are that there will be multiple dependencies introduced. When stories are small, they are easier to understand which allows you to focus on what is right in front of you.

Small user stories are easier to estimate

Going hand in hand with smaller stories being easier to understand is that smaller stories are easier to estimate accurately. Would it be easier to guess the weight of an elephant or a cat? I recently conducted a small survey asking people to estimate those weights and each time the estimate for the cat is much, much closer. Try it yourself. You can also see this in the Fibonacci sequence that is commonly used in Agile estimating. As the numbers get larger, there is more room between them which indicates more ambiguity and less precision. 1, 2, 3, 5, 8, 13… these numbers are all pretty close to one another… 21, 34, 55, 89, 144… not so much.

Small user stories introduce less risk into the sprint

Have you been part of a team that had a 21 point story carry over to the next sprint? It was almost done, but not quite. At the sprint review, the stakeholders are now a bit disappointed because they were hoping to see that new checkout flow they’ve been dreaming about for the past two weeks. Imagine if the team had broken the story out into 4 or 5 smaller stories, for example. The stakeholders would have loved to see how the user can add an item to their cart and then add their credit card, even if they didn’t get to see the confirmation screen and email. But now they are sad and wonder why they attended the review in the first place.

Small user stories increase the workflow

Maintaining a steady workflow is important to help the team get in a rythym and avoid bottlenecks. Perhaps you’ve witnessed a large user story stuck in progress for over a week while Johnny QA is twiddling his thumbs and tapping his foot just waiting for the chance to find those bugs. Smaller stories lead to a better workflow and less bottlenecks, which lead to better team productivity.

Small user stories help shorten the feedback loop

When user stories are smaller, they are completed faster, therefore providing the Product Owner and other stakeholders the opportunity to provide feedback more often. When the team receives feedback more often, they can be ensured that they are working on the right stories, which in turn, ensures that the correct product is being built.

Can user stories be too small?

Yes, definitely. I remember one team in particular that I was on where the size of stories was discussed in the sprint retrospective. The team all agreed that the stories needed to be smaller. The next retrospective, we were discussing that the stories were too small. So, even though it is beneficial to have small stories, beware of making them too small. For example, if you are changing the size and color of 5 headers on a page, it’s probably overkill to have 5 separate stories for that. The overhead of creating and moving the stickies or updating the tool is probably more work than actually updating the headers.

To sum it up, small user stories provide clear benefits and add more value than larger user stories. However, breaking stories down is not as easy as it sounds and the team needs to work together to find the right size. It takes team collaboration and it takes practice. But it’s worth it, so give it a shot with your next batch of user stories.