Agile Metrics – Measuring What Actually Matters


Do you really know how your agile teams are doing?

As organizations transform to agile and stand-up multiple teams it becomes almost impossible to see how healthy all those teams are in a consistent way. This is an important question not just for leaders, but for the teams themselves to understand the areas where they need to improve. Here’s a typical view of what happens today to answer this question:

  • Every agile coach or ScrumMaster creates their own survey or evaluation of team health and maturity.
  • We leverage excel sheets to analyze the data which could get complicated and take weeks/months to analyze.
  • There is no consistent way of measuring health across many teams.
  • Agile coaches are stretched too thin with no clear way to prioritize which teams need their help the most and which teams can use self-manage.
  • Leaders and executives don’t have overall understanding of the health of the organization and where they can help. We tell them ‘agile is working! We FEEL we’re making big progress’ and then only share hard metrics to prove it.

When we talk about the health of teams, we shouldn’t just focus on the hard metrics and agile processes alone. This can lead to gaming of the data. The metrics that give us ‘predictive’ indicators actually come from the cultural and people side. This is called ‘mode 2’ of the bimodal movement according to Gartner.  Susan Courtney, CIO of BCBS NE, actually shared that “80% of their enterprise agile transformation was about the cultural side and 20% about the agile and process side”.


So… We started a couple of years ago digging deeper into this topic of team and organizational health measurement. Our objectives were simple:

  • Have a holistic measurement of team health that is consistent across all teams so that we can identify common patterns and address them.
  • Engage a team in a fun strategic deep-dive retrospective that gives them immediate value. We’ve learned this needs to be a facilitated conversation that allows them to analyze the results of their assessment in real-time so they can build an actionable growth plan.
  • We wanted the results to appear in ONE engaging visual. We were tired of analyzing several graphs to make sense of the data. Hence the birth of the TeamHealth Radar.
  • This needed to happen on a cadence. Similar to how teams do Release Planning every quarter or every Program Increment (PI) (if you’re using Scaled Agile Framework® or SAFe®), we wanted them to inspect and adapt quarterly and then work the growth items during each spring retrospective. Why? So growth is continuous and measurable.

What does business agility and organization health look like?

Let’s go 5,000 feet above before we start digging into TeamHealth. As we’ve worked with many companies attempting to transform themselves and looked at the common objectives for their transformation, four key pillars started to emerge:



Clarity: “Do we know who we are and why we exist? Do we have agreement on our core values and how we should behave? Do we know what’s the most important thing right now at the team, program, and portfolio levels?”

Focus: “Are we able to stay focused until we get something done or do we continue to run after shining objects?” “Do we allow our teams to finish what they started before adding new ideas to their backlog?”  Most of the lack of focus actually comes from lack of enterprise adoption of agile planning and prioritization at the portfolio level. That’s for a different future blog!

Predictable Execution: “Do we all know how to execute work in a predictable way, whether is Kanban, Scrum, or Lean. Do we have a process for it where we all know what it means to be a product owner, how often do we plan our iterations, and what does velocity means for us?”

Healthy Culture: In the middle of that triangle are the healthy and happy people who enjoy what they are doing. This comes from their leaders shifting from command and control to servant leadership, and their teams learning strong collaboration, facilitation, and teamwork skills.

What We’ve Learned About Team Health

We’ve spent a few years now learning and improving our understanding of what makes an agile team (or any team) healthy through building AgilityHealth. The heart of this discovery has been the TeamHealth Radar below in addition to the format of the facilitated quarterly retrospective. This radar provides ‘qualitative’ measures that are critical to understanding how the team is doing and where they can improve. I’ll tackle including ‘quantitative’ later in future blog.

Download the TeamHealth flashcards to understand what ‘great’ and ‘not so great’ look like for each of the competencies we’ll explore below.



A healthy team should have clarity on their vision and purpose (why they exist) and their measure for success. They should have clarity on their plan; short term, mid-term, and long term. They should have clarity on their roles; what is expected of me individually and what is expected of others on my team? Another critical skill is becoming generalizing specialists. As a team member, am I open to learning new skills beyond my specialty so I can help my team when needed?


Performance is measured in two ways: confidence (the gut-check) and measurements.

Confidence, starting with the product owner, we ask: “As a product owner are you confident and satisfied that this team has the tools, the skills, and the desire to meet your current goals?” We ask the same question to the team members. We also engage the stakeholders outside of the team (users, sponsor, managers, other teams) by asking them for their confidence in the team AND their satisfaction using the NPS popular question ‘How likely are you to recommend working with our team to others?’

Measurement, we’ve gathered the top five drivers for companies adopting agile (see VersionOne State of Agile Report).  These are: predictable velocity, time to market, value delivered, quality, and response to change.


A strong and healthy leadership team has a direct impact on the health of the overall health of an agile team. To assess their health, we focus on these roles: team facilitator (ScrumMaster), product owner, technical lead, and the functional manager of the team. We’ve found interesting relationships emerge. For example, there is a correlation between clarity (as an outcome), and leadership (as an input). This means, as an example, if you want the team to have clarity on vision, plans, and roles, they should have a healthy team facilitator and product owner.

We also believe it is important to assess the functional manager of the team due to the positive or negative influence their leadership can have on the team. We focus on servant leadership, people development, and process improvement. This is important in order to nudge managers to shift their focus on growing individuals, and improving their team process rather than task management and fire fighting.


Probably the most critical aspect of the health of a team is that layer below the surface.   Part of the power of having this will be a facilitated TeamHealth retrospective each quarter, is it provides the team an opportunity to to dig deeper into this layer and open up conversations they usually don’t have during regular iteration retrospectives.

We measure cultural health by having each person rate the following ‘happiness’ statement on a 10-point scale “I enjoy working with this team”.  We then dig into how well the team collaborates, do they trust and respect each other, are they allowed to be creative (and do they actually do it). Finally, do they hold each other accountable or are they still waiting for a boss to do that?


Healthy agile teams have a strong foundation. This is made up of basic principles of agility such as sustainable pace (not burning out), self-organization (empowering the teams to make decisions), technical excellence (which now has its own Technical Health radar), having the proper planning and estimating cadences, and facilitating effective meetings.

The team structure can also have a big impact on health and performance. We assess if the team has the right size and skills, and are they allocated and stable (reduce multi-tasking and pulling people out of the team). Finally is their workspace environment, virtual or co-located, and setup for collaboration?

 Summary and Final Thoughts

As I’ve worked with many companies through their agile transformation it has become clear to me and to the leaders of these organizations that measurement is no longer a nice-to-have, but a must-have.

As you scale agile and stand-up tens or hundreds of agile teams, the visibility and transparency of how they’re doing is imperative to your future success.  Seeing patterns across multiple teams and building much more targeted growth at the team, program, and portfolio/LOB levels takes your transformation to the next level of maturity. I hope you’ll share our vision and passion for leveraging the right set of metrics to enable business agility.


Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in Agile Metrics | 1 Comment

Consistency is the Key When Scaling Agile


detourWake up, get dressed, go to work, go to lunch, go home, etc., etc., etc.  Each of these decisions is made over and over again in what might be called a routine.  As part of this sequence, work is done whether simple or complex and the outcome is typically valuable.

What happens when this “routine” is changed for some un-anticipated reason causing a detour?  Was there a problem or not?  Was the end result less value created?  Festinger coined the term “Cognitive dissonance to describe inconsistencies in our understanding which can cause stress”.  If this identified inconsistency can cause anxiety leading to failure, could it be that consistency will have the opposite effect and lead to success?

According to  VersionOne’s 10th annual State of Agile Report, 43% of the respondents rated consistency the most important success factor when scaling agile, followed by implementation of a common tool across teams (40%), and agile consultants or trainers (40%) were cited as the top three tips for successfully scaling agile.

Top 5 Tips for Success with Scaling Agile

What is it?

Consistency Defined – agreement or harmony of parts or features to one another or a whole.  We know there are many parts to our lives, some of which are complicated and others can be classified as simple.  An executive in a company might have as part of their daily routine dropping their kids at school and then spending the rest of the day re-structuring companies in which they serve.  This combination of decisions can get convoluted quickly if there is not a certain “agreement or harmony” of the parts that make up the day.

music-250x156In this small case, a traffic problem can cause the corporate world to be delayed in a strategic decision. These are the decisions that need more time, research, and analysis as seen through a bigger lens.  Consistency in the simple decisions allow for more time to be spent on the complex ideas and solutions.

Agile software development values keeping things as simple as possible.  One of the Agile Manifesto’s principles is “Simplicity–the art of maximizing the amount of work not done–is essential”.  Things like people, process, terminology, events, and locations can all contribute to a complex work environment.  As more decision points are added to any project, complexity increases.  Scaling agile contributes directly into this increasing cognitive map and can lead to a less harmonic result.

Why is it important?

When people are added to teams, there is a need for existing members to take time out of the regular schedule for assimilation into the workflow.  This typically involves sharing of information, team culture, and idiosyncrasies associated with this group seen or unseen.  The routine is changed.

With scaling, teams are being added to teams creating many more points of reference, collaboration, and potential confusion.  Consistency is important because confusion creeps in which produces change and can lead to chaos.  The chaos factor will hold back teams from delivering on a regular basis.

peopleRobinson and Rose stated, “Often, in the tension of a chaotic stage, team members simply start doing things to burn off the emotional energy.  The difficulty with this is that the activity is often not well-thought-out and can actually have nothing to do with the actions that they need to take to be successful.”

Similarly, changes in process, can have the same effect.  Like a detour on the way to the office, a small change can signal a disruption in success.  Following well-known and mature processes can facilitate the ability to keep moving forward.  A common cadence will help settle the dust of simple questions like when and where, so the complex issues are allocated more time and effort.

Bell and Raiffa posited, “Many of the central issues of our time are questions of how we use limited information and limited computational capacity to deal with enormous problems whose shape we barely grasp.”

With this limitation already acknowledged, how can we increase consistency?

How do we do it?

Brief analysis of the ceremonies a group does can shed light into what is “consistent” and what might need to change. Start with the people because this affects everything else.  I know of one company that has set a Service Level Agreement (SLA) on contracted teams to support consistency so their Bounce Rate stays small.  People naturally form routines and look for simple answers.  Self-organization can help to surface inconsistencies and supports faster acceptance of change.  Also, look at the process, culture, terminology, and location as indicators for or against consistency.

consistency is keyGetting to agreement or harmony can take agile teams some time; however evidence shows that consistency will enhance success.

Find out more by downloading the 10th annual State of Agile Report and reviewing archives of past reports.

Decision Making: Its Logic and Practice
By Byron M. Roth, John D. Mullen

Teams for a New Generation: A Facilitator’s Field Guide
By Greg Robinson, Mark Rose

Decision Making: Descriptive, Normative, and Prescriptive Interactions
By David E. Bell, Howard Raiffa

State of Agile is a trademark of VersionOne Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment

Bug Bashing for Beef


At VersionOne we like to try new things.  Experiment with new processes.  Inspect and adapt.  Hey, I guess we do agile.

Recently we noticed that our bug backlog was beginning to get some cruft in it, so we brainstormed how we could chip away at the list in a meaningful way.   We take quality seriously around here and our goal is to provide the highest value product with the best quality that we can.

We have a weekly backlog grooming meeting to discuss and prioritize incoming defects from the field.  (Yes, we have defects.  It’s software after all!)  Through the collaborative input of product managers, testers, and support, high priority items are triaged and assigned out to teams to work on them for the next point release.  Medium and low priority defects go into a “Bug Basher” backlog for teams to pull when they have the bandwidth to do so.

We noticed the Bug Bashers backlog growing over time.  We knew that those defects were not high priority, but we felt it was a good idea to do a little inspecting since we know that lots of mediums and lows can add up to a bad experience for our customers.

It was also apparent that our focus on delivering stories was keeping us from going too much farther down the defect priority list.  So…..we decided to add a little horse power and instituted a Bug Bash Day on a Friday to see how things would go.

We wanted to be pragmatic and effective, so the process turned out to be really simple:

Pick a bug and fix it.  That’s it.

Jeff Cook, our director of customer support, instituted the phrase “anything goes when it comes to the close” as a mantra for the day.  That just meant that we were looking for stale defects in addition to things we could fix in a day.  This mantra got the whole team involved in looking for opportunities to clean things up.

Separately, Cory Wheeler, veteran VersionOne software engineer had organized a “bring your steak to work day”.  We love meat around here and what better way to celebrate it, than eat it!  It was a day to cook meat, socialize, and hang out over lunch.

We decided to combine the two ideas and “Bug Bashing for Beef” was born.

Here’s a couple pics from the day:






On Monday, Sean McCrohan, VersionOne team lead, posted the results in Slack.  The exercise proved to very successful.  We had closed 47 bug fixes for the day.

Swarming on bugs for a day helped to focus in and get some small stuff out of the way.  It worked so well that this is a practice we plan to do again.

If you find yourself in a similar situation, a Bug Bash Day may work well for you, too.  Give it a try and let us know how it goes.  Beef is optional, but encouraged!

Posted in Agile Powered By People, Agile Project Management, Agile Software Development | Leave a comment

State of Agile: Still Scrumming After All These Years


Think Scrum’s days are numbered?  Think again.

As excitement around lean software development and Kanban exploded around 2010, there was no shortage of people proclaiming that we had arrived in a post-Scrum world.  Some even went so far as to predict that Scrum would soon go the way of the 8-track.

(This is an 8-track, kids.)

(This is an 8-track, kids.)

But as I look at VersionOne’s State of Agile reports over the past 10 years, it’s clear that there were a lot of false prophets.  Since we published the first State of Agile report back in 2006 with 722 respondents, Scrum has remained on top of the heap as the most-used agile “methodology”.

In 2006 the numbers looked like this:

VersionOne State of Agile Report, 2006

VersionOne State of Agile Report, 2006

When you consider that the “Hybrid/Custom” approaches probably had a significant amount of Scrum baked into them, Scrum users made up somewhere around 50% of the survey respondents.

Fast forward to 2016, and this is what we see:

10th Annual State of Agile Report, 2016

10th Annual State of Agile Report, 2016

Scrum’s impact in the latest survey really shakes out like this:

  • Scrum – 58%
  • Scrum + Scrum/XP Hybrid – 68%
  • Scrum + Scrum/XP Hybrid + Scrumban – 75%

Making some assumptions about the “Custom Hybrids”, Scrum probably comes in somewhere north of 80%.

Flipping ahead a few pages in the survey results, we see that the leading scaling approach is “Scrum/Scrum of Scrums”, with SAFe® coming in a distant second.  One thing these approaches have in common is that Scrum is the team-level engine.  (Yes, SAFe does include Kanban at the team level now, but it is couched within an iterative framework.)

So why is Scrum still so pervasive?

In my opinion, Scrum’s appeal has always been its simplicity: few roles, few rules, and a focus on getting to Done.  That minimalism remains as refreshing two years into an agile transformation as it is on day one.

I believe that most people understand now that, even within a single organization, Scrum’s a better fit in some situations, Kanban is better in others, and some hybrid approach is better in others.  There was never any basis for the methodology wars or the predictions of the ascent of one and the demise of others.

You’ll be hard-pressed to find a pure Scrum shop these days.  By “pure” I mean where they’re working to the Scrum framework, while banning the use of any XP engineering practices and forbidding the use of things like WIP limits.

The State of Agile Report asks what methodology is followed “most closely”.  I’d bet that if we took away the option to select Scrum by itself, the percentage of Scrum-infused methodologies would still total up to about the same as they do now.

As with everything else, the market will decide if there’s ever a clear methodology winner.  One thing that’s certain, though, is that the reports of Scrum’s impending death have been greatly exaggerated.

