Monthly Archives: September 2010

Agile from the Trenches – Part 3 – Enabling to a Successful Team

I could have titled this post “Agile from the Trenches – Creating a Successful Team”, but I feel that would be misleading and largely an incorrect statement.  A team is initially created by evaluating and assigning members to the team.  But that is essentially where the “creation” part ends, and the “enabling” part should begin.

It is very important that agile teams are cross-functional.  What does this mean?  The team should consist of members with skills in each of the functional areas needed for the project.  For software development projects, this would mean having each of the main functional skills represented on your team: business analysis, quality assurance/testing and development.  Some teams may need additional representation in different areas (architecture, infrastructure, information security, etc.) depending on the scope and complexity of the project.  The goal is to build a team that is as independent and self-reliant as possible.  This will help reduce the risk that outside influences or dependencies on other teams will cause problems.

While the assignment of team members is a very important step, sometimes it is out of our control as leaders and as team members (e.g. a team may already be formed).  It is important that we remember to focus on the other important components of the team building process and focus on enabling the team and what that means.

Team Charter

Before the team can set off and accomplish great things, it is very important that they understand the organizational goals, vision and values as well as those of the team.  During the team building phase,  the team should draft their own charter that will define the teams goals, vision and roles and ensure that they line up with those of the organization.  This will be a living document, and should be updated accordingly as things change.  Here are the key elements of a team charter as outlined by Chris Edmonds (Driving Results Through Culture) in his Most Teambuilding Isn’t post:

  1. Organizational Vision, Purpose and Values – all teams are “sponsored” by the organization in which they operate. A team must understand the vision, purpose, and values of the company so that it can align team purpose and values with those defined organizational elements.
  2. Team Purpose – the team’s purpose statement identifies what the team does, for whom, and why it is important. A clear purpose provides direction for identifying team goals and the roles needed to accomplish those goals.
  3. Team Values and Norms – Values are the enduring principles that guide team and team member plans, decisions, and actions. Norms are the day-to-day ground rules that clarify appropriate behaviors for team members.
  4. Team Goals and Roles – goals identify the measurable outcomes and timelines that must be delivered upon to ensure team success. Roles define the individual responsibilities required for the successful operation of the team.
  5. Team Practices – this section defines the team’s strategies and processes that ensure the team stays on track to deliver promised outcomes. Practices include communication strategies, decision-making authority, and accountability practices.
  6. Team Resources – these are the tangible materials the team needs to accomplish its goals, including time, budget, people, equipment, training, etc.

Chris also mentions that “teams need clarity of purpose, values, goals, and strategy as a foundation for team performance and team member morale.”  This is very important, as a team that doesn’t clearly understand their purpose will be left to wander and their performance and delivery will be compromised as a result.  Each team member should also have clarity of purpose (i.e. what is their role and purpose within the team).  The team members should come out of the team building phase with a clear understanding of their individual role is within the team, and understand the team charter.

Allow the Team to Own the Work

Ownership of one’s work is important.  If an individual or a team do not feel that they are in control, at least in enough control, of their work – then they are also not in control of the outcome and the consequences.  One of the many cool things I like about agile methodologies, is the focus on ownership.  The team should have true ownership over their work, and their commitments from iteration to iteration.  In fact, it is best if the team owns as much of the work as possible.

I will use the Scrum methodology to highlight some areas where the team has power of ownership:

  • Process – Although a team may start by following a predefined process or methodology, they still own the process.  The iterative nature of the process, and the Scrum Retrospective stage,  allow the team to find areas of improvement and make corrections in the process.  This can also be referred to as continuous improvement.
  • Scope – The business will determine and provide the overall direction and priorities of what needs to get done.  This is done through the constant upkeep of the Product Backlog.  During the planning for each iteration, the team controls how much they feel they can accomplish during that iteration.
  • Work Assignment – Rather than having individual tasks assigned, the team is coached to take on their own assignments and manage their own work.  It is important to note that there are controls in place to help with managing accountability in this type of environment (transparency through the board, burndown charts and the daily scrum meeting).  If somebody is falling behind, they are encouraged and coached to reach out to the team.  The basic concept is even though work is typically done at an individual level, the entire team is still responsible of the final outcome.  This encourages the team to work as a team, and not solely as individual high performers.

Enabling and Empowering the Team

We drive down as much ownership to the team as possible so that they are empowered to be productive, innovative and are able react quickly to changes and the needs of the project.  Ownership without proper enabling and empowerment will lead towards frustration and poor performance of the team.  In this type of scenario the team will quickly learn that, while they are expected to deliver, they are not in control of anything to make their lives or the project any better.

Each organization and culture will have it’s limits and comfort level around empowering teams.  This is to be expected and acknowledged.  Ensure the limits are well understood and set expectations with the team so that they understand what, if any, adjustments might be allowed in the future.

Here are some examples, through past experience, where our team has suggested or made changes to improve the project and their work environment:

  • Limiting dependencies on other teams – While the team had been able to deliver on time, a large amount of time was wasted and delivery risk increased, when they had to work with and wait on another team to finish tasks they were dependent on.  It became clear very quickly that this other team was not under the same mandate and timelines as this project; they had delivery requirements of their own.  Organizing and synchronizing the teams may seem like an option (very difficult and risky in my opinion), but the preferred option was to bring in as many of the outlying tasks into our team as possible (thus removing the external dependency altogether).  The team could now control their own outcome and better estimate for future iterations.
  • Automation – Through many iterations and retrospectives, the team has found many places to automate common tasks and processes.  This has increased team productivity, innovation and reduced risk for the project.
  • Process Improvement – The team is continually making minor process and communication adjustments from iteration to iteration.  Continual changes in how work is tracked, how the team estimates and plans has allowed the team to take control and find efficiencies and constantly improve on what they have done before.

A properly empowered and enabled team will naturally start to suggest and make changes which should increase team productivity and overall success of the project.  Some coaching and guidance will be needed along the way, but this is ultimately a much better place to be for the success of any project.

Please share your success stories of team empowerment and improvement by submitting a comment!

Debunking Testing Myths

Joel Tosi of VersionOne wrote a good article on testing myths.

He raises a good example for the age old excuse that “I don’t have time to write unit tests”.   The example provided was some code that processed a data feed/push with transformation.  In this type of scenario, it can take a substantial amount of time to complete a full test run.  If the job takes an hour or so to run, that time can add up as bugs are found and the code is troubleshooted and retested.  It would be far preferable to invest much of this time up front in creating and running automated unit tests which can simulate troublesome data issues and problems in a matter of seconds or minutes, in a more controlled and granular manner (than processing a full data feed, or even smaller simulated data feeds).

The fact that these unit tests can be fully automated in a Continuous Integration build as either unit tests or more robust integration tests, is even better.  This way, the unit test is generated once, and will be run every time a build is done (probably at least once a day, if not multiple times per day).

If developers are not spending time writing automated unit tests, it very well may cost more time through the course of the project.

%d bloggers like this: