New Agile Acronym – EFCIC

Recently, I was preparing for a couple of speaking engagements and was thinking about how to summarize what Agile means to me.

What I came up with was Empowerment, Flexibility, Communication and Collaboration, Iterating on Feedback and Continuous Improvement.

Written out as an acronym, this spells EFCIC, which kind of sounds like efficacy, which means “the power to produce a desired result; effectiveness”.

Well, that sounds like a pretty good goal and something that Agile can help with, so here is my new Agile acronym…

E mpowerment

For Agile to work well, teams and individuals must be empowered. Empowered to make decisions, empowered to estimate effort and complexity, empowered to fail and learn from mistakes, empowered to ask questions, empowered to be creative, empowered to develop their skills, etc. If teams are empowered, they are more likely to be able to face challenges that come their way.

F lexibility

Let’s face it, plans rarely go as expected, especially in software development. The ability and need to be flexible is essential. Having the mindset that things are going to change can help be prepared when the time comes… and it will. If teams are flexible, they will be able to quickly pivot and head in a different direction when necessary.

C ommunication and Collaboration

To me, communication and collaboration have a strong correlation and both are really important. Teams need to have strong internal communication so they can become high performing and external communication so they can work with other teams and identify dependencies. Collaboration – whether it’s pair programming or working with the PO to define a feature – will help teams get the most out of each other and also increase team cohesiveness. If teams communicate and collaborate, they are more likely to be on the same page, come up with better solutions and continue to improve.

I terating on Feedback

Don’t fool yourself and think that you’re going to build a product right the first time. Instead, build something small, get feedback, iterate on it, get more feedback, iterate, feedback, iterate, feedback, etc. If teams iterate on feedback, they are less likely to waste time and more likely to build the right product.

C ontinuous Improvement

Even if your team seems like they are firing on all cylinders, chances are that there are some improvements that could be made. Focusing on continuous improvement is important so teams don’t get too comfortable. Experimentation is one of the keys here because it helps people think outside the box and leads to new discoveries. Even if the experiments don’t work, at least you know what doesn’t work. If teams focus on continuous improvement, they will challenge themselves and the status quo, benefiting not only the team, but the organization as well.

Does EFCIC represent the way that you view Agile? I would love to hear your thoughts.

5 Things Learned From Steve Jobs

Last week, I (virtually) attended the Lean Startup Conference and heard Guy Kawasaki – former Chief Evangelist at Apple – speak about 10 things he learned from Steve Jobs. Below are the 5 that caught my interest, along with some of my thoughts…

1. Customers can’t tell you what they need (you need to help them figure it out)

I think it is important to keep in mind that building the right feature takes collaboration and communication. This is similar to how a Product Owner presents a user story to the dev team and then there is a discussion to clarify points, add acceptance criteria or discuss why another approach could be a better idea.

2. Changing your mind is a sign of intelligence

This is very much in line with Agile thinking, which is why we work iteratively and incrementally and why continuous improvement through inspecting and adapting is so important.

3. Engineers are artists – treat them like artists

Just like an artist, engineers need space to be creative and innovative (no micro-managing). They also need time to work on their craft, for example, time to refactor so they are not introducing technical debt.

4. Innovators ignore naysayers

There are many reasons why people will say something can not be done. Perhaps they don’t understand the vision, maybe a particular idea threatens them or they don’t like thinking outside the box.

5. Some things need to be believed to be seen

Guy explained this as the idea of sometimes people won’t take the time to see something until they’ve been convinced of the idea. So, really understanding the benefits of a feature, being persuasive and convincing people of the idea many times is the first step.

Please let me know what you think.

Agile Experimentation

I am a big proponent of experimentation and find it particularly useful within the Agile space. When teams are working in short time boxes, a quick experiment could add a lot of value. On the downside, if it doesn’t add value, the team can choose to end the experiment and hopefully they have learned something. With an eye toward continuous improvement, perhaps the team wants to try another.

Below are a couple of experiments that teams I’ve been coaching have tried.

Experiment #1

During a retrospective, I brought up the topic of communication. How was communication within the team? Did they think it was strong? Were they all on the same page and did they know what each other was doing? Most people said it was very strong. One person said that they knew what everyone was doing and another said they would like to know what everyone was doing but they weren’t quite there yet.

I took this opportunity to suggest a communication experiment. How would the team like to give their daily scrum update for another person on the team? For various reasons, everyone thought it would be a fun experiment, so we decided to try it for a week.

The exercise started out pretty well, actually. Around day #2, things started to become a bit more challenging and by the end of the week, the team was ready to end the experiment. The team realized that although they had good communication, there was still room for improvement.

Experiment #2

Another team had recently been broken up and was reforming. They were clearly in the “storming” phase and were having problems with their throughput. In a retrospective, we focused solely on what could be done to increase throughput and start seeing work flow across the board. A member of the team had the idea to start using a daily team goal.