Find out more by downloading the 10th annual State of Agile Report and reviewing archives of past reports.

State of Agile is a trademark of VersionOne Inc.

Posted in agile 2016, agile survey, agile trends, Scrum Methodology | Leave a comment

So…when does the healing begin?

so-when-does-the-healing-begin-800x328Many people have commented on the statement that Kent Beck made in Snowbird around agile-manifestohis purpose for the meeting.  I wasn’t there of course, so I am most likely paraphrasing, but the generally accepted representation was that he wanted to “heal the rift between development and the business”.  As I was attending the first of the conference season
events, Mile High Agile, I started to wonder how well that has worked.  I’m not thrilled with what my conclusions currently are.  I’m hoping someone can show me where I’m wrong.

First, some history.  This might seem a little self-indulgent, but I promise that I do have a point, if only to set some context.  I discovered eXtreme Programming back around 1999. I read the book and rejected it, until I met people who were doing it.  It was truly revelatory. People were happy.  The business oriented folks were working together collaboratively with the rest of the team.  Not at a daily meeting, but throughout the day.   I started digging deeper and realized that someone had finally found a way to make software that managed the balancing act between good engineering and good project management. With that in mind, I went to the first XP Universe.  I left even more energized and ready to take on the world.

The next few years were fun and challenging.  Most of my time was spent practicing and Missing-Pieceevangelizing XP, and then agile came along.  I continued to be part of development, and attended many, many conferences and discussion groups.  And that is where it gets weird.  At the early conferences, the mix between developer and manager/project manager was a little lopsided toward the programmers.

Then there was a shift and all of a sudden it was hard to find someone at the conference who wasn’t a Scrum Master, the head of a PMO, a senior portfolio project manager, CSM, CSPO, SA, or EIEIO.  Several keynote speakers who I really admire started asking, “where are the programmers?”  This has led me to wonder, what now?  The rift was starting to heal, but it seems to be growing wider again.  Far too much attention is being spent on “what processes and tools do we need” and not enough on “how can we deliver working software?”  What can we do to reverse this trend?

So, now that I’ve indulged in reminiscences, it’s time to do something about it.  I’m not a big fan of just sitting around arguing over a course of action without actually doing something about it.  So let’s get the software development back into agile software development.

We can begin by refusing to accept a separation of “management practices” and “technical practices”.  There are just agile practices. The next time we’re going to spend training money on agile stuff, let’s skip the story writing and framework training, and let’s spend it on test driven development (TDD) or refactoring.  Better yet, let’s spend that time and energy on DevOps.  And don’t just send “Dev” to these classes. Wouldn’t it be cool if the technical folks had the same understanding of what agile means?  And the next time you’re inclined to ask for or write another report about “progress”, ask yourself “can I express this in terms of working software?”

So this is  my call to action: The time for the  healing to start again is now.  What will you do to make it happen?

Posted in agile, agile 2016, Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Executive, Agile Leadership, Agile Management, Agile Methodologies, Agile programming, Agile Software, Agile Software Development, Agile Software Quality, Agile Teams, Agile Testing, Agile Training, agile trends, Continuous Delivery, continuous improvement, Continuous Integration, DevOps, Extreme Programming, Scrum Development, Scrum Methodology, Scrum Software, Software Craftsmanship, Test Driven Development, Uncategorized | Leave a comment

How We Celebrated Our CTO’s Birthday and How You Can, Too


This week at VersionOne we had the opportunity to celebrate our CTO Ian Culling for having a birthday.  He won’t tell us how old he is, so I guess that means he’s over 20?  If you get the chance to meet him you might think he’s in his 20’s!

The man is a big part of the culture here at VersionOne.  He makes things fun in addition to being smart as hell and doing a bang up job as the CTO.  Walk into the development area and you are sure to find traces of Ian’s shenanigans, Dumb & Dumber orange suit, a plethora of nerf guns, Oculus rift, OneWheel, and more recently a Razor drift cart.

