Blog


Common Pitfalls of Agile Teams

Agile, and Scrum in particular, has become mainstream for most development teams. Despite so much knowledge in the field and an ever-increasing number of coaches, many teams still struggle with common pitfalls which could hinder their productivity.

The Development Team is Responsible

When talking about teams, it is not only the development portion of it that’s important but everyone else as well, including the product owner and Scrum Master.

The whole team is responsible for providing an incremented and potentially shippable product at the end of each sprint: The added value is identified and defined by the product owner before being materialized by the development team under the guidance and support of the Scrum Master.

It is a shared responsibility, and each member of the team is responsible for the overall goal.

Retrospectives

Some teams might misuse the retrospectives by transforming them into a blaming or complaining (and sometimes justification) event. A retrospective is the team’s opportunity to take a break and reflect on the events and outcomes of the finishing sprint. It is an opportunity to learn, inspect and adapt. Teams shouldn’t skip retrospectives and should try to identify as many potential lessons as possible.

Agile is Fast

The nomenclature of agile might falsely give the impression that agility means speed. Although most agile teams deliver faster than normal teams, this is not what agile really means. Agile really means responding quickly to change. There might be short sprints with shippable product increments at the end of each, as in Scrum or, more often, prioritization and releases as in Kanban.

The essence is to get earlier feedback and rapidly respond to customer requirements and business change. Teams shouldn’t be tempted to sacrifice quality or improvements to achieve the illusion of being fast. If they fall into this trap, they will actually get slower by incurring technical debt. So, it’s crucial that teams understand what agility really means and take care to focus on aspects other than speed.

Bugs

The most commonly argued question in the software industry is: “What can be considered a bug?” Some teams might find it easier to close a failing user story and create a bug as follow-up. Well, such a team is not one whose members understand agility.

The team should focus on delivery and ensure that each user story that is closed can be potentially delivered to the customer the next day. A bug is only reported when something is not working as expected after delivery, but closing a user story after reporting a bug for it within the sprint is more like showing and reporting progress than building and delivering products.

The Big Picture

Teams are not working on user stories in sprints. Rather, teams use an incremental approach to deliver functionalities. This means that they need to see the big picture of what they are working on and how to maximize the value delivered to their stakeholders.

Again, it is necessary to highlight that the product owner is part of the team and that it is his or her duty to draw this picture, make it visible to the rest of the team and get their feedback on it. The big picture could be named a theme, an epic or a feature—call it what you wish, but please make sure that it is present.

These are some of the common misunderstandings and pitfalls agile teams could fall into. Did you face any of them? Have you experienced others? Feel free to share in the comments section.

 

 

 

Introducing Changes to Your Team

Joining a new team always brings new challenges to both the team and the Scrum Master. The Scrum Master will be always seeking to introduce new ideas and improve the performance and collaboration within the team. Often, he or she will experience some resistance from the team, which is completely normal given that the team is used to working in a set way.

The first thing the Scrum Master needs to keep in mind is that any change, regardless of how small it is, might take the team back to the forming phase if not handled carefully. 

Beyond the apparent behavior of team members, there is an emotional turmoil as well which was described by Elisabeth Kübler-Ross in her work for helping terminally ill patients. She called this turmoil the Five Stages of Grief: Denial, anger, bargaining, depression and acceptance. This model could be also be used to help you, as a change agent, to understand where your team members stand and how to react at each stage.

Jason Little used this model in his book “Lean Change Management,” and I will present it on a smaller team scale rather than an organizational scale.

For each of these emotional stages, you’ll need to behave differently to help the team accept and adopt the new approach you introduced.

Create Alignment: You owe the team an explanation. Why are we introducing this change? What are the benefits? How will this change help the team perform better? These are the questions you’ll need to answer to get the team’s buy-in and motivation for the change. Maximize Communication: Try to eliminate doubts and be proactive. Ask the team members over a coffee or lunch about their thoughts on the new change. Try to talk to them as much as possible to clarify what might be puzzling them about the change. Spark Motivation: People are different: what motivates one person might be a demotivator for another. Try to understand each person in the team and strive to find the proper motivation each person needs in order to adopt the change. Maybe you can ask one of them to join an agile meetup or a talk addressing the topic to see the impact and benefit from peers in the industry. Develop Capability: Give the team time to experiment with the new approach. You should pick only a few stories for two sprints to give them space for experimentation, allow them to acquire the needed skills or simply practice the new approach. Share Knowledge: Encourage the team to share their story with other teams in the organization and at events they attend. This can give them a sense of accomplishment as well as satisfaction.

