Thursday, September 27, 2018

The retrospective as a fountain of shared knowledge | Supreme Agile

The retrospective meeting is one of the most important meetings in the scrum framework. It allows scrum teams to raise and share any impediments that influence their ability to flourish and improve each sprint. Therefore, the information that the team shares internally is usually extremely valuable because it reveals what holds back the team. This could be a product owner who delivers poor-quality stories, external stakeholders who interfere in team decisions, or a lack of technical skills that does not allow the team to become “cross-functional.” (For more information, see: The agile retrospective meeting, everything you must know.)

The information shared by the team is extremely important for the team. However, this is not all; the retrospective meeting has wider implications that can be relevant to other teams in the organization. One simple way to bridge the different teams is for one person in the organization to attend all sprint retrospectives and act as a coordinator who summarizes the main issues and success stories that apply to all the teams.  If you decide to follow this path, you need to ensure that the following guidelines are applied:

  • This person must be trusted by the team, who will agree to add him or her to the team retrospective.
  • This person should not by any means interfere in the team dynamics throughout the meeting.
  • He or she should be patient enough to participate in multiple retrospectives.
  • They must have the authority to take real action that can promote change
  • They should have the knowledge and experience to separate the important issues that are relevant to all teams and filter out items that are less relevant.

Another alternative that is more scalable is that each scrum master comes to a meeting containing all other SMs of the organization and shares the results of the team retrospective. The biggest advantage here is that we can do a retrospective on retrospectives and prioritize the main impediments that have the most impact on teams, the organization, and the process.

The final option, that each team shares the sprint retrospective report with other teams, is one I don’t recommend using. As you learn over the years, people will not read these reports, and even less will they take action based on them.

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Saturday, September 22, 2018

The sprint planning meeting that goes on forever | SupremeAgile

The sprint planning meeting is the longest meeting in the scrum framework and based on my experience it also the most exhausting meeting for most teams. The most difficult thing about this meeting is that team members often come to this meeting with the mindset that it will take the exact time written in the book…but it doesn’t!

In scrum we have a very important term called timeboxing. A time box is an agreed upon and limited box of time that is used by a person or team to perform a dedicated activity (see here for more information about timeboxing). Everything in scrum is time-boxed, including the scrum planning meeting, so what happens when the meeting time is near the end, and the team hasn’t determined the goal or sprint backlog? Do we end the meeting and continue it next week? Should we extend it? Do we just end it?

This scenario happens over and over, especially for new scrum teams that have neither the maturity nor the experience to conduct an effective sprint-planning meeting. So, what should one do in this scenario? To be honest, it really depends on what you want to achieve, but some common solutions that I love to use are:

Let the team learn the hard way

Let’s say that you have a team that is not willing to change their habits and continuously ignores the meeting’s timeframe. In this case, you can cut the meeting at the end of the time box, which will make the team suffer throughout the entire sprint. The ritual is that once you recognize that the team will not finish in time, you can address the team and let them know that the meeting ends in 10-15 minutes and let them choose whether to start the sprint with what they have or start all over again the next day (what do you think they will choose...?).

Extend the meeting and ignore the time-box

Another option is to ignore the fundamental foundations of agile and just extend the meeting while ignoring the meeting timebox. Based on my experience, if you do it once, it may help the team finish the meeting with a good feeling, but once the team makes it a habit it's a red flag for a much deeper problem.

During my many years as an agile consultant, I worked with hundreds of agile teams, and one thing that I know for sure is that you cannot let the team drag on the meeting. It usually doesn't help accomplish anything. People are tired and lose their ability to focus. If they failed to do an effective planning during the meeting, which can go from two to eight hours (depending on the length of the sprint), the chances are that the team won't manage it given the extension.

Another day, another chance

Another commonly used option is to re-schedule the meeting for the next day. In my opinion, it's the last option that I will use but still an option. If you decide to re-schedule the meeting, you must ensure that it does not become a regular solution for the team. You must perform a deep root-cause analysis (RCA) to understand why the team fails to deliver within the meeting time frame.


Each one of the solutions above is valid for specific cases, but to cut it short, no matter what option you use, the team must learn to conduct the sprint-planning meeting effectively as we expect to see in scrum. Make sure the team understands the importance of timeboxing so they can respect and follow it during the day to day activities. 

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Sunday, September 16, 2018

An open letter to all product owners | SupremeAgile

Dear Product Owner,

Your job is to ensure that the product backlog is always in great shape. This is your responsibility to your team. Throughout the years I’ve seen you take your role and abuse it by not focusing on what is important for the success of your team. If you want to succeed in your role, please focus on the things that really matter to the team. By this I mean:

Clear requirements

Each story that you add to the product backlog should reflect a customer requirement, and it’s your job to ensure that the story reflects this. I expect to see from you a clear definition of what the team should develop to meet your request. Dear PO, sometimes you fail to do your job and share PBIs that are incomplete because you were too busy with other, less important things. Remember that this is what is expected of you as the focal point between the team and the customer. Dear PO, please do your work and ensure that the team gets solid and clear requirements, so they do not need to guess what you wish for.

Definition of done (DoD)

Definition of done is not optional for you to decide on; the team needs it to understand what they have to do to fulfill your vision. How can you expect the team to succeed if you cannot provide a mandatory thing that will reduce errors and miscommunication?

Your responsibility as the team’s PO is to work with the team to create and approve both the feature and the stories’ DoD. This is just the way it is: you just don’t have the privilege to say that it’s less important or obvious and have the team figure it out.

One thing that I want to say regarding this issue is that I trust you not to use a generic DoD that you created two years ago and apply it to a new project without reviewing it first. I know that you are a hard worker; please respect yourself and your team by doing the simple things that they expect from you.

Technical stories

Dear product owner, I know that you want to succeed, and there is no real reason for you to add technical stories that you absolutely have neither the knowledge nor the experience to write. But it’s not a shame for you to learn your product, and by that, I mean the technical aspects of the product. I don’t demand you be on the same level as your development team, but at the very least you should be able to review the story and make sure it makes sense for the team. Learning will allow you to create a better story that the team can actually accomplish because you understand what you’re asking for and whether it is possible for the team to deliver it.

Now, I know that for some POs this is a hard thing to ask. So the only thing I can say is that at the end, it’s up to you to decide whether to take real ownership on your deliverables or whether you’re just acting as a basic proxy between the team and the customer.

Live and let live

Dear product owner, I know that there are a lot of expectations from you to deliver. After all, you are the one who interacts with the customer, who sometimes puts great pressure on you. I understand it, I truly do. But this does not give you the right to interrupt the team during the sprint with "small" urgent items that the team must deliver just because there is some pressure on you. I don’t have any complaints about changes that you want to make once the team is already committed to the work (this is agile after all), but there is a difference between working with us to understand how your requests will impact our commitments and just adding PBIs to the sprint without considering how it may cause us to fail. 

There is nothing wrong with collaboration

If I were in your shoes, I would use the vast knowledge of my team in all aspects related to my role. How can they contribute, you ask? Well, they can help in the creation of the technical stories or help with the DoD or just become more motivated to help you accomplish your vision because you collaborated with them.

Another aspect related to collaboration is your participation in the sprint meetings. Now, I know that sometimes it may seem less important to you, but know that your team needs you. I expect to see you at the daily scrum meetings to see team progress and the problems encountered on the way to accomplish what they promised you. Refinement meetings should be with the team; this will help the team understand and determine rough estimations that can change your prioritization. Believe me that the team will greatly appreciate the chance to reduce the time of the planning meeting.

You are the master of the review meeting, but it’s also your chance to build a strong committed team by sharing productive feedback. You will not achieve anything with negative feedback. Retrospectives? I know that in some cases you are not invited because it’s a "team" event. But I believe that you are part of the team and therefore must take part. I know that you feel that it’s not related to you, but I promise that you will see that you can become a highly effective contributor.

Planning meeting? Yes, you usually take ownership on the first part (story review and setting the iteration goal) and fade out while the team starts to estimate and add their tasks. This is your chance to collaborate with the team and answer all open questions, change the original prioritization, and break down stories that the team cannot accomplish in the upcoming sprint.

Why don't you focus on our team?

Dear product owner, I know that you want to show that you have the skills to handle more than just one scrum team, but to be honest you don’t. I expect from you to be 100% focused on our team. We trust you to lead us to a better future while we trust your judgment and decision making. 

You are not a child; you cannot get it all

Dear product owner, part of your job is to prioritize the backlog to allow the team to deliver the most important stories first. But you are not a child, and you know that there is a reason why the prioritization starts with the top items first, and there is a reason why these stories are ordered (if not, we have a bigger problem than I thought).

The prioritization process is used to avoid a negative approach of "must" have. Remember that it’s the team’s responsibility to decide how many stories they can deliver during a sprint. Yes, their efforts are based on your prioritization. But once they decide that they can commit to only ten stories based on that prioritization, you cannot use the word "must" for stories exceeding this number. This will result in over-commitment and less focus that will most likely lead to poor deliverables. 

Know your boundaries and do not cross them

As the product owner of the team, you must ensure that the team has a clear definition of what they need to do to deliver the best product for the customer. Sometimes you forget the clear boundaries between you and the team, which will most likely influence team effectiveness, morale, and motivation. Now, what do I mean by this? Let's start with the basics: you are not supposed to interfere with the daily work of the team. I know that you probably think that you know better than the team just because 10 or 20 years ago you were a developer or a project manager chasing people to deliver what you asked of them.

It is NOT your job to interfere with team decisions on how to deliver what you asked. Your job is to prioritize the backlog to allow the team a clear definition of what you really want. While I expect you to be at the team’s daily scrum meetings, this meeting is for the team and not for you to control and interrupt. And above all, you are NOT the team manager who tracks their progress and asks them what they are doing in their day-to-day activities. You can gain this information by coming to the team’s daily meetings, reviewing the burndown chart, or just seeing the PBI state in the sprint backlog. In addition, while your participation in the team planning meeting is highly requested and most appreciated, you are NOT allowed to push the team to over-commit on work that they will most likely fail to deliver.

What is your vision?

Dear product owner, as a team member in your team I have enough going on without having a clue about why we are building the product the way you decided. I know you always say that the product backlog is enough to us to acquire this information, but there are 100 other teams that are working on the same projects, so I ask how we can understand the company vision without your help. Dear product owner, I expect to see a clear vision of the product. This will help us see the big picture and gain a sense of ownership over the product.

Knowing the importance of quality

Dear product owner, I know that you have a lot of pressure to deliver features to our customers. And yes, I also understand that this is how you can show how good you are by pushing the team to deliver faster while focusing only on getting more and more new features that will add value to the customer. But now you can see that quick deliverables that do not give real attention to quality are starting to affect our ability to deliver at the same pace we used to.

Dear product owner, can't you see that we invest a huge amount of time per sprint to fix quality issues that come from the field just because you thought that there is no room for investing in quality aspects such as test automation, unit tests or performance aspects of the application? These now come back to haunt us in the form of technical debt and bugs that consume most of our time. Dear product owner, I hope that you now become smart enough to understand that quality is a crucial part of what we are doing. I know that from now on you will allow us to create PBIs to will help us to create a better product that will allow us to increase quality and reduce future technical debt. 

With love,
Your team

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Thursday, September 13, 2018

Regain team motivation by using slack time | Supreme Agile

Similar to real life, you can’t always sprint. If you're not a robot you need to rest in between sprints. What’s relevant to the best athletes is relevant to scrum software development as well. In scrum, the team works in short intensive iterations of 1-4 weeks, which is quite different from what we used to see in traditional software methodologies that are more similar to running a marathon.

Scrum sprints are very intensive because their main purpose is to provide value to the customer who is waiting at the end. At the start of the sprint, the team creates the sprint backlog that reflects their commitments (here is some pressure…) and needs to work in a very fast and changing environment. A team member who needs to work in such an intensive environment usually does not have time to relax and put off their tasks (the customer is waiting). So in the end, there is really no time for resting, which is highly important.

“Slack time” provides the rest time the team needs in order to regain their strength. But that's not all: it also helps increase team motivation and morale (important factors for creating self-organized teams). At the end of each sprint, the team conducts a review meeting, where the team presents the sprint deliverables, and a retrospective to discuss what the team wants to improve/keep in the next sprint. After these meetings both the team and the product owner will be full of information, tasks, and ideas that they need to implement in the upcoming sprints.

The common practice in the industry is that the scrum team starts the planning meeting right after the retrospective is over, so they can start the next sprint on the first day of the following week. And now for a simple question: do you think the team can effectively prepare for the next sprint with all the data they generated during those meetings (which is still related to the previous sprint)?

The answer is very simple: if the team immediately starts planning the next sprint, I can assure you that the chances are that the majority will not be focused enough to conduct the meeting as they could have had they had the time to stop and think about all information and lessons learned. The PO will not have time to prepare the backlog (based on the feedback received during the retro/review meetings), and so on.

Let’s give the team some slack

The solution to the problem I just described is to introduce some kind of slack before the team starts the new sprint. We would like to make sure the team has time to rest and think in the period after the sprint retrospective and before the next sprint planning meeting.  

One thing that I learned over the years is that you cannot always succeed with this approach, but at the very least, you need to try to give the team some slack prior to jumping into the planning meeting. To do so, sometimes I change the meetings’ timeframes by sending home all team members once they complete the retrospective of the current sprint and schedule the planning meeting for the next day or the beginning of next week.

Without using slack time:
Friday 10:00-11:00: Sprint review (Sprint 1)
Friday 11:00-12:00: Sprint retro (Sprint 1)
Friday 13:00-17:00: Sprint planning (Sprint 2)

With slack time (option 1):
Friday 10:00-11:00: Sprint review (Sprint 1)
Friday 11:00-12:00: Sprint retro (Sprint 1)
Friday 12:00: slack time.
Monday 09:00-13:00: Sprint planning (Sprint 2)

With slack time (option 2):
Thursday 08:00-09:00: Sprint review (Sprint 1)
Thursday 10:00-11:00: Sprint retro (Sprint 1)
Thursday 11:00: slack time.
Friday: Learning time
Monday 08:00-12:00: Sprint Review (Sprint2)

Note that in option 2 I added another day (Friday) that the team can use for learning or in some other cases to do whatever they think is best for them (in most cases they will invest the time to create a better working environment that will be worth the effort in the long term).

If you decide to use learning days there are some tips that can help:

  1. Learning days should be added per month and not after each sprint, so in the case of two-week sprints, we will add one learning day at the end of the second sprint.
  2. Although this time is dedicated for the team, you still need to see whether it adds real value. There is no reason to use these days without adding real value to the team, process or the business.
  3. Try to make this day global for the whole organization; it becomes less effective when some teams are working and some are resting.

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Tuesday, September 4, 2018

What is technical debt and how does it affect agile teams | SupremeAgile

Ward Cunningham, one of the creators of the Agile Manifesto, was the first to describe the concept of technical debt (Cunningham, 1992, OOPSLA conference). He defined technical debt by using the following logical metaphor:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite….The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.

Cunningham used the metaphor above to explain to his colleagues why creating software quickly to get customer feedback is a great thing. However, he addressed two main points (my own interpretation):
  1. The development team and the organization must become familiar with the consequences of creating technical debt, and what they will need to pay to reduce it to allow continued growth of the business.  
  2. The team must embrace the first key point during the design and implementation of the software.
Since this metaphor was published (the term technical debt was introduced earlier in the 1990s), there have been conflicts in the software industry about how to more accurately define technical debt. The software industry has expanded Cunningham’s definition of technical debt to include all the bad things affecting the software development cycle. These include:

Software defects 
All defects discovered during the SDLC and not removed by the team (classic examples are defects that the organization defers to a future project or iteration).

Outdated code design
Code design created at the beginning of the project that is no longer relevant due to changes in the software structure, architecture or technological improvements.

Poor test coverage
Poor test coverage leads to a sizeable number of defects and issues most likely to be found in advanced phases of the project.

Excessive manual tests
There is a reason why agile teams are pushing towards automating tests as much as they can. Manual testing does not allow the team to complete testing in a single sprint, and as a result, technical debt is created in future sprints.

What technical debt is NOT