He’s also known for showing up at events in “special” attire.  It’s a thing we that we’ve come to expect from him, but there’s always an element of surprise to it.  So in honor of his birthday, we thought we would egg him on for an upcoming golf event that we have going on.

Below is the email that went out from Holly Reynolds, an interaction designer on the product development team.


In case you didn’t know…. it’s Ian’s birthday today…

We all know how much Ian loves to dress up and as much as he probably would like to come to work in his actual birthday suit, clothing is not optional here at VersionOne.

Stars pass and we honor them by celebrating their life after they are gone, but that seems like such a waste.  Ian’s not dead, but he is getting older.  Each of these remind me of him in a special way.  I’m pretty sure if you pick your favorite, we just might get to see this guy show up at the upcoming golf outing on May 16th  (don’t forget to sign up…you’re welcome Michelle).

Reply to me with your vote by 5 pm today or add your own suggestion for the birthday guy if you please.

The results will be compiled and shared later.

Ian Stardust
Creator, eccentric, minus the weird hair.







The Artist Formerly Known as Ian
Calm, cool and….collected;
Purple pants are not above this man






Rowdy Roddy Culling
“I came here to chew bubble gum and kick ass.
And I’m all out of bubble gum.”









Comment on this post and vote for your favorite or make a suggestion of your own.  We’ll share the results in a couple weeks!

Posted in Agile Powered By People | Leave a comment

State of Agile: Are Distributed Teams Here to Stay?

are-distributed-teams-here-to-stay-800x328The 10th annual State of Agile Report is out.  I love reading the results of these surveys, as I learn so much about what other businesses are thinking and doing in the agile software development arena. Each year the results show the growth of acceptance and adoption of agile around the world. Gone are the days when recruiters would tell me to “get that agile stuff (or some word like that) off of your resume, or I can’t even get you an interview”. That is the good news!

But the survey also brings to light some uncomfortable facts about how agile is being attempted or practiced in the real world. This is just as important as all of the happy news. Identifying what is not going well is more important than just feeling good about the fact that all of this “agile stuff” is starting to take hold. Just as inspecting and adapting is built into our psyche as agilists, we need to apply it to our own movement.

One item that really stood out for me was the fact that more than 80% of responding organizations are distributed at some level. This is an incredibly high number, and more than twice the level it was last year. All of the research and experiential learning shows that one of the best things you can do for productivity and communications is to co-locate your teams. So is this a problem? I think it is. Teams need to be able to talk to each other, and should be able to do it without having to schedule a conference call, not to mention dealing with time zone issues.

Distributed Agile Teams

One of the 12 principles of Agile Software Development is “The most efficient and effective method of conveying information to and within a development team is face to face conversation”.  So distributed teams mean that we can at best be 11 and 1 in our agile world.  And the odds are not in our favor that this is the only thing we are “setting aside”.

So is this all bad? I don’t think so. But it is something we need to address and work on. First, let’s ask ourselves if we absolutely must have these teams distributed.  Just because they always were distributed, doesn’t mean they still need to be. If we absolutely must have distributed teams, we need to find the best way to facilitate conversation. What are some options we can consider to help that happen?

Form Teams Around Location

If you can, make the team at each location a fully functioning team. Rather than having QA in Denver and Development in Dublin, have a team in Denver that handles some features, and a team in Dublin that handles others. Or, if you can, just have each team pull from a common backlog. Emphasize the need to eliminate any perceived dependencies rather than just identifying them with yarn.

Anything But Email

Email continues to maintain its status as the world’s worst form of communication we’ve ever invented. There are many good online chat tools, as well as using Conversations in VersionOne that can help remove the formality that gets in the way of real conversation.


One of the most important, and least recognized, challenges to a distributed team is the “senior partner/junior partner” attitude that pervades most distributed arrangements. No team should be called “the offshore team” or “the remote team”.  Make sure to alter times for meetings so that the same team isn’t inconvenienced every time. It is better for each team to share the inconvenience of time zone disparities.

So yes, while I would love for all teams to be able to engage in face-to-face conversation, the world is clearly moving to multiple distributed environments. We could rail against this, or we can learn to work with this reality and find ways to make it as effective as possible.

Find out more by downloading the 10th annual State of Agile Report.

State of Agile is a trademark of VersionOne Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment

State of Agile: Culture Matters

culture-matters-800x328So you want to adopt agile within your organization or perhaps your transformation is already underway. You are not alone as the number of organizations of all sizes adopting agile continues to grow. The increasing popularity of agile persists because organizations are realizing benefits including the top three cited benefits from the 10th annual State of Agile Report:

  • Ability to manage changing priorities
  • Increased team productivity
  • Improved project visibility

But there are barriers to adoption and success with agile. Be forewarned, depending on the current culture of your organization, the path to agility could be long and challenging.

In the 10th annual State of Agile Report, the top barriers to agile adoption center on matters of culture including 1) the ability to change organizational culture, and 2) general organizational resistance to change. And the most often cited causes of agile project failure include 1) the company culture at odds with agile core values followed by, and 2) lack of experience. Culture can profoundly impact agile transformation and can also cause existing agile projects to struggle.

Barriers to Further Agile Adoption

Culture is defined as a way of thinking, behaving, or working that exists in an organization.

So does the culture drive the behaviors, or do behaviors drive the culture? I say yes to both in this chicken and egg debate. We own our behavior and can change as individuals. While we each have a personal value and belief system that governs our thinking and behavior, we also are driven by the need for self-preservation, a survival instinct. Placed within an organization value system, people most readily adapt their behaviors to align with the perceived organization values, expectations, and observed behaviors. To change the thinking and behavior of a group requires a recognized shift in the core values and expectations.

So why is culture so challenging? First the new set of values and expectations must be clearly communicated and understood by the group. Then the group must trust that it is safe to actually shift their thinking and behavior. Without a strong foundation of trust, this may take a long time. Any inconsistent application of new values and expectations from authority figures will signal that it is not yet safe to behave differently further delaying change. Some will be confused about how to adapt or to fit into the new expectations and will need guidance. Some may not accept the new values. While others may hesitate to move outside their familiar comfort zone or fear losing position or influence. Human psychology is complex and the factors are situational making it difficult to prescribe a canned solution.

But, there are some common ingredients in successful agile transformations. Start by instilling the agile valves. Communicate, explain, and model them. Leadership needs to believe in these values as others will quickly see through empty words. Learn from others. Provide coaching and mentoring, whether from internal or external sources, to help people understand their new role and how to be successful.  People fear and thus resist what they do not understand or feel they will not be good at. It is easier to just do what you already know.

Too often organizations focus agile adoption efforts on instilling the mechanics of a process framework while failing to understand the underlying values and principles of agile. To successfully establish an agile culture, you must set the values, expectations, and beliefs to fundamentally change the underlying thinking and behaviors around the agile set of core values. Agile involves a different way of thinking about the work and the people.

The agile core values are expressed by the Agile Manifesto.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Agile values are rooted deeply in a sense of mutual trust and respect for one another, a belief that people matter and that empowered teams are the keys to excellence. Effective collaboration is essential, and continuous improvement around the delivery of value is the goal. Frequent feedback loops provide opportunity to inspect and adapt and to adjust priorities.

An agile culture requires a foundation of trust and transparency. It challenges the status quo, listens respectively to dissecting opinions, and views failure as an opportunity to learn. It empowers teams and promotes team performance investing in team building and growth of team members. It embraces a spirit of service and excellence. Servant leadership replaces controlling and directing.

Some organizations announce “Yes, we are doing agile” now. Then they quickly become disillusioned when they are not experiencing the expected benefits cited by agile organizations.

When you look a bit deeper, the reality is that they continued to think and behave as before. What they valued and believed did not change. They just adopted some new terminology and some process activity. They were going through the motions, but with no fundamental change in thinking. Sadly they failed to understand the philosophy behind agile values and principles. The culture did not change.

While agile transformation may not always be easy, it does provide benefits for those willing to stay the course. Find out more by downloading the 10th annual State of Agile Report.