Introducing change is not an easy journey, but the reward is worth the trouble. Don’t be afraid to introduce new ideas and adopt new practices. Your major goal as a Scrum Master is to keep the team continually improving, and this won’t happen by always doing the same things in the same way.

What is the latest change you introduced to your team? How successful was it? I would like to hear about your experience in the comments section below.

You Need a Scrum Master

“We can’t afford a Scrum Master.”

“What does a Scrum Master do other than schedule meetings?”

“Any developer can call themselves a Scrum Master and send meeting invitations!”

“We don’t need a Scrum Master, we do things differently!”

These are some of the statements often heard from management when asked whether they need a Scrum Master on their teams. These types of responses could reflect some of the misconceptions about the value of the Scrum Master role, and might also reflect a previous, unpleasant experience with an incompetent one.

Although this question has been asked several times in various agile blogs and has been answered with a clear “Yes” in almost all of them, it is still being asked every now and then, especially by smaller companies and startups. Some other arguments on this topic can be found here and here.

In this post, I would like to share two situations faced by friends of mine in two different companies which both decided against having a dedicated Scrum Master on their team.

The Team Lead/Scrum Master Knows All 

In a previous post, I shared my concerns about mixing roles in a scrum team, and sharing the Scrum Master role among developers was one of them.

In this real-life scenario, a developer (or the tech lead, to be more specific), was given the title of Scrum Master since he was “certified.” But, if we look at the team’s internal process, we will soon discover why such a team needed a dedicated Scrum Master.

In this team, they didn’t have sprint review meetings, the “daily” Scrum was done three times a week, there were no retrospectives or build automation and the tech lead was the only one doing code reviews for the whole team. It’s easy to imagine the massive queue of tasks that were waiting for review and deployment. The technical debt needed months to be fixed, and the product owner was anxious to get the features to production.

This team sorely needed a dedicated Scrum Master to coach the team on the value of core agile practices such as pair programming, automated tests and automated builds. Essentially, the team needed to understand the importance of collaborative code ownership as well as the power of frequent deliveries and early feedback.

We Don’t Need a Scrum Master

This next team was a small one, but the takeaway is similar to that of the first example. This team didn’t have a Scrum Master at all, and instead had a product owner, a distributed development team and a team lead. Like the previous example, the team lead was the only person who reviewed the code, which quickly created a lagging queue of tasks. Another challenge for the team was that some members of the development team were part-time employees, while others were dividing their attention between two projects simultaneously.

Some might wonder what a Scrum Master could possibly do for such a team. In short, a Scrum Master could act not only as a glue holding the team together but also as a grease to help the team get through challenges more smoothly. He or she could help the team organize themselves properly, improve communications, help the team share knowledge and improve code ownership.

In both cases, the lack of a Scrum Master increased and complicated the difficulties the teams faced. Without adequate understanding from management of the importance of such a role, teams like these will continue struggling to find their way and provide high-quality products.

Do you have other examples of a lack of a competent Scrum Master making a team’s life more arduous than necessary? If so, please feel free to share them in the comments section below.

5 Signs Your Team is on the Path to Agility

Some of the comments on my previous article, Mixing Roles in a Scrum Team, explored the idea that the successful mixing of roles is dependent on a team’s maturity level.

However, this begs the question: how can we accurately assess a team’s maturity?

In the article Agile Self-Assessments, Ben Linders gathers many tools which any team can use to assess its maturity. Based on the results of such assessments, agile leaders can make informed decisions on how to proceed with team structuring.

Since I’ve already shared some of the signs that a team is lacking an agile mindset, I would now like to share five signs that an agile team is on the right track.

1.       A Release at the End of Each Sprint

The ability to release at the end of a sprint indicates several positive team traits, the most important of which is that the team understands and adheres to the definition of done. That is to say, all user stories which were finished in the sprint are in a releasable state. In these situations, “releasable” usually indicates that the product is suitable to be released to an internal integration environment, not to the end customer. However, an internal release is still a release nonetheless.

2.      A Staircase Burndown Chart

Having small user stories which can be finished in a short amount of time is a talent acquired by both the product owner and the team as they move upwards on the agility ladder. A staircase burndown chart showcases the team’s understanding of prioritization as well as the importance of delivering the product in small chunks rather than as a full-blown application.

3.      Gathering to Solve Problems

If you see the team sitting together around one computer and problem solving as a group, this reveals that the team is sharing knowledge, brainstorming, seeking a solution and, most importantly, that they are truly working together as a team.

4.      A Prioritized Backlog

