Tag Archives: Agile Methodologies

Is Your Agile Team High Performing?

agile team software technologyHaving an agile team can make all the difference in how your company functions. Agile teams are known to be more flexible and high performing, enabling you to ship out new products faster and stay competitive. However, simply calling a team agile doesn’t guarantee success. Companies have to work at being agile and that requires having certain skill sets.

There are six important characteristics a team must have to be considered agile. We will discuss those characteristics here and then discuss how your company can make its teams more agile.

Communication: Is Your Team Communicating Enough?

Communication is vital whether or not your team is considered agile. It’s important to always keep the lines of communication open, whether that’s through regular team meetings, email communication, or some other method, such as a Slack channel. Both team members and management should be able to give and receive constructive feedback on a regular basis, outside of the traditional annual reviews. While those annual reviews are still important, it’s good to be proactive throughout the year to ensure that your team is performing well.

Another important aspect of communication is expectations. Managers should lay out clear expectations for projects right from the start, but also provide opportunities for team members to ask questions throughout the process. There should also be a plan in place to automatically update team members about any changes that might need to be made to a project. Frequent communication is key because it’s the only way to create the feedback loop that is a must for every high-performance agile team.

Cross-Functionality

Cross-functionality is defined as a team with various functional expertise working toward a common goal. A cross-functional team will include at least one person each from multiple departments within a company. A well-rounded cross-functional team might have members from human resources, marketing, finance, and more.

The key to a successful cross-functional team lies in the ability of team members to work well together toward a singular vision. From the start, they have defined expectations and allow members the opportunity to let their strengths shine, while also learning other skills that will make them an asset to their current team and to other teams in the future.

Since agile tech teams require feedback from different teams so that product and software changes can happen faster, effective cross-functionality is a must.

Collaboration

A good agile team has the ability to collaborate irrespective of their strengths and weaknesses. The team members combine their strengths and weaknesses to create a team that is able to achieve multiple goals. Collaboration is best achieved when expectations are clearly set from the beginning of a project and teams are able to put their best foot forward.

Self-Organizing

A good agile team will be able to manage themselves without having to constantly be guided by a manager or a project leader. This isn’t to say they don’t need guidance, especially at the beginning of a project, but they should be able to take a concept and run with it, as long as they have the necessary resources available to them. A good agile team is also self-motivated and eager to prove themselves.

Is there alignment on performance objectives with other departments of the company?

As mentioned above, it’s important to measure performance objectives throughout the year and not just during the annual review period. Moreover, performance objectives should be aligned across the entire company. All employees should be striving for excellence, whether that’s within their team or within their individual role.

In this case, there should be an emphasis on product delivery rather than project delivery. If an organization hasn’t transitioned to a product structure, there may be issues in getting team members to align with one another. In such a case, the leadership should take on an expanded role in helping teams become more cohesive.

Metrics-Driven

As with any business, people are driven by metrics. There should be tangible goals that teams are working toward and they should see the results of those goals. The measurement of goals should be clear and concise. Setting tangible goals with measurable objectives can help the leadership see where teams are excelling and where they are struggling.

There are many metrics an agile team can measure, including sprint burndown, team velocity, release frequency, and delivery speed. When looking at metrics, it’s important to look at what went well and what needs work. By measuring these specific metrics, teams will have measurable goals to strive for.

It’s okay if you don’t currently work for or have agile technology teams at your company. It’s easy to turn things around and create an agile team that can work for you instead of against you. Just follow the recommendations above and your company will run like a well-oiled machine in no time at all.

If you feel like your company needs further support in becoming agile, Santex can provide you with the tools and resources necessary to help your team become more agile and better able to keep with the agile teams that already exist at other companies. Be sure to check out our most recent e-book, Best Practices for Outsourcing Development, for more information.

software outsourcing practices agile methodology

Seven tips for new Project Managers

Tips to improve project management skills

By Johan Tabori – Project Manager at Santex

The project management role has evolved very rapidly over the last two decades. The traditional view of “boss” has morphed into a combination of “facilitator” and “coordinator,” a description which is a better fit within agile organizations. The following tips can help you to improve your project management skills in today’s increasingly changing business environments:

1. Ensure healthy and friendly work environments.
Fear is the worst incentive to work, therefore, you want to make sure the team work environment is as friendly as it can be. By ensuring this, your teammates will trust you and you will be able to delegate responsibilities more adequately. The same goes for the client, because team dynamics can be affected by how good a relationship with the client is, so don’t be afraid to demand collaboration and mutual respect.

2. Know your team and client.
As a project manager, you need to wear your psychologist hat sometimes. As you move forward with the project, it’s very important to understand both your team’s and client’s mindsets. Understanding these mindsets will be very helpful when bringing up sensitive issues or when you need to resolve conflicts.