State of Agile is a trademark of VersionOne Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment

Improved Project Visibility: A Top 3 Benefit of Agile

improved-project-visibility-a-top-3-benefit-of-agile-800x328-2Visibility, the ability to see what is in front of you, is critically important for companies in order to remain profitable and relevant in their industry. Imagine how difficult it would be for you to drive a car without being able to see the road.  Adding in weather impediment elements can hamper your ability to reach your destination on-time even further. Even the sunniest days can blind your vision causing you to be distracted from where you are going.

Just like with driving a car, it’s a leader’s ability to chart the course with a clear vision for what the customer needs, along with what the teams can deliver, that is key to business success. So it comes as no surprise that 87% of the 10th annual State of Agile survey respondents said that the “ability to manage changing priorities” remains as the top improvement result of implementing agile practices. The ability to change helps foster the #2 item on that list, “increased team productivity” at 85%, and both of those are a result of “improved project visibility” at 84%.* In fact, managing change, increased productivity, and improved project visibility have been at the top of this list for the past five years.

Benefits of Agile

While change and productivity are so very important, visibility is the key that paves the road to agile success. Without visibility, how hard would it be to change course quickly? Without visibility how do you track and measure productivity improvements? And just like in driving, visibility is a two-way street. Teams need to know where they are going as much as the leaders of your organization need to know what the current map looks like, how fast the cars are driving, and how close we are to various destinations.

Whether you are a senior leader, or a member of an agile team, here a few key areas to help your company reap the benefits through better visibility practices:

Team Visibility

  • Know the important team indicators that drive the company’s success (e.g., velocity, throughput, productivity)
  • Align your work items correctly to help influence the success factors and be open to discussing this in your daily and weekly planning sessions
  • Be transparent with leadership and encourage them to be more involved in reviews
  • Share impediments and bad news as quickly and efficiently as possible
  • Practice extreme visibility with all your indicators, make them visible and known far and wide

Leadership Visibility

  • Become a trust agent for your teams and remember to always be building trust
  • Share company news and the key indicators that drive the company, have the teams help create these key numbers in partnership (e.g. share ownership on scorecards and dashboards)
  • Know how the teams operate and understand the value of their processes and ceremonies (act and think more like a team member)
  • Celebrate every win and encourage good behavior (vs discouraging bad behavior)
  • Ruthlessly remove impediments for the team to help them be successful

Improving the visibility in your organization can produce amazing results. Agile companies strive to provide customer value early and often. The State of Agile Report once again highlights how agile companies are seeing productivity improvements that boost company profits and increase the number happy customers.

Do you have the visibility your organization needs to succeed?

State of Agile is a trademark of VersionOne Inc.


Posted in agile 2016, agile survey, agile trends | Leave a comment

The Results Are In! Read the 10th Annual State of Agile Report

SOA-1024x512 (2)

VersionOne is excited to release the 10th annual State of Agile Report – one of the key ways that the company proactively gives back to the software development community.  For more than 10 years, this annual survey has collected unbiased feedback to give software professionals insight into agile trends, best practices, and lessons learned to help them succeed with their agile transformations. In fact this year there were a total of 3,880 completed responses, of which only 28% were VersionOne customers, further adding to the range and diversity of respondents. While many of the trends remained constant, we were surprised by some of the results.

Here’s a sneak peek:

  • Larger enterprises are embracing agile – 24% of respondents work for organizations with 20,000+ employees.
  • Agile is scaling – Scrum still dominates, but the Scaled Agile Framework® (SAFe®) made a big jump this year.
  • Agile talent and experience is growing – 63% said they were ‘very’ to ‘extremely’ knowledgeable about agile.
  • Agile is going global – 26% of the respondents work in Europe, and more than 18% work in Asia, South America, Oceania, and Africa.
  • You’re succeeding with agile – 95% reported that their organizations practice agile, and only 1% had experienced agile failure.

Read the report and get access to the archives of the previous nine State of Agile reports.

VersionOne is a registered trademark and State of Agile is a trademark of VersionOne Inc.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment