Welcome to Agile by the Numbers

Filed under [ Agile by the Numbers ]

Welcome to Agile by the Numbers!

This series of articles delves into the sticky topic of Agile metrics. Let me state right off the bat that this is NOT focused on measuring the performance of an Agile team for purposes of benchmarking or report-card scoring, although you will get some nice data for this purpose if you follow along.

The main purpose of Agile by the Numbers is to put a small number of key sensors in place, to create information for the Agile team to see where they are headed and where they can focus to improve their success.

I prefer the term “sensor” to “metric” because I believe that the purpose of any measurement is to improve a team’s ability to sense and respond to issues affecting their success. Metrics, on the other hand, tend to be more management-focused and frequently do not deliver this type of value at the team level.

Each of the sensors I will be discussing in this series tie back to one of two things: enabling a team to produce finished software faster (measured by Team Velocity) and increasing the business impact, or value, of the software delivered (Business Value).

If a measurement does not impact either of these, then I would have a hard time explaining why it is meaningful to the team. Let me say that again: if you are collecting data that does not show your team how to increase their velocity or value production, then you should ask yourself who it is for, and whether it helps you create an observable, meaningful result.

Each article in this series will focus on one aspect of Agile team success: what to measure, why to measure it, and how to ensure the team is drawing the right conclusions from what you see.

We’ll start with a brief definition of success:

The success of an Agile team is primarily determined by:

  • The team’s ability to plan and complete a set of stories within a sprint, have the work accepted by the business owner, technical reviewer(s) and have zero defects carried over in to the next sprint.
  • Agile teams that focus on this definition can accelerate their ability to deliver business-valued software by 100% or more of their initial velocity, while working at a steady, sustainable pace.
  • In my professional work I have witnessed dozens of teams achieve and maintain this goal and while it can take some teams months to get there, once it happens these high-performance agile teams make the whole thing look easy.

    High performance agile teams avoid lengthy meetings, spend their lunch hours playing ping pong or shooting basketballs at a wall, and are able to spend their evenings and weekends with their families, and their days working at sustainable pace that continues to accelerate sprint after sprint.

    Using the techniques described in this article series, your team can too!

    Agile velocity

    Filed under [ Agile by the Numbers ]

    Velocity is the primary measure of the performance of an Agile team.

    The Agile manifesto values “Finished Software” as the primary deliverable of a team, and team velocity is an agile metric that measures that directly.

    Measuring Team Velocity:

  • The previous article defines Agile success as:
  • The team’s ability to plan and complete a set of stories within a sprint, have the work accepted by the business owner, technical reviewer(s) and have zero defects carried over in to the next sprint.
  • Velocity measures a team’s capacity to do this, by counting Story Points of the stories that are accepted during each sprint. Over time, as a team gets more productive, the team is able to design, code, test and accept more Story Points in a sprint and the Team Velocity rises.

    Sound easy to measure? Surprisingly, no! It turns out there are a number of pitfalls waiting to trap the unwary team, giving rise to false or distorted velocity. This shows up as early success, but the team will hit a wall at full speed later in the release! The aftermath of this collision with reality can be pretty ugly, with missed release dates, a stressed-out team and lasting quality problems.

    The next 3 posts in this series will address the most common mistakes an agile team can make with agile velocity, and offer suggestions on how to avoid the ugly consequences.

    Why is my team slowing down?

    Filed under [ Agile by the Numbers ]

    slowingdownWhy is my team slowing down? What’s happening?

    The worst thing any project team can do is to raise expectations through early success, but be unable to sustain the pace. This happens to many Agile teams due to some simple mistakes made in tracking Team Velocity. As a result of these painful misses, some organizations are getting a bad taste for Agile, and are once again looking to the next big idea to get the performance they want.

    Let’s look at the formula for velocity: Velocity = Story Points Accepted/1 sprint

    Pitfall #1: Story Points Accepted.

    The way a team determines whether a User Story is accepted is important. If a team does not have a strong Definition of Done it is likely to inadvertently count stories as Accepted (and therefore part of velocity) when in fact they may still need work such as complying with code standards, including logging & exception handling, fixing defects or even handling minor requirements that fell off the table during the sprint.

    Over time, this debt builds up and dealing with it will cause an unexplained loss of velocity.

    The Definition of Done is owned by the team, and varies between teams. An example of a strong Definition of Done is:

  • Code is written & unit tested
  • Code has passed technical walk-through/review
  • Product Owner has received an informal demo
  • Test plan has been fully executed and all defects have been fixed
  • Technical documentation (if any) has been written
  • Code has been integrated with continuous build scripts, along with all DML, DDL, web service registration and other environment configuration elements.
  • If a team does not maintain and adhere to a strong Definition of Done then Team Velocity really doesn’t measure work that is truly finished, and is not useful as a gauge of success.

    Welcome to Agile People Patterns

    Filed under [ Agile People Patterns ]

    In this series of posts, I will discuss common (and not so-common) problems faced by teams and their leadership trying to adopt Agile practices.

    Adopting Agile is a lot harder than practicing Agile! If you have had the privilege of observing a mature Scrum team, you can see how effortlessly individuals come together so that the team rapidly delivers value. Work flows smoothly, with components being developed, dependencies resolved, designs agreed on and frequent deployments occurring with a only brief ad-hoc conversations needed to coordinate between team members.

    The history of Agile adoption has followed a frustrating cycle. Leading-edge companies enthusiastically embrace the latest methodology and create early success stores. These in turn prompt more mainstream companies to jump on board, with various levels of success. As the interest in Agile broadens in scope, Agile projects multiply. Inevitably, these projects begin to encounter issues with culture, governance, organizational structure, and management values. Compromises are made, and the results suffer. The industry begins to gradually back off its initial enthusiasm, and people start looking for the next, greatest Agile method; one which promises to deliver the same or better results without the same problems.

    And so it repeats … with Evo, Spiral Development, Crystal, XP, Agile UP, and now Scrum and Kanban. These are all fine methodologies, and each offers useful innovations that improve on predecessors. Ultimately it is the same set of adoption barriers that causes these initiatives to lose steam, not the merits of each methodology or the skills of the practitioners.

    Why is it so much harder to adopt than practice Agile?

    We’ll explore the answer in this series, but the short version is that there are many organizational, cultural and behavioral barriers present in every company; patterns that have been established and reinforced for many years.

    Agile performance comes primarily from a shift in behaviors at the individual, team and leadership levels. These in turn require a shift toward new values, some of which run counter to the values ingrained in most teams by decades of traditional management. This creates resistance, and unless you deal with the underlying values, you will get at best a superficial shift in behaviors.

    Organizational structure also poses barriers to adopting Agile. Structures that have been optimized to support traditional management methods can really throw a wrench into an Agile team’s efforts to deliver quickly and frequently or bring disparate roles together into efficient co-located teams.

    These barriers tend to show up in common patterns, reflecting the similar management philosophies and organizational structures that have existed for many years across industries.

    This series of posts will focus on these Agile adoption patterns, and discuss solutions and techniques for navigating the barriers they pose. My aim is to enable Agile practitioners to recognize these more quickly, and respond more effectively to smooth the Agile adoption process.

    Agile performance: it’s about more than skills!

    Filed under [ Agile People Patterns ]

    What makes a successful Agile team member?

    I’ve been asked this question numerous times by people assembling a Scrum or XP team, so I thought I would blog about it. Simply put, attitude is everything.

    Sure, you need to be competent at the right technical skills, but I will take 1 person with the right attitude and acceptable skills over 3 technical experts who do not exhibit the right attitudinal traits, every time. And I’ll get more value out of the average guy with the right attitude than I would out of the experts. In fact, I’d put money down that by the end of my project the so-called average guy will be performing at an expert level.

    Agile methods value “People over process” and rely on people to come together as a team, self-organize, and be focused on the group result rather than their own individual skills to determine their success.

    But what does this mean? And how do I find people with the right attitude?

    To get a more specific answer, I’ve broken down the 4 major traits I have seen lead to high performance on agile teams:
    Sense of Urgency

  • We want a sense of urgency about getting meaningful work done. This is different from the deadline-driven high-stress mindset that we see all over the place; this arises from a genuine passion for building good software that solves business problems. Such a person will be impatient with spending a day planning out work; he will want to dive in, do enough analysis & design to make sure the concept is thought through, then focus on getting tests to pass while writing flexible, quality code. She will always be looking for ways to work more efficiently, and very likely introduce new tools and practices to the team.
  • Commitment to team results

  • One of the great things about Agile methods is that they shift attention from an individual’s work to the results of the team. Just like a good basketball team is focused on the team’s score and frowns on the glory-hound individual who hogs the ball or plays out of position, a Scrum team member is focused on makings sure he provides what the team needs to succeed, when the team needs it.Of course there is recognition and respect to be gained, but it comes from team members not management, and is earned based on contributions, not gained through achieving artificial objectives.
    This is true because the Agile feedback mechanisms such as velocity focus on the team’s ability to produce working software, rather than an individual’s ability to perform tasks. Both the team and the individual soon learn to value contributions that enhance the team’s success.
  • Transparency

  • A key stumbling block for Agile teams is the unwillingness of members to expose what they do not know, are struggling with, or do not like about the process or work. Instead of seeking help, individuals will tend to ignore problems, paper over roadblocks and try to work through issues by themselves before someone else notices.This reluctance to be vulnerable is understandable, and it stems from a lack of trust in either management or other team members. As leaders, we need to encourage people to ask for help, surface roadblocks, and give public recognition for those brave enough to do so. At the same time, we need to call attention to the time wasted and impact on the team when individuals sit on or ignore problems. The visibility Scrum brings to results makes it easy to spot situations where this is occurring and provides clear examples that can be used to shift the behavior of the team.
  • Willingness to take risks

  • Most people in our society have learned to fear making mistakes. Everywhere from our schools to our homes to our workplaces, we have experienced that mistakes have negative consequences and that playing it safe is the best strategy to achieve stable success in the eyes of others.In an Agile team, this mentality quickly slows the team down. In order to avoid mistakes, people find themselves over-analyzing and over-planning their work. Work expands to fill the time allotted, and technical decisions that could quickly be tested are delayed.To overcome this, we need to invest substantial effort in ensuring that the team environment is one in which it is safe to make mistakes and learn from them. As leaders, we must reward people for acting on limited information, taking their best shot, and then correcting based on what occurs. This does not mean we need to encourage sloppiness or lack of discipline; on the contrary we need to empower our team members to act on their own initiative then share their learnings with the team. This empowerment is critical to forming a team that harnesses the talents and energies of all members. Such a team will quickly establish a culture of initiative, creativity and high performance.
  • It’s about the Team, not the individual

  • Taken together, the above traits combine to enable individuals to come together as high-performance teams producing a large volume of defect-free code without incident. This is the culture and behavior of a successful scrum team, and I have seen team after team achieve this after several months of adjustment to the concept that it is team results, not individual performance that creates success.The trouble is, traditional management practices tend to breed the opposite behaviors. We are an individualistic culture and while we give lip service to the concept of a team, most software development management practices focus on the individual’s performance and contribution to the project. After a few years of professional experience, the average software developer learns to focus on his small piece of a project; set expectations that he can easily achieve, and make sure that management sees the intrinsic value he brings to a project.If she doesn’t succeed at this, she will not be rewarded. If she over-extends herself with optimistic commitments for the good of the project and then fails to deliver, she will earn a bad reputation. Success has been measured by her ability to make make and keep commitments, not her ability to achieve brilliant results. If there isn’t enough time or resource to achieve a specific result, then it is the fault of the manager for not planning properly. A good worker will make a strong effort to deliver anyway, but will make it clear that this is a stretch goal. Some people will seize these moments as an opportunity to save the day, and spotlight their dedication and abilities.The prevailing culture therefore tends to breed a combination of mediocrity in individuals punctuated by individual heroics. The heroics become necessary because of the problems that arise out of the mediocrity; a true high-performance team will not create nearly as many crises to solve.
  • A recipe for success

  • Creating a high performance Agile team involves much more than assembling the right technical skills. As we have seen in this article, we need to assess the soft skills and attitudes of the team members and also ensure our plans allow enough time to make any necessary adjustment in the team’s culture. Establishing the right culture requires experienced leadership, and it usually takes between 1 and 3 months for most teams to begin to demonstrate the level of performance we associate with Scrum teams.
  • <Here's a recipe to help you get started faster:

    1. Build your team around a nucleus of bright individuals with 3-5 years of experience. Make sure they have the right attitude and soft attributes listed above, decent technical skills and that between them they cover the necessary technologies. Don’t expect everyone to be good at everything right off the bat; expect that the team is going to learn from each other.

    2. Carefully add in one or two senior people covering critical technologies. It is very important that these people fit the culture of the team, and don’t come in with baggage such as insistence on specific practices or development process (unless that process is Agile). If you can’t find these people but still need the expertise then consider making them adjuncts to the team; consulting resources to review and support the team but not full team members.

    3. If you can swing it, add one or two proven Agile superstars who embody all the attributes listed above. These individuals do not a record consisting solely of heroics or fire-fighting, but are the type of people who naturally take full responsibility for both preventing and solving problems. These natural leaders will act as catalyst to the above team, leading to a more rapid formation of the culture of team performance. Including these individuals is a good investment, as you will find that their presence will breed future leaders who can in turn catalyze other teams.

    « Newer PostsOlder Posts »