Developing an estimated prioritized backlog is the main responsibility of the product owner, and he or she can’t do so without the help of the rest of the team. For a backlog to take shape, the product owner will need the team to estimate and clarify user stories, ask the proper questions and form adequate acceptance criteria.

5.      Short Planning Meetings

In general, the shorter the planning meetings, the more mature the team. This is because short meetings typically mean that many of the team’s uncertainties were already clarified during the backlog grooming session or via frequent communication with the product owner.

These are just a few of the many signs that a team is mature, but they are the ones which can be most easily spotted by agile leaders of any level.

Do you know about any other indications that a team is on the path to agility?

I would love to read about them and any other thoughts you may have in the comments section below.

Mixing Roles in a Scrum Team

One of the powerful advantages of Scrum is having two different types of responsibilities: the shared responsibility for the final product, and the individual responsibility based on each team member’s role.

Responsibility for the product is shared by the whole team: the product owner, scrum master and development team are all collectively responsible for the development and delivery of a working product at the end of each sprint. On the other hand, each one of those team members is also individually responsible for a specific part of the product.

While the product owner is responsible for gathering requirements, shaping the product vision and prioritizing the “What, Why and When,” the development team is responsible for devising ways to  provide the needed features, as well as determining how much time and effort is needed to fulfill the requirements of each user story.

The Scrum Master, by supporting the team and driving them to achieve better results, acts as the catalyst of the sprint.

Despite this separation of roles in a Scrum team, sometimes management thinks that it makes sense for a single team member to take on multiple roles.

I’ve heard about teams where a developer acts as Scrum Master, as well as teams where the Scrum Master role is rotated among the development team members. My view on this approach is that it creates an unhealthy structure due to the conflicts of interests present within each role.

I would find it strange for a developer who is supposed to work on user stories provided by the product owner to simultaneously coach the product owner on how to write and prioritize user stories.

This type of team structure also fails to deepen the development team’s confidence or trust in the product owner to decide what features are needed or make proper decisions.

One other unhealthy situation occurs when the line manager of the team was also a developer who was actively participating in the development. The lack of a boundary between these roles can cause various different problems.

The development team wouldn’t be eager to challenge their “colleague’s” technical proposals, since he or she  is a member of the same team. Sometimes the developer-manager would overrule the product owner, since he or she was the product owner’s manager as well. 

In some situations, user stories might get injected as a result of urgent requirements from management. For example, a user story to show a report needed by the management might get injected in a sprint hindering the delivery of another user story needed by the customers.

A different type of structure, which can be frequently found in startups, involves a developer who is also the product owner. This structure would succeed only if the developer managed to overrule their inner geek in favor of the business needs of the product.

When the founder is not able to differentiate between his or her role as a developer and his or her role as a product owner, the success of the startup can be jeopardized. The few startups that do succeed are able to do so because of this key factor.

In normal cases, I would prefer that the roles in a Scrum team remain separated, as they should be, in order to enable each team member to achieve what is expected from his or her particular role.

Effectively creating a healthy environment in which a team can work properly is critical to the team’s success, and thus should be a top priority for management.

Have you ever worked in a team with mixed roles? I would like to hear about your experiences and thoughts in the comments section below.

I Played LEGO with My Team!

 

As 2016 came to its end, I wanted to do something different with my teams. I decided to try LEGO® Scrum which was proposed on Lego4Scrum.com  and highly rated by many practitioners.

I won’t explain how this game is played since there is a very good guide on the website, but I will try to share my experience and the lessons the team learnt.

My main goal was to coach the teams on how different teams can work on the same product, share the same backlog and plan sprints together. I divided my two teams into three smaller ones, four members each. I acted as the PO and tried to simulate several real life scenarios, like changing priorities and team members getting sick during the sprint.

Reasons I Chose to Build LEGO City

We chose to build a LEGO® city. The reasons?

We are building a product that is very similar to building software. You can decide on several buildings aka user stories which can have different levels of complexity and require different amount of time. It is something tangible the team can feel and they can see the direct effect of their decisions right away. It can be fun. Playing the Game

First I presented the training’s agenda and how we will organize the sprints and so on. Afterward, I presented the requirements of the city and we wrote the user stories together.

We did the estimation using a fast estimation technique, “swimlane sizing.” We created several groups with different story points, then each team nominated one member to place different user stories in the group where it would fit more. Then a sanity check was done where all the teams reviewed the estimates to make sure everyone had the same understanding.

As soon as we started with the first sprint, many issues facing newly formed teams were obvious: there were alpha males, shy persons, people who didn’t want to make decisions, etc.

As a result, two teams failed to deliver their committed scope. One team decided to work on the design of the city and drew it on paper for others to place the finished buildings, i.e., the integration environment was missing. The other team spent too much time building a “perfect” building and didn’t manage to deliver the second one.

On the second sprint, a team member of the “successful team” got sick and they didn’t manage to deliver, while the other two teams delivered all they’d committed to.

Just before the third sprint, there was a change of requirements and new features were requested. The teams estimated them and each team worked on one of the new features while some of the previous user stories in the backlog were left behind.

One of the teams working on one of the new user stories finished a little bit earlier and tried to “add” more features which were not required. This led to making the finished building fall apart. They managed to fix it by the end of the sprint, but it was a good lesson.

My Remarks

At the end we had a debriefing or a retrospective to get feedback. Here is my overall feedback on the game:

The game is fun, of course, but also simulates what happens in real life. The game is also stressful, we had very short sprints (seven minutes) as well as the meetings. Not everyone loves games in the office. If teams plan together, they can work on the same product, but if the teams are not co-located, it will be more challenging. What the Teams Learnt

Since it was similar to real life, there were many lessons the team learnt during this practice. Also, the teams appreciated trying something new and fun. Here is a highlight of some of their comments:

Scrum coaching is not always boring and we can have fun at work. Several teams can work on the same product and share the same backlog. While designing the city, the team was trying to reach the perfect design which cost them a lot of time. Gold plating is harmful. Don’t get tempted to add features that were not initially required unless they are needed. While committing to delivery, leave some room for emergencies, which means taking risks into consideration.

In general, I liked the session and I would like to do it with more teams involved in the future.

Have thoughts about this exercise? I would like to read your thoughts on the idea and practice itself in the comments below.

5 Signs Your Team is Lacking the Agile Mindset

When a Scrum Master joins a new team—whether it’s a team new to Scrum or one that has been practicing Scrum for a while—he faces different challenges. Therefore, the duties and focus of the Scrum Master for the first days are different in both cases.

In the first case, where the team is new to Scrum, most of his time and focus is used to teach and coach the team through Scrum. There is often a standard approach to how the team will be introduced to agile then Scrum.

On the other hand, when he joins a team with only some Scrum experience, he needs to act differently. For example, he needs to watch and observe more how the team is acting and how the members are interacting together to see if the agile mindset exists.

Some teams think they are agile by holding the prescribed meetings, but this is not the essence of agile. This type of team needs to be coached to cultivate the agile mindset, regardless of which framework is in practice.

There are many signs that indicate the lack of an agile mindset. Let’s look at some of the common signs that should send a warning signal to the Scrum Master that the team needs to refresh its Scrum and agile knowledge.

1. Knowledge Silos

One of the teams I worked with in the past used to have each developer working on a specific part of the product, and only he knew about it. Whenever a problem happened, they needed to wait for him to fix it.

This can also manifest when certain persons are pre-assigned to specific tasks or user stories during the sprint planning. This behavior prevents the team from working on priorities; rather, each person would work on the part he/she knows without considering the deliverability at the end of the sprint.

Another drawback of such behavior is the lack of team spirit and teamwork, since each one will be working on his/her own island without caring about what happens on the other island.

2. Not Working on Top-Priority User Stories

Teams working on a user story at the bottom or in the middle of the sprint backlog miss the concept of prioritization, and it could also signify a conflict with the product owner or a product owner who is not doing his homework.

Having a prioritized sprint backlog, and of course, a product backlog, is a product owner’s main responsibility to maximize the value delivered each sprint. If a team decides to work on a user story at the bottom, it is either the user stories that are not properly prioritized, or the team needs to understand the importance of picking work based on priority.

3. Separate User Stories for Testing

Having separate user stories only for testing of other user stories, whether these user stories are in the current sprint or a previous one, signifies that the team either doesn’t have a definition of done (DoD) or they don’t understand the meaning of deliverability.

Although it is acceptable to have separate user stories for developing automation tests, it’s a big red flag when you have user stories for “testing” only. In this case, the team needs to be coached to understand what it means to deliver a working product increment at the end of the sprint and to define their Definition of Done.

Without verifying your implementation, you can’t make sure that you are delivering a working software.

4. No Visibility of the Burndown Chart

If the team doesn’t have or doesn’t use the sprint burndown chart, their progress won’t be clear to them. The burndown chart is a tool to show very easily and quickly how focused the team is. The team might feel they are doing a lot of work, but yet they have flat burndown. This means they are not delivering, and they need to regain their focus to deliver more often.