The plan would be that during the daily scrum, the team would identify the top priority for the day, how much of that the team could finish and who would help get it done. The plan is similar to the typical daily scrum, but much more focused on the team rather than the individuals.

The daily team goal helped the team focus, increased their collaboration and led to a lot of swarming. The experiment received positive reviews in and out of the team and is still being used today.

I viewed both of these experiments as positive. Even though they had differing levels of success, it felt good to try something new and I believe that the teams learned something from both.

What kind of experiments have you tried?

Teamification: Agile Team Self-Selection

Earlier this year, while consulting as an Agile Coach, I was involved with an interesting experiment. The experiment asked individuals to self-select into software development teams. Team members would be allowed to choose what products they worked on and who they worked with. The event was called Teamification Day.

I had never done anything like this, so I was excited and also interested to see the process and results. A lot of effort went into preparing for the event. The Agile Practices group – which I was part of – took the lead by designing the event and communicating information.


Each work package (epic or larger) had an assigned Product Owner and dev lead. The PO and dev lead worked together to design a presentation that explained their work package. This would be used on Teamification Day to educate and recruit people to their team.

Each pair also had a board that would later be used to indicate interest in a specific work package and would eventually indicate the final roster for that team. This board contained valuable information, such as:

  • Standard constraints: The required makeup of teams (ex. 3-5 devs, 1 PO, 1 Agile Coach)
  • Team is able to deliver end-to-end solution
  • Where the team would be co-located (Chicago, for example)
  • Team information: Name, value stream and work package
  • Skills desired: Ex. One FE dev, two BE devs, UI/UX and also specific knowledge if necessary (Elastic Search, Java, Kafka, Nifi, Selenium, etc)
  • Team adjustments: After each round, teams would use this space to identify what they still needed or what they have too much of

The Agile Practices group created the boards and then had a couple of dry runs to see how it felt and what issues we thought needed to be addressed. There were a handful of issues and ideas – ranging from ‘will the areas be too chaotic with so many people and so many questions?’ to ‘do we need flags to indicate the team’s location, whether the team is fully formed or not fully formed?’. The goal of this event was to allow roughly 200 people to learn about 25 different teams, ask questions and then choose their own team – so we knew there were going to be obstacles.

Curiosity Market

On the morning of Teamification Day, there was breakfast – along with excitement and anticipation – in the ballroom. After some short messages from various leaders, the Curiosity Market was opened. The Product Owners and dev leads stood by their booths and pitched their work packages – explaining what they would be working on, why people should be interested and exactly what kind of team they were looking to form. The room sort of resembled a science fair.

Since there were so many teams, several rounds were run and the time slots were staggered – with some presenting and others taking a break – to give everyone an opportunity to get the information they desired. As is typical with many Agile events, the law of two feet was encouraged to allow people to move around and do what made the most sense to them.

Team self-selection

Following the Curiosity Market was lunch. The Agile Practices group discussed how the morning played out and went over last minute coordination details for the afternoon. We discussed that despite (what we perceived as) a successful morning, the afternoon would be more complex. Anything could happen as people started choosing teams. However, we had discussed possible scenarios and were armed with techniques to facilitate various situations.

As the self-selecting portion kicked off, some teams were formed quickly, as there were some individuals and groups who had previously discussed where they would like to be. The rule was that anyone could put their name on any team board – even if that team ended up having 15 people who wanted to be on it. After a couple of rounds, most of the teams were squared away, but there were some teams who had too much of one skill and not enough in other areas. The event facilitator asked teams to call out what they needed – for example, ‘we need two front end devs’ or ‘we are short one tester’. At that point, teams would know where the gaps existed and could go discuss and recruit people to help complete the team.

After a little more discussion and pitching from Product Owners, all the teams were formed.

Post team self-selection

Months after the teams self-selected, things seemed to be going very well. Individuals seemed happy with how things turned out and in a recent survey, the self-selection process was called out by many as a positive. There were only a handful of people who did not get one of their top choices and providing the freedom to choose your own destiny was appreciated. Of course, not everything is or was perfect – there were a couple of people who have been traded to help better align teams and when teams moved on to different work packages, the work was not the same, which was a little disappointing for some.

Another interesting idea that has been rolled out are job boards. A job board is a place where teams can advertise that they are looking for a skill and others can view the board to see what team they would like to join. There are certain constraints – for example, people need to be on a team for 3 months before moving – but people will also be allowed to switch teams if they’d like.


Overall, I am grateful to have been a part of this self-selection Teamfication experiment. By most measures that I see and hear, it was a success. It provided the freedom and autonomy for people to choose teams for themselves, which conveyed a message of trust and accountability. Self organization was center stage in this experiment and it proved, to me, that empowering individuals can be a strong force.

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.