3. Quickly respond to communications.
Unless you are in a meeting or have an emergency, don’t wait too long to respond an email or call. If you’re not sure about the topic being discussed, don’t be afraid to ask for clarification. If it requires further investigation, let the sender know and promise you will look into it and get back to him or her as soon as possible.

4. Review project status with your client periodically.
Weekly follow-up meetings are the best way to keep your client and stakeholders informed. Make sure you cover key aspects of the project such as current status, scope, milestones, communications, and team updates.

5. Involve your team as much as possible in key decisions regarding the project.
In most cases, your team will have more technical skills than you do, so instead of imposing any particular technology, architecture, or framework, make sure these are agreed upon within the team.

6. Take the opportunity to learn.
Self-centered project managers fail miserably in accomplishing long term goals . Acknowledge your weaknesses and information gaps and learn from every team member and client.

7.  Demonstrate your value as a service provider before asking for more business.
Clients hate when they are presented with prospective new business at the beginning of the contract. They want to see you “in action” before they can start thinking about it. Once you have proved you are able to deliver value to their organization, they will come to you and discuss future projects.

 About the Author
Johan Tabori – Johan’s education as an informatics engineer prepared him well to become the project manager that he is today. A natural multi-tasker, he has been leading IT project teams in a variety of vertical markets and applications for more than 10 years.

Extreme programming… once again

By Jose Torres – iOS Software Engineer at Santex

Extreme Programming principles help us safely drive the work of building software.

Vague or constantly changing requirements are a fact of life. Instead of ignoring them, we should adapt our processes to reality. Extreme Programming (XP) principles exist to help us safely drive the work of building software. The web is full of information on XP, which can be synthesized as:

Lightweight, evolving, flexible knowledge to develop software.

The concept of XP first came about in the 1990s. It bears repeating though, because, unfortunately, many organizations have lost the point. Perhaps they apply technical principles and fail in their flaccid adaptation. Maybe they employ agile processes but little in the way of technical practices. Can these discrepancies be balanced? How can we fight back?

Move to an extreme state and embrace its principles. Some organizations resist this shift. One of the best ways to adapt to this change is by running a pilot of a small, internal project.

XP Principles state that at least two developers must work in a single workstation. To extend this concept, add one more step after the development sprint organization and consider having the team determine the number of developers who will work together for each user story. On the most critical user stories, place the whole team at a single workstation to discuss and then write production code.

XP Principles also dictate that there be a short release cycle for the product. To take this concept further, set up a specific time period during the day (i.e. every three hours) to continually release the product. You could also consider a full integration, if possible. This will help relieve the problems of production integration later, as integration is always happening. As David Farley states “reduce cycle time and the rest falls out.”

Keep in mind that having an active local community can help you to go further. In London, for example, there are multiple extreme programming initiatives like XProlo, eXtreme Tuesday Club, and XPDay, all of which are dedicated to XP practices, where people can join and share knowledge. We should continue creating initiatives and networking to create communities and evolve together.

There are many ways of actively moving forward when integrating extreme principles in software development. As main actors, we are responsible for tracking the efforts of our organizations as they assimilate and take real XP practices to the next level.

About the Author
Jose is an innovative Software Engineer who specializes in developing iOS applications for both iPhone and iPad. Skilled in creating business applications as well as games, Jose enjoys mentoring colleagues and fellow developers.

How Agile methodologies mitigate cognitive biases that lead projects to failure

By Walter Abrigo, Managing Director at Santex

I want to emphasize in this article how the existence of two cognitive biases, which are almost always present in our daily lives, position agile methodology practices as one of the most adaptable frameworks for project monitoring and management, in general. This is especially true when the context of the given project development is complex, has changing requirements that are poorly defined, and where innovation, competitiveness, flexibility, and productivity combined are critical to achieving the desired results.  

Cognitive biases

  1. The emotional aspect of our decisions and choices.

  2. The fallacy of planning.

By reviewing each of these biases, we are able to see how people’s behavior fits better and more consistently within the structure of Agile methodologies.

Our decisions and choices are emotional

The following cases demonstrate how, in our every day decision making, we often forget the Base Rates (or the true distribution of events). Additionally, we strive to make sense of representative stereotypes, we seek causes and explanations, and we have a natural aversion to losing whenever there is something at risk.

First Case: Forgetting the Base Rates (the true distribution of events)

Tom is extremely intelligent, although he lacks true creativity. He needs order and clarity, and prefers systematic organization. He has a strong competitive drive and seems to have little interest and sympathy for others. He does not enjoy dealing with other people. Although he’s self-centered, he has deep moral awareness.

Let’s order the following nine areas of expertise according to the probability that Tom would be a student in any of these fields. We’ll use one for the most likely and nine for the least likely.

  • Business Administration

  • IT

  • Engineering

  • Humanities and Education

  • Law

  • Medicine

  • Physics and Biology

  • Social Sciences and social work

Most will agree that Tom fits well with the stereotypes of smaller groups of students, like IT and engineers, but would fit poorly into larger groups, like humanities and education, social sciences and social work. This is an example of how we substitute the probabilities of the Base Rates for representative stereotypes.  

Second Case: Prejudices based on stereotypes

Linda is thirty-one years old. She’s single, outspoken, and very bright. She majored in Philosophy and, when she was a student, she was very concerned about the issues of discrimination and social injustice. She participated in several anti-nuclear protests. Given this information, which of the following scenarios fits best with Linda’s personality?

  1. Linda is a bank teller.

  2. Linda is a bank teller and activist for the feminism movement.

Most will agree that Linda is well suited to the role of “bank teller and feminist.” The stereotypical teller may not be a feminist, so including this detail adds more emphasis to the description. Nonetheless, both feminist bank tellers and regular bank tellers share the common fact that they coexist in the world of ‘bank tellers.’

P(teller)=P(feminist teller) + P(teller not feminist).

Third Case: Seeking causes

Take the genders of six children born one after the other in a hospital. The sequence of boys and girls is random. Each event (birth) is independent of the other, and the number of boys and girls born in the hospital in the last hour has no effect on the gender of the next child. Now consider three possible sequences (M = male, F = female):

  1. MMMFFF

  2. FFFFFF

  3. MFMMFM

Are these sequences equally probable? The intuitive answer is, “of course not!” but that is false. Because each event is independent and the results M and F are both (approximately) equally likely, all possible sequences for the six births are as likely as any other. Now that we know that this conclusion is true, it seems counterintuitive because only the third sequence appears to be completely random. Our minds are built with associative machinery that continuously seeks causal relationships, and this tendency leads to serious error in our evaluation of sequences that are truly random.

We are hunters of patterns, believers in a coherent world in which regularities (like a sequence of six girls) are not accidentally produced, but rather the effect of a particular cause or someone’s intention.

Fourth Case:  We are willing to risk more when it comes to losses than gains.

Situation 1: Imagine a group of people where each one has $3,000 and you give them a choice between:

  1. Receiving another $1,000, or

  2. Flipping a coin and playing the $1,000 for double or nothing: if they win they’ll receive an additional $2,000, but if they lose they get nothing.

What would you choose?

Situation 2: Imagine a group of people where each one has $5,000 and you give them a choice between:

  1. Giving up $1,000, or

  2. Flipping a coin to play $1,000 for double or nothing:  If they lose, they give up $2,000, but if they win they don’t lose any money.

What would you choose?

Most of us in situation one prefer option one and most of us in situation two prefer option two. The interesting thing here is that the odds of the four options are identical, but differ considerably in our minds. We are more willing to take a risk when it comes to LOSSES and are more reluctant to take a risk when it comes to GAINS.

The fallacy of planning

The fallacy of planning is one manifestation of an omnipresent optimistic bias. Almost all humans see the world as less harmful than it really is, our skills better than what they really are, and our goals easier to achieve than they really are. We also tend to exaggerate our ability to predict the future, which exudes optimistic overconfidence.

When we complete a successful project, we assume that it was due to our accurate and detailed planning of controlled variables. We forget the random variables that impacted us positively. We assume the cause of success was within the plan, and we are the performers.  

When we finish a project and it is unsuccessful, we assume that this was due to the presence of external uncontrollable variables, not foreseen from the beginning which affected us negatively. The cause of failure is out of our hands, and we are not the performers.   

Agile methodologies mitigate these biases

Having raised the existence of these two cognitive biases (the emotional side of our decision-making and the fallacy in our planning), we see two aspects of Agile methodologies that make them in the most effective way to mitigate the biases: valuing people and response to change.

By realizing that our decisions are more emotional than they are rational, we place more value on individuals and their interactions than we do tools and processes. This allows us to communicate more empathetically and understand the emotion behind our choices.

Regarding the fallacy of planning, by putting more value on response to change, rather than following a plan, we can better detect the random variables that may arise and impact the results.

In this way, we can realize the importance and value that Agile methodologies have in reducing the noise and deviations that may occur during the development of a project.

Sources

KAHNEMAN, D. (2011) Thinking, Fast and Slow. Debate Editorial.

About the Author Walter Abrigo is a Managing Director at Santex. In addition to his large academic career, he possess market expertise in several organizational processes such as management control, change and strategy, recruiting and staffing as well as performance and engagement.

You can read the spanish version of this article published in “Pulso Social”.