A common misunderstanding about technical debt is that it refers to many other software project issues, which is an incorrect interpretation of what Cunningham intended for technical debt to be. According to Cunningham, technical debt does not refer to individuals in the team, incorrect processes used during development, or poor engineering quality that comes from lack of experience.

Let's review some software project issues that may be classified as a technical debt due to an inaccurate interpretation of Cunningham’s definition:

Delay in the delivery of a feature

Delayed features delivered to a customer should not be classified as technical debt. Although it’s a huge issue that may have a strong impact on the organization, it's still classified as feature debt.

Poor or missing training

In some cases, engineers will need the training to succeed with the different development and testing challenges. Lack of training is classified as training or educational debt. This kind of debt can be eliminated or improved through proper training from the get-go.

Lack of skills

Sometimes it is just the way it is, and not all engineers have the full set of skills to handle the different challenges the project entails. This type of debt is called skill debt. This debt can be easily removed by having the right people participate in the project.

The use of poor processes during the SDLC

Although traditional and agile methodologies use different processes throughout the software development life cycle, lack of knowledge on how to use them may cause deleterious effects. Regardless, this should be classified as process debt. This type of debt can be eliminated when the business understands how to apply these processes correctly.

UX issues
Poor user experience can make the software unusable for some, but it's not technical debt; it should be classified as UX debt.

Types of technical debt

As you can see from the previous paragraph, Cunningham didn't intend for technical debt to refer to process issues that led to bad design, problems with individuals in the team, nor any other issue related to business maturity.

This kind of debt can be eliminated easily if the organization provides the time and the training that allows development teams to learn better technical practices and better decision making throughout the project.

Now that we know what technical debt is all about, it’s time to review the three categories of technical debt.

Planned technical debt

This type of technical debt occurs when the organization or team makes an informed decision to generate technical debt with the full and calculated understanding of the consequences that this decision engenders (more risks, higher costs and less time to deliver new functionality).

When the organization decides on a strategic decision to generate technical debt, it becomes critical that the team let upper management know the compromises the team will have to make.

One great example is related to testing. In many cases when the team arrives at the end of the sprint and there are tight deadlines, they will decide to keep some areas untested to ensure they can deliver on time. The technical debt is areas of the application that are not tested, which will add more risk to the application. In addition, the team will have to postpone the feature planned for the following sprint in order to run the missing tests.

Another important aspect of planned technical debt is to ensure that the team and the organization maintain a record of their decisions. By creating documentation, the organization and the team increase the likelihood that the technical debt will eventually get removed. Otherwise, it will most likely be forgotten and become a bigger and unplanned problem in the long term.

Unplanned technical debt

This refers to any technical debt created by the team due to the use or execution of poor technical or logical practices. Examples:
  • Use of a poor design approach that leads to many defects in the application.
  • Inadequate communication among the different teams that leads to an ineffective integration process.
  • Insufficient risk management, which leads to critical errors and delays of the release.

Unavoidable technical debt

This type of technical debt refers to changes in the business and the fast-developing technology that, over time, allow the organization to create and adopt better solutions. It typically arises when the customer asks to add changes to the project scope after the project has already started. This results in an immediate cost such as adding new functionality to an existing part of the system. The easiest way to describe this type of technical debt is to say that it appears when a new business requirement makes the current code obsolete.

Managing technical debt

As we’ve seen, sometimes the business can control the technical debt and sometimes it cannot be predicted, but the main thing is that the business ensures it has the tools to handle debt no matter the cause. As the years have gone by, I’ve learned that there are three main dimensions that the business should focus on: 

The organization must follow the market to be aware of any tools and technologies that will help create better products, increase the work efficiency, and manage its technical debt.

The organization should ensure that the product backlog is updated with all the incomplete tasks that were raised during day-to-day activities. By doing so, the team will gain major benefits, such as the ability to prioritize their work, increased transparency for external stakeholders, and awareness of the effort they need to reduce the new debt.

The organization should ensure that it fosters a culture of accountability, awareness, and responsibility. By implementing this type of culture, the organization will create the necessary approach among its employees that will allow for reduced future technical debt and, at best, a reduction to the minimum necessary. 

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

My Presentations