Tuesday, April 21, 2020

How to increase team motivation and sustain it | SupremeAgile


The best agile teams are built from people who work together as one unit, where each team member has both the technical and the personal skills to allow the team to become self-organized, cross-functional and self-motivated.  These are all big words that I hear in almost every agile project, but the criteria to make a great agile team are almost impossible to achieve without one major factor: motivation towards a common goal.

So how can we improve team motivation and sustain it throughout the project? Prior to answering this question, I want to review the two types of motivation that we must encourage within the team to promote success:  Intrinsic and extrinsic  

Intrinsic motivation refers to behavior driven by personal internal reward, without the need for an external boost to increase motivation. This motivation is related to the person’s desire to succeed and achieve a certain goal. The main key for this type of motivation is that we must ensure that each team member has the chance to not just meet expectations as a member of a team, but also accomplish their own personal goals that will most likely increase both their own and the team’s results.

Extrinsic motivation, on the other hand, refers to an external motivating factor such as vacations, bonuses, salary increases or just getting a paycheck at the end of the month. We can treat this type of motivation as a desire to do something in order to achieve a specific reward.

To allow the team to become self-organized, cross-functional and self-motivated, we must cover both motivation types while searching for a balance between organizational and personal goals. One thing that I learned throughout the years is that there are no shortcuts. We must know our employees and the factors that motivate them. This is the only way to achieve both personal and team success.

The path to create a highly motivated agile team

Here I will share the most effective rules and principles that I use to increase individual and team motivation. I know that there are many other methods that you can use in one situation or another, but I never had a motivation problem that I could not resolve by using one of the following approaches.


Treat all team members as equals but know their differences

A scrum team is built from different people that are assembled  to achieve a common goal. It is nice to say that all team members are equal, but they are not. We always need to remember that each team member has his or her own set of skills, knowledge, and experience. Although we need to ensure that each member works under the same set of rules, guidelines, and goals, as they are equal within the team, the next level is to understand which team members are more suitable for accomplishing specific goals that may arise during a challenging development project.

A great example of this issue is a technical lead who is part of the team with vast knowledge in a specific technology that the team will use throughout the project. This technical lead will still work under the exact rules and boundaries as all other team members. Thanks to his knowledge, however, we can free up his time to focus on a single area and move all other activities (activities which may be less prestigious in the eyes of other team members, such as bugs, dealing with customers, and closing technical debt) to other team members.


Show interest in the team and its members

Throughout the years, you learn that motivation starts with just paying attention to the team and letting them know it. Think about them as your own child who wishes for a good word once you return from work, or how important it is for him to hear your appreciation for what he achieved today in school. They, like your child (as a team and as individuals), want you to listen to them, celebrate their achievements, and just pay attention to what they have to say.


Meetings, meetings, and more meetings

I’ve never seen an engineer who wants to participate in multiple meetings that just keep him from working. The scrum framework contains multiple events, which can be a motivation killer for those engineers who do not understand why they need so many meetings that just interfere with their ability to remain focused. This is especially true for new teams that just started working this way.

It is essential that each meeting that is added makes sense to the team; otherwise, it is just one more meeting that’s holding them back. If you add meetings, make sure they have a clear agenda so that the team does not feel like they are wasting their time in an already busy environment.


Increase interest with challenging tasks

Some people prefer to have some changes in their day-to-day work that allow them to regain their excitement and interest in what they are doing. There is some sense of excitement at the start of the project, and when starting agile there are massive changes in all aspects of the team’s work, which is enough to keep their interest.

After this period, the team will already have gained most of the knowledge that they need to work in this framework, and they will focus their attention on the ongoing daily activities that are part of every sprint (meetings, handling defects, etc.). This is where team members may start to lose their interest due to the repetition of activities without any new challenges. The best solution, in this case, is to break the routine by adding challenging tasks that will help the team regain their motivation and interest.


Supportive working environment

The working environment plays a very important factor in determining team motivation. Remember that the team will spend most of their effective hours in work, and therefore it is very important to ensure that they have a supportive and pleasant working environment where they feel comfortable working and developing as a team.

Set goals that will not fail the team to begin with

Think about a leader who sets unrealistic goals for the team, such as delivering features at the end of a sprint that the team has neither the knowledge nor the experience to handle, or asking the team to complete an integration with another team although the second team will not be ready on time, or asking the team to deliver a feature during a sprint that involves multiple external interruptions that will consume most of their time.

Setting a goal that a team does not have a real chance to meet is probably one of the biggest grounds for reducing team motivation. Will you have the right motivation after you need to present a demo of your work at the end of the sprint but fail to do it because you have been given an unrealistic goal? I guess not.

To make sure we allow the team to see success, the team must work with clear, visible and above all measurable goals that will allow them to succeed with a smaller chance to fail right from the beginning.  One classic example is a team that has huge technical debt that affects their ability to deliver real value to the customer. In such a case, we can set a goal of reducing this technical debt by five to ten percent per sprint. By setting such a goal, we can be assured that the team understands what is expected of them and measure it from sprint to sprint. In addition, the team will have the opportunity to create a plan and add all relevant stories that are related to this goal, which will increase transparency for external stakeholders.


Creativity that comes from real freedom

There is a reason why you hire smart people, and there is a better reason why we need to provide them with freedom to use their creativity while working on tasks. My rule is that you need to set guidelines for any task but allow the team to use their own creativity in deciding how they want to reach the objective. By following this simple rule, we allow the team to find superior solutions to problems based on what they thought was the best solution instead of just giving them some strict guidelines that will kill room for innovation.


Make room for mistakes

Mistakes are part of every solution and cannot be avoided. Team members will make mistakes no matter how talented and committed they are. The key here is to set clear boundaries that allow them the freedom to work and use their skills but reduce the percentage of mistakes that will have a severe impact on the organization. In addition, we must make sure that each member has the confidence to make mistakes because there are no “punishments” that will keep them from trying again.


Be clear about the prioritization

You all know that the product owner is responsible to ensure that the stories are prioritized in the order that will provide the best ROI for the customer. How is prioritization related to team motivation? Well, think about a planning meeting where the team must decide which stories will take place in the next sprint but with a product owner who fails to perform his job and does not prioritize the product backlog. Will it increase motivation? Probably not, because it will lead to an inefficient, long and less-focused meeting. If the team had a prioritized backlog, it would allow them to maintain focus without losing time on other stories that the PO later decides are less important just because he failed to determine it earlier.

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Sunday, March 24, 2019

Applying agile principles to automation projects | Supreme Agile


Automation projects can be very challenging, even for the most experienced teams. Each automation project has its own challenges, difficulties, and risks that cannot be forecast at the start of the project. In addition, there are other factors that can affect the project, such as the organizational culture, timelines, pressure from senior management and the available resources and their expertise.

In this article, we will see how agile teams can use agile values and principles to meet challenges when facing an automation project. Now, it makes sense that agile teams can benefit from the agile manifesto and its main ideas when starting a large, complex automation project. Just think about the main concepts presented in the manifesto: collaboration, courage, safe environment, continuous feedback, communication, and most importantly: continuous improvement.

Taking the Time to do it right the first time

Every automation project will demand an investment from the team prior to finding the best solution. In addition, an agile team works under great pressure to deliver commitments after a very short period of time; therefore, the team must know how to work with senior management to get the time they need to succeed with the project.

It’s very common that senior management focuses more on what the team delivers at the end of each sprint rather than on the work they need to do to succeed. Automation projects have a major impact on the whole project, but they are not delivered to the customer. This is why the team must get management to understand that implementing good automation solutions takes time and must explain the trade-offs clearly.

Implementing automation solutions the "right" way takes time because it demands upfront planning and investigation, similar to any other coding project that includes planning, design, coding, and testing. The team won’t benefit from the automation solution in the short term, but it will save a major amount of time in the long term.

Let's take the scenario of an agile team pressured to deliver a lot of features without being given the time to automate regression tests to ensure these features keep working once they are released to market. This common scenario will most likely lead to a large cost in the long term due to an accumulation of technical debt that will not allow the team to deliver the same business value they did at the beginning of the project.

To allow the team to succeed, the team must work at a sustainable pace that will allow them both to deliver the most valuable PBIs but also work on the frameworks that will prevent the need for manual test efforts in future iterations.


Mistakes are part of the solution  

Automation projects take time and a great amount of effort. During this time, the team will most likely make mistakes, such as lack of communication, and encounter technical issues.  In agile practices, mistakes are seen as just another way to improve the team and the overall quality of the product. Mistakes are the best growth engine for both the team and the individual. In addition, mistakes are great for triggering learning cycles. The more problems you have, the more you'll learn during the process.


Build the simplest thing that could possibly work 

Automation projects can be very complex even for the most experienced teams. To help deal with this complexity, we can use one of the best-known principles of Extreme Programming (EP), which states that teams should develop with simplicity by "doing the simplest thing that could possibly work."

This mantra of keeping things as simple as possible applies to automation projects as well as to any other coding project. For an agile team that needs to automate as a key to their ability to deliver fast and early, it might mean starting with a simple test design, minimal project scope (which will be extended at advanced phases of the project) and using the most simplified automation framework that does the job.

There is a very good reason why simplicity is a core agile value. Simplicity does not mean that the team does only the easiest things. The simplification mindset and practices will drive the team to think deeply about what they want to achieve and how to approach it step by step, instead of developing a large complex plan that will increase risk and uncertainty. In case of a bad choice, the team will have more room to handle their mistake.

Automation test projects should start at the lower layer of the application, the unit level, which can be easily automated compared to the other, more complex layers (component, integration, and system). Once the team has a solid test infrastructure at the unit level, they will gain more confidence in automating the higher levels of the application step by step and test by test.


Continuous feedback

Continuous feedback is a major concept in agile software development which allows agile teams to work in short iterations. The team gets fast, productive feedback at the end of each iteration instead of getting it at the end of the project (which is more relevant to traditional software development).

Automation projects can benefit from this concept because it allows the team to experiment with versions, automation designs, frameworks, and evaluation of the execution results while getting quick feedback and changing course if needed.

Automation projects will take at least a few iterations to find the automation framework— in-house framework, open source tool —used for implementation. At the end of each iteration the team will benefit from two streams of feedback, first when they present their work (during the review meeting) and receive feedback from the relevant stakeholders, and second by just looking at the work done and examining what's working and what's not.

The use of these streams will allow the team to understand whether they chose the right path or if they need to adjust the current solution to support the feedback they received. In addition, continuous feedback will allow the team to adjust their work without getting stuck in automation projects that consume many resources, time, and effort (which a team simply does not have in an agile environment).

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile


My Presentations