Five Ways Leaders Can Help Agile Succeed

Leadership undoubtedly plays a large role in helping Agile succeed. Here are five ways that leaders can help enable the success of an Agile program.

Create the right kind of environment

Creating an environment where people can take risks, experiment, fail and learn is extremely important if teams are going to continuously improve. An environment where people are afraid to make mistakes is an environment that is bound to fail. Leaders should help create a workplace that is fun, but where people are motivated and accountable.

Remove organizational impediments

It is critical that leaders help remove organizational impediments so that teams are not slowed down and can be as high performing as possible. This starts with identifying impediments, whether it’s establishing a communication channel to elicit feedback from teams or having an Agile coach provide insight. Next is taking action to remove the impediments. There’s a cumbersome change request process in place that is slowing down the delivery of products? Leaders need to find a way to change or eliminate that process. Teams are spread out on three different floors? How can leaders relocate the team so they all sit within earshot of each other?

Be transparent

One important aspect of Agile is transparency. From knowing what backlog items are being worked on to having a clear definition of done, transparency adds clarity and trust. Leadership should lead by example by being transparent and therefore providing clarity to their teams and building trust within the organization. Even if being transparent reveals some dysfunction, that’s good because now that dysfunction can be addressed.

Communicate the vision

Even self-organizing teams that are working hard to finish their sprint goals need to come up for air and make sure they are headed in the right direction. Leadership should be communicating the overall organizational vision so that the team can understand how they fit into that view. Another important part of the communication loop is listening and welcoming questions and feedback.

Trust the team and get out of the way

Teams will perform better when they are not micromanaged and told how to do their work. They are on the team because they are good at what they do and the team is using Agile so they can perform at higher level – so leaders need to get out of the way and allow teams to unlock their true potential. You will be surprised what your teams can do if you just give them the tools to succeed.

Being Flexible With Agile

After being involved with many Agile teams across a wide range of organizations – one thing is certain: each group will have their own style and flavor. No organization – whether a startup or Fortune 50 company – or team – distributed or collocated – will be the same. And in my opinion, that is a positive thing that adds value – not only to that specific situation, but to the Agile community as a whole.

The Scrum Guide, Agile Manifesto and other bodies of knowledge provide guidelines to follow, but flexibility is necessary in order to meet the needs of a particular project or client. Let’s face it, if teams aren’t flexible and don’t adapt to a given situation, there are times when nothing would get done. And typically, the goal is to produce working software, not to be in compliance with the Scrum Guide.

I have met those who are a militant about following the Scrum Guide to a T and any deviation is perceived as an act of war. Typically, I have found that sticklers are new to Agile – in the Shu phase of Shu-ha-ri. I will admit that when I began learning and applying Agile, I tried very hard to stick to the “rules”. However, I learned a while ago – after being exposed to various teams, organizations, levels of Agile experience, clients and situations – that being flexible with the application of Agile methodologies is important and probably a necessity.

The more experiments run and ideas tested only add to the amount of knowledge circulating throughout the web, conferences, Meetup groups and impromptu conversations. One of the great parts about Agile is the agility that it provides – the risks taken, the lessons learned, the nonconformity.

So how about you – do you strictly adhere to the Scrum Guide or do you tailor your approach to the specific situation? What are the pros and cons?

How to Make an Agile Transformation Stick

Previously, I wrote about top-down and bottom-up Agile transformations. After the organization has started their transformation, it is important to make sure that the teams and organization are not slipping back into their old habits. Especially if Agile is new, it is easy to regress. It’s critical to stick with it so the teams and organization can get the most out of the transformation. Below are three focus areas that I believe are important to help a transformation gain steam and then begin to make lasting change.

Those who are not familiar with Agile need to be educated, and those who are familiar with Agile should continue their education. Identify areas within the organization that could be improved and explain how Agile methodologies can make a positive impact. Create an Agile champions team and encourage Agile ambassadors to spread the word or hold lunch and learns. Invite people to attend the daily scrum and look at the burndown chart so they start to get an idea of how the teams operate. Engage others and encourage their teams to become Agile.

An organization is not going to transform over night. Or in a week. Or in a month. Set expectations that the process will take time, but remind people that the team is completing work and inspecting and adapting regularly, so they will be able to provide feedback and see continuous improvement. Let people know that Agile brings a level of transparency that will help make challenges visible early on. Bringing Agile into an organization can be a culture change, so be patient.

From an executive level, let the team know that you are behind them and support what they are doing. That is important and can make a difference by letting the team feel comfortable and confident to try new things, learn and get better. From a team level, be willing to engage with management and explain what you are doing. Justify why pair programming is helpful and not a waste of time. Explain the importance of having the team sit in the same room. Also, don’t undervalue the importance of Agile coaches. They help get teams up and running, but also make sure that teams are continually improving and performing at a high level – not just flatlining and being content.

Education, patience and support. Do you have any other ideas on how to make an Agile transformation stick?

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?

Agile Transformations and the Chicago Cubs

If you live in or near Chicago or have been paying attention to baseball this year, you know that the 2015 Chicago Cubs have made an amazing turnaround. I have been following the Cubs and have noticed several ways that they compare to a successful Agile transformation.

The culture has changed

The Cubs new manager, Joe Maddon, has instilled a sense of transparency, accountability, support and fun. One of the most important and difficult aspects of an Agile transformation is changing the culture. When a transformation receives top down support, it helps to motivate the teams and greatly increases the odds of success. Agile is a different way to work than waterfall, for example, and it makes some people uncomfortable because letting go of command and control isn’t easy. The team needs to be empowered to make decisions, but also know that they are held accountable. A culture that allows failure because it results in learning is important. Teams need to feel comfortable to try new approaches so they can find what works best for them.

Cross-functional teams

The Cubs have many players that are able to switch positions throughout the game. Even in the playoffs – the most important time of the year – people are playing several different positions in one game. Key players get injured and the team doesn’t skip a beat. Applied to Agile, cross-functional teams help ensure that team members are not working in silos and increases collaboration. Spreading knowledge and skills across the team helps them thrive and provides the ability to be more dynamic and responsive to change. There is less concern when someone uses PTO or gets sick because team members have the ability to play several roles.

Keep it simple

“I always talked about simplicity” and “The simpler solution is probably the better one to go with” are a couple of things that Maddon has said this season and he’s also referenced Occam’s razor (’The simplest solution is usually the correct one’). This attitude is very important for an Agile transformation because organizations and teams are trying to transition from a very detailed, let’s-get-everything-defined-up-front kind of attitude. With an Agile transformation, identifying an MVP (minimum viable product), writing small user stories that are expressed in the language of a customer and emphasizing face-to-face communication are examples of how keeping it simple helps to be successful. Building in short iterations and then inspecting and adapting help make the process more simple.

Just in time planning

When the Cubs started the season, Wrigley Field was under construction and several of their key players were not even on the team. The Cubs did not need everything  in place to start the season. They continued to build on their stadium and their team as the season went on. This is a key lesson during an Agile transformation. The notion that all requirements do not need to be detailed before the project has started can be difficult when you’re new to Agile, but a just-in-time process will keep the team focused and help avoid waste. A key aspect of Agile is learning as you go and adjusting the plan based on what you learn. Short iterations, having a few sprints worth of stories groomed and using retrospectives help teams be nimble and adjust on the fly.

Please let me know what you think, and Go Cubs.

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.