Another misunderstanding that I have experienced with some of the teams is when they ask to have their burndown chart burnt based on tasks finished rather than user stories.

I consider this a bad practice, since it gives them an illusion of achievement, and at the end of the sprint, you might be surprised by having so many tasks finished but not delivered because the whole scope of the user story, including testing it, was not finished.

5. They Estimate Only for the Upcoming Sprint

Although it is one of the basics of agile to a have prioritized, estimated backlog, some teams might estimate only the scope of the upcoming sprint during backlog grooming sessions. Some teams don’t even have these sessions.

Planning only per sprint is dangerous since it doesn’t allow the product owner to anticipate or plan when certain features will be released. In these cases, the Scrum Master will need to teach the team the several levels of agile planning, and the value of having a prioritized estimated backlog for the team and the customer.

These are just some of the signs I have experienced when joining a team that let me know that the team doesn’t yet have an agile mindset, and more education should be the focus. Have you seen signs like this when you’ve joined a team? Do they exist in your current teams?

I would love to get your feedback in the comments below.

How to Use Team Resistance to Reach the Agile Mindset

Agile relies to a great extent on the team and how team members interact with one another to achieve the expected goals. There is no simple formula or “golden rule” for building a high-performing agile team, but a combination of activities and tools can help achieve this goal. Even in the face of resistance, an agile mindset can be cultivated.

Building an Agile Team is Different

One of the most challenging activities for any leader is to build a high-performing team with members that work together in harmony. In “Developmental Stages of Small Groups” and “Stages of Small Group Development Revisited,” Bruce Tuckman finds that teams go through five phases of development:

Forming Storming Norming Performing Adjourning

To reach the “performing” phase, a lot of effort is needed by the leader to make the team members understand each other’s work habits and create a synergy among them.

When working with an agile team, we can recognize that there is more effort needed by the agile coach or Scrum Master. In addition to helping the team evolve through the common development phases, team members should be trained to change their mindset to think and act in an agile way.

When a team achieves an agile mindset, it can work independently with minimum coaching or guidance.

This last step is as difficult as--if not more difficult--than the other team development phases.

Also, this last step is usually the phase where the team develops most of its resistance, because of the tendency to focus on solving technical riddles rather than delivering business value.

There are several tools that a coach or a leader can use to overcome this resistance, and help the team acquire the proper agile mindset.

Team Resistance

When a development team is in a performing phase, the developers gain more confidence in themselves and feel that they need less coaching or guidance—or sometimes none at all. This excess confidence might lead in many cases to an increased resistance to the coach’s advice to develop an agile mindset.

So what should an agile coach do when a team decides to make a move that the coach believes is anti-agile?

Before proposing solutions, the agile coach should keep in mind that this situation has both positive and negative aspects ...

Positive aspects:

You have a good team that can agree on a single decision The team is in the performing phase, because they are confident and trust one another They are demonstrating dedication; from their perspective, it is better for the project to do it their way 

Negative aspects:

The agile mindset is not yet there How to Use Team Resistance for Coaching

Of course, the first action should be to show the team the drawbacks of such a decision and how it would affect the deliverability or the consistent pace of the team, which eventually would have an impact on the product.

But what do you do if they insist, and the product owner is supporting the decision, hoping to gain the development team’s trust?

Here are some tips that might help, but should be executed carefully to avoid backfiring:

Agree with their decision even though you believe it is wrong If there are consequences to their decision, let them experience them until the end of the experiment, whether it takes one sprint or more (but I prefer to limit it to one sprint to be able to repair the damages as soon as possible) At the end of the experiment, hold a special retrospective to reflect back on the results of the experiment and the pain (if any) they went through During the retrospective, make it clear that there is no blaming (Rule No. 1), only learning; without a proper retrospective that focuses on learning rather than blaming, they might lose their confidence, so you must be careful when using this technique Since it was a decision that was driven by lack of agile experience, they should be willing to listen and learn more; this is your golden opportunity to enrich their minds with agile concepts, and make them understand the reasons behind them

Hopefully after an incident where something goes the wrong way, the team will start to see things differently. At this point, you begin to cultivate a well-developed team that embraces the agile mindset as a compass for future decisions.

Resistance Can Be Your Friend

It is always challenging to coach agile teams, and a coach should possess many skills and have many tools to help him or her get the best out of the team. Although team resistance to agile concepts might seem like a bad sign or a challenge, it could be a golden opportunity to coach the team to change its mindset when other techniques might fail.

What do you think about the techniques here? Have you tried something similar or different? Let me know in the comments below.