Tag Archives: agile development

Failure or Success

Effective Agile Teams Begin with the End

Failure or Success“If you don’t know where you are going, any road will get you there,” said Lewis Carroll. Not only does this statement apply to individuals, but also to teams. In either case, you might not like the destination when you get there.

Stephen Covey’s second habit is “Begin with the End in Mind”. Before you can effectively create the physical manifestation of the product you want to create or the team you want to be, you have to first create a mental representation of that end state.

One exercise he proposes for helping to clarify what is supremely important to you is to visualize your own funeral. When you visualize your family, friends, or coworkers speaking about you after you have passed, what would you want people to say? As helpful as this visualization exercise can be for individuals to recognize what is important in their lives, it is also important for teams to determine what is important to them.

If an article were written about your team and preserved for the future, what would you want people to know about your team, about how you treated each other, and the way you went about your work? To help determine what is important to your team, consider your team’s ultimate goal. What do you want people to say about you, your team, and your work. Consider your teammates, your Product Owner, your stakeholders, and your customers. What about your functional manager? Consider involving your stakeholder community in the discussion.

Going through such an exercise can result in identifying a common view of what the team wants to become and how they want to operate. Without agreement on what the team values, the urgent demands of the project can keep you from becoming the team you need to become. Symptoms of teams without a compass may be that your team becomes myopic, focused on creating features to the detriment of sustainable pace or maintainable code. Alternatively, your team could become paralyzed by analysis and architecture debates, not recognizing when the analysis is sufficient to allow it to move forward.

To create your team vision is to “begin with the end in mind.” It is more than an elevator statement that captures the 30-second pitch for your product, and it is also more than a list of user stories that you intend to complete within a particular timeframe. What you want to distill from this exercise is a set of principles that can inform the decisions that you and your team will have to make through the course of your work. Take the information you collect and use it to create a mission statement for your team. When creating your mission statement, ensure the involvement of all team members; perhaps have a facilitated discussion led by somebody from outside the team can help ensure that all voices are heard. As Mr. Covey puts it: “No involvement, no commitment.”

Make your mission statement visible in your team room, on its wiki, give printouts to each team member, and anywhere else you feel is appropriate. If somebody is violating the mission statement, inquire about the deviation and determine if the mission statement has become outdated or if the behavior is perhaps not correct. Include a review of the mission statement as part of your retrospective.

Remember, if you are on an team and don’t know where you are going, you won’t get anywhere you want to be. Keeping the end in mind and using the mission statement as a team compass can help the team stay on track toward its desired goal.

Effective Agile Teams Are Proactive

Proactively addressing risks is one of the major strengths of Agile methods. Not only do Agile teams have “spikes” to try to eliminate technical risks, but effective Agile teams have a mindset of eliminating a wide array of risks.  Here are some examples of ways risk is proactively addressed in Agile environments:

If a technology approach is of concern, we do a design spike and find out quickly if the approach isn’t feasible.

In Scrum, the retrospective is an explicit opportunity to look for ways to continue to improve, not resting with “we’re good enough”.

The “test first” approach is a proactive approach to quality.*

If the budget gets cut, we have working software created, not merely the requirements document, design document, and a pile of untested code.

The description of “Be Proactive” in the 7 Habits is “Proactive people take responsibility for their own lives. They determine the agendas they will follow and choose how to respond to what happens to them.” I don’t think I’ve seen an Agile book put it more succinctly. This excerpt could easily be rewritten for Agile teams: “Proactive [agile teams] take responsibility for their own [work]. They determine the agendas they will follow and choose how to respond to what happens to them.”

The Agile Manifesto’s 12 Principles has three in particular that stand out to me as having proactive risk mitigation components to them. These three are:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So, what do you do if you are on a team that has not embraced their responsibility to be proactive? Here are a couple of suggestions:

Consider whether or not your team has the trust necessary to be comfortable identifying risks. I suggest reading the book “Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators (J-B Lencioni Series)“. This book is a follow-up to the book “The Five Dysfunctions of a Team”. The “Overcoming….” book offers specific activities  and suggestions that help address the dysfunctions identified in the earlier book.

Is the team able to communicate in a high bandwidth mode? If risks are getting lost in low-bandwidth communication, consider moving to a collocated room. Eric Landes authored a DevX article entitled “Team Rooms Breed Highly Productive Agile Software Development Teams“.  FYI: You will have to register to read the article.

Model proactive behavior. One of the best ways to show that something is important is to do it yourself.

 Encourage your teams to be more proactive about their work, and I believe you will find that good things follow.

*See the “Being Proactive – Getting to the Triangle of Happiness” blog about testing as it relates to happiness on a blog by Daniel Wintschel and humandoing software.