Monday, October 1, 2018

Taking the scrum retrospective to the next level | David Tzemach


The sprint retrospective meeting is one of the most important meetings in the scrum framework and should therefore be treated responsibly. However, planning and running an effective scrum retrospective is much easier said than done. Over the years, I’ve learned that there are some basic tips that can help increase the effectiveness of these meetings.

A few words about retrospectives

Retrospectives are important because they allow the team to concentrate both on the things that are keeping them from fulfilling their full potential in the agile environment but also to share the things that are working for them and that they want to preserve. During the meeting, the team has a safe space to discuss problems. But that is not all: the meeting also allows the team to feel empowered and share their achievements, celebrate successes and increase their morale (for more information, see: The agile retrospective meeting, everything you should know).

So what can go wrong?

It is easy to understand why retrospectives are important as (what I love to call) the “engine” of improvement. However, there is a huge gap between using a preliminarily written script and actually having a retrospective. It can work maybe once or twice, but it usually starts to negatively impact the team to the point where they start treating the retrospective like another meeting that they are forced to participate in because of its part of the scrum framework.

Another crucial issue is impediments that are not handled and monitored by the scrum master. Think about a team that is fully excited to share their problems in the retro meeting, but one week later, the scrum master presents the impediment board with the exact same problems without any real change. How do you think it will influence the team’s willingness to share their thoughts? Why would they share them if they know that nothing will actually change?

As I mentioned, retrospectives are critical for the team and probably the most efficient way to improve not only the process but also team motivation and teamwork. Therefore, the big question that remains here is how to make each retrospective better than the previous one. To answer this question I’ve created a list of tips that helped me throughout the years that I hope will help you.

Tips

A safe environment is key

Retrospectives allow team members to share impediments that hold them back from achieving their full potential. As such, team members must feel safe to share their insights about any problem that they see. If the meeting environment does not allow them to feel comfortable and safe to share those insights, chances are that they will choose not to share. This makes it impossible to mitigate problems and achieve continuous improvement.

A few things that can help:
  • Once you recognize that a team member has nothing to say, have a 1:1 conversation post meeting to understand the real cause. Team members that do not share information are most often the ones that have the biggest contribution.
  • Ensure that the meeting is conducted in a comfortable physical environment that is agreed-upon by all team members.
  • Avoid finger-pointing during the meeting. Retrospectives are not about personal blame.


Do not cancel the meeting

Although retrospectives are very important for the team, there are often times that the team will cancel the meeting because they do not have the time, power or motivation to have it. In addition, in many cases, there is an external crisis such as a critical bug in production, customer issues, etc., that force the team to cancel the meeting.

The basic rule is that no matter what you must ensure that there is room for retrospectives. If you are not able to conduct it at the ordinary time (usually the last day of the sprint after the review meeting), make sure the team finds the time to conduct it the following week prior to the planning meeting. If you still cannot find the time, at the very least provide a platform for the team to share their inputs and discuss them as early as possible during the next sprint.


Are the meeting outcomes actionable?

The value of retrospectives can be measured by a simple test of how many of the items that were raised during the meeting were implemented. This shows the team that there is an remedy for their problems. What team members will want to participate if there are no real answers or improvements for their items? To provide good solutions, we must make sure to start from the basics.

What do I mean by basics? 
  1. Start with documenting those problems that allow tracking (an impediment backlog is a good start).
  2. Make sure to prioritize the items that provide the most ROI for the team, and always let the team decide which items are most important to them.
  3. Make sure that each item can be mitigated with a practical action plan; items that cannot be mitigated with an action plan must be re-discussed and broken into smaller items.
  4. Set the goals, and do not commit to items that you cannot really handle.
  5. Make sure to show the team the improvement from the previous sprint
By following these simple steps, I can assure you that your retrospectives will become much more efficient and result in increased collaboration from the team.


Break the Ice if needed

The best retrospectives that I have taken part in were ones in which every team member had the confidence to say whatever he or she wanted to without being judged by the other team members. Retrospectives will never be as good as they can be when team members do not feel comfortable, confident and in a safe place.

A few things that can help:
  • The scrum master should start the meeting with general clarifications about the meeting’s rules of engagement and ensure that every member feels safe enough to speak.
  • The scrum master should start with his or her own thoughts about the previous sprint if no other team members volunteer to break the ice. If you do this, chances are that the rest of the team will feel confident enough to share as well.
  • Another option for breaking the ice is by asking the team a simple question, such as “How do you feel today?” or “Does anyone want to start to share their thoughts?” or “It was a great sprint for us; what do you think?”
  

Facilitation is the foundation of every great retrospective

The facilitation process is relevant to all scrum meetings but is particularly relevant to retrospectives. Why is that, you may ask. What is the difference between this and other meetings? Well, besides the obvious differences, there is one thing that pops out. Retrospectives are strictly owned by the team; external stakeholders are not allowed in (which they are in all other meetings as contributors or silent observers).

A few things that can help:
  • Don’t invite any stakeholder who could influence the team’s freedom to speak. Ensure that external stakeholders that arrive without notice do not take part.
  • Ensure that all team members are familiar with what is expected from them during the meeting.
  • In case the team wants to add external stakeholders (which is possible with the approval of all team members), make sure that they know the meeting rules and what is expected of him.
  • Make sure all team members arrive prepared for the meeting.

Review progress from the last retrospective

The main target of a retrospective is to help the team flourish while removing the impediments that hold them back. One of the keys to increasing collaboration and team motivation is to show them their progress since the last retrospective. The team will be more motivated to participate if they see that their ideas, complaints, and words actually mean something and were not made in vain.

As part of each retrospective, the team can share many items that they want to improve that require smaller changes or share only a few items that require more effort of one or more sprints. Now, the thing that really matters here is that you show some kind of progress, even when you do not have the complete solution for their problems. Keep in mind that each item is prioritized and you therefore need to address the most important items first. If the top items are blocked, do not wait but start mitigating the other, less prioritized items and move back to the top prioritized items when possible.


Make sure you cover the positive aspects

Unfortunately, many teams that focus on their problems forget to talk about the things that went well and that they want to keep. Talking about what went well motivates the team by showing them the things that helped them succeed and maintains the team’s good habits of collaboration and hard work.

Talking about the positive aspects also allows the team to see that there always are positive aspects. My suggestion is that you always create a balance and discuss both the positive and negative aspects. During this time, you should show the team how the negative items (that were mitigated) became strengths and not weaknesses. Tracking will provide the best platform to get the team to understand the importance of the meeting and its benefits.


Rotate the meeting facilitator 

The scrum master is usually responsible to facilitate scrum events, but I believe that this may be more relevant to new teams that just started an agile transformation and are still not self-organized. Once the team becomes self-organized, there is no reason for the scrum master to remain the meeting facilitator.

In my opinion, it is a good idea that the meeting facilitator be changed each retrospective. By following this practice, the team will gain more ownership of the process and will want to participate because they know that they can really impact the team’s empowerment.

Once you decide to follow this practice, it’s important that you let each member conduct the meeting following their own personal approach and agenda (under the clear boundaries of the meeting), which will help increase their motivation to succeed as meeting facilitators.


How efficient is your retrospective?

A common failure of agile teams is their inability to determine how efficient their retrospective really is. It is important that the team includes items on the retrospective itself to determine if they can improve it or not. Questions that I usually use during retrospectives are:
  • Do you think that our retrospective is efficient enough?
  • Is there anything that you want to change in the process of the next retrospective?
  • At the end of the meeting, can you share feedback on the meeting?

Retrospectives in a different location

One thing that I’ve found to be very helpful in boosting creativity, brainstorming, and motivation is to conduct retrospectives in different locations once in a while. Conducting the same meeting in the same location creates a sense of routine that we do not want to see in agile teams. My suggestion is to take the meeting outside the office every two to three retrospectives, such as at a coffee shop or at the beach. Just give it a try, and I assure you it will be worth it.


Root Cause Vs. symptoms

Retrospectives are made to allow each team member to share the impediments that affected their ability to succeed. Therefore, when looking at what needs to be improved, there is a very important rule that I always make sure to keep, and that is to understand the root cause of any item and not just its symptoms, which is usually what is provided in the original input.

The best example for this issue is if there is similar input every sprint. There are many reasons for this, and it’s important to correlate between the items to see that you simply cannot fix the issue without understanding its root cause.

There are many techniques that you can use for root-cause analysis (RCA), which I will share in subsequent posts, but one approach that always works is RCA using the 5 whys (just search for it and you will see why).

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile




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.

Summary

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.

Example:
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: 

Technology
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.

Processes
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.

Employees
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

Monday, August 27, 2018

What do testers in agile teams do when there is nothing to test? | SupremeAgile


In the last eight or so years I have been involved in more than 50 agile transitions as an implementer, trainer or consultant. Each transition encounters its own challenges and complexities, which of course has led to many questions from the business and agile teams.

One question that keeps coming up in almost all agile projects is: "What should testers do during the sprint when there is nothing to test?" This issue is often encountered. Think about the beginning of an iteration, when developers start coding, but there is no build that they can deliver to test in the first few days (or more) of the iteration.

Well, I think that in the current software industry testers should know how to code in a way that allows them to add more value to their teams and stay relevant. (For more information, please read my previous article here.) Unfortunately, in many cases, testers have neither the knowledge nor the skills or willingness to make this transition.

In this case, I will say that the tester should be preparing for tests at the user-story level, which include the test strategy and test methods to be used. Additionally, they should prepare test environments, so when there is available code to test, the test process can start immediately.

During the planning meeting at the start of each iteration, the team commits to the stories they intend to deliver at the end of the iteration. As part of this commitment, the team also estimates the work and starts breaking down stories into smaller tasks that they will use as part of their day-to-day activities.

Let’s focus on the task-breakdown process. During this process, the team usually tends to work on programming tasks. However, there are many other non-programming tasks that the team needs to accomplish during the iteration. Now, if the team spends time trying to identify and estimate each one of the non-programming tasks during the sprint planning meeting, chances are that the tester can contribute quite a lot, even if he does not have the necessary coding skills and there is no testing to do right now.

Let's see some examples of the non-programming tasks that often need to be done during the iteration:
  1. Break down user stories into tasks.
  2. Talk to external resources that can help the team (such as designers and tech experts).
  3. Help the team handle impediments.
  4. Writing test scenarios.
  5. Investigate new automation tools.
  6. Set up a test or development environment.
  7. Improve the development and testing processes.
  8. Improve the build-creation processes.
  9. Document checklists, health-checks, release notes, etc.

The tester as bottleneck

Up till now, we reviewed the common situation where the tester does not have anything to test during part of the sprint; conversely, the tester may become the bottleneck of the team. Think about the following scenario. A few days prior to the end of the sprint the tester receives stories to test without having a real chance to test everything. What do we do now? Well, we can remove this bottleneck by involving all team members in the testing process. The tester decides which tests to do himself, and which tests should be delegated to the rest of the team. That's what cross-functional teams are all about!

Test Driven Development (TDD)

If the team is using TDD as their preferred software development process, it means that team members spend more time writing test code from day one. In this case, what value does the tester bring? Well, the tester should pair-program with the developers that are writing the test framework for their code.

If the tester has the coding skills he can do much more in TDD by helping the team write the tests, but if that's not the case, he should still pair-program with developers to suggest tests for better test coverage.

If the team is not using TDD, or if they've already written all the test cases that will be implemented by developers using automated tools, the tester should add value by simply doing whatever he can to help the team achieve the iteration goal, just as we’d expect to see from any other team member. 

Thanks to Tally Helfgott for proofreading :) 



Linkedin Profile

Tuesday, August 21, 2018

What can we automate in an agile environment? | Supreme Agile


Most types of testing benefit from automation, starting from basic unit tests all through system tests. As you know, unit tests don’t supply enough coverage to catch system regression failures. But running a set of manual tests before every check-in, which could be dozens of times a day, just isn't practical.

And this is a problem—a big one. Because when developers can't run tests by simply pushing a button, I can assure you that they will most likely not be motivated to run tests at all.

Let's talk about the kinds of tests that are most suitable for automation. Automation starts with an automated framework that allows developers to check-in their code often and receive quick feedback about its impact. So let’s start with this first. 

Continues Integration (CI) system

This is where we create the most important, albeit simple and logical, a ground rule for automation: due to the nature of agile software development, which is faster than any other approach, agile teams should focus on automating any repetitive or tedious work involved in developing software.

And no candidate is better for this than automating build creation as part of an agile development process. Due to the fast nature of agile development, the team should be able to create numerous builds per day, especially to test newly added code.

CI systems are crucial in an agile environment. Continuous integration and build processes are the two systems that give that greatest ROI of any automation effort:  
  • CI allows for immediate feedback at the unit-test level (in case that you have the relevant unit tests to support it).
  • It reduces many of the risks involved in adding new code without testing it.
  • It allows the team to create and deploy numerous (stable) builds and allows for multiple check-ins per day.
  • It improves communication because team members can receive a notification once the build is ready without needing to check the status.
  • CI systems speed up testing time by reducing the number of errors at the unit level before these errors become apparent in advanced phases of the testing process.

Based on the above, agile teams must implement continuous integration and build the framework as soon as they can. Although it requires continual maintenance, it’s the only option for agile teams to succeed and reduce technical debt in large complex projects.

Based on these simple facts, you may see that agile teams must implement continues integration and build the framework as soon as they can. Although it requires continual maintenance, it’s the only option for Agile teams to succeed and reduce technical debt in large complex projects.

Development and Test Environments

Agile teams need to test and develop in a fast-changing environment; as a result, there is less room for the creation and maintenance of work environments. Agile teams can use automated deployment of their environments without multiple hours of manual work.

In addition, the team can use automation to handle many other areas related to their work environment:  
  • Creation and cleaning of the testing data and configuration.
  • Setup of specific topologies and architectures.
  • Simulating a specific scenario for reproducing a bug. 

Testing of the User Interface (UI)

The agile development process embraces the approach that the team must deliver an incremental working functionality at the end of each iteration; as a result, the team will usually execute basic automated regression tests at the GUI level.

As I mentioned earlier, I'm a great believer in automated testing, but in some cases, we really need to think about whether we want to use it, especially when we want to test the user interface of an application whose GUI changes.

To overcome the challenges of GUI testing, there is great importance in selecting the most suitable tool for the job, one that’s easy to maintain and flexible enough to absorb changes. This is probably the most important key to successful GUI automation.

Testing all layers of the application

I'm a great believer in automated solutions that can reduce manual testing efforts to the bare minimum necessary. It starts at the first layer of the application, by running unit tests that we all agree is crucial in reducing problems that when found in that layer of testing won’t become a bigger problem later.

Next, we have the second layer of component tests. Programmers test components as a whole module by using a set of inputs and outputs that the module produces. The third and, for me, the most crucial part in the testing strategy, is integration tests, where modules are tested together as one suite. And if that is not enough, why not test the whole system by running the fourth layer of system tests, which test the entire application as a whole system.


Performance, load and Stress tests

If you’ve ever been involved in the testing process that included one of the testing types mentioned above, you probably know that it’s almost impossible and certainly ineffective to use manual testing methods as the preferred way to run them. Furthermore, there is a wide range of tests that you simply cannot run without automation tools.

In addition, using manual tests will not provide the accurate test results we can achieve by using dedicated automation tools that can simulate the exact scenario without any human interference that may affect the testing process and therefore the results.

Thanks to Tally Helfgott for proofreading :) 


Linkedin Profile

My Presentations