Are You Agile Enough for DevOps?

Are you agile enough for DevOps?

One of the biggest buzzwords in the industry lately is DevOps.  We all know by now what DevOps is intended to offer, and most organizations are looking for at least some subset of the promise of a continuous delivery flow and the power of “pulling ops into the room”.  But can we really do that if our own job of becoming “more agile” is still incomplete?

Let’s explore for a moment what we even mean by agile.  I recall back in the early days that agile discussions were about how to turn around features quickly by breaking them down into smaller “bite sized” chunks, delivering those, and then determining where to go next based on that feedback.  We invented cool things like user stories, and utilized mechanisms like short iterations and daily standups to move closer to this fast-paced, turn-on-a-dime philosophy toward software development.  We discovered, without a doubt, that this was a better way.  One major portion of these methods was a set of technical practices that would enable the teams to write software in a way that would support such a nimble environment.

So, where are we now?  We have discovered that doing things in these small chunks is hard.  It is counter intuitive too.  We want to look at things in big picture terms.  The question I used to hear the most was “how can I manage a portfolio this way?”  Now that question has been turned into “how can we scale this?”  My answer to each question is the same:  Don’t.    The reason we moved to the smaller chunks and stories is because the “big picture” approach doesn’t work.  So finding ways to shoehorn agile methods into  “scaled” or “Big Up Front Agile” is a waste of time and energy.  Rather, let’s learn how to do the real agile methods better, and reap the well-known benefits.

What does this have to do with DevOps?  Hang on, we’re getting there.  One of the things  that got set aside along the way was the focus on practices that enable agility.  Test Driven Development (TDD) was at best assumed it would magically happen, and more often set aside as something “we’ll get to once we get all of our release trains and architectural runways laid out”.  In other words, never.  A possible metaphor is saying “I will start exercising once I’m in better shape.”  You have to do the technical practices first, or the rest is just a waste of time.  And this is where DevOps comes into play.

DevOps is most closely associated with the idea of Continuous Delivery.  The idea that we can at any time build and deploy the results of our development efforts allows us a huge amount of flexibility with deciding what software gets delivered and when.  The tools that help us, whether it be for visualizing and orchestrating the moving parts of build, test, and delivery, or the tools that automate these parts, have reached a level of maturity that allows us to move forward.  The question remains, does your team have that same level of maturity?

If the extent of your team’s agile mechanisms is identifying “portfolio items” that will be broken into stories that will then be scheduled into sprints, do NOT try to go straight to DevOps.  Learn how to truly embrace TDD, both at the Unit Test level and the Acceptance Test level.  Once you feel comfortable with that, you can move to Continuous Integration and then Continuous Delivery and DevOps.

If you are doing “some TDD” and daily builds, you are getting there, but ramp up the tests first.  You might be inclined to at least get some of the cool DevOps tools into place, but I highly recommend getting your TDD house in order first.  Time and energy are finite, so let’s spend them appropriately.

If you still have a “change control board” of some type that controls when a merge happens, you aren’t ready for DevOps.  Ensuring that your tests are in place and automated will help build the trust necessary to avoid constructs that are explicitly designed to slow the development process down.  Building habits of checking in code and building several times a day will allow us to catch what errors might make it through quickly, and with a much smaller delta between check-ins to identify where the errors might have come from.

So, am I being somewhat absolutist here?  Absolutely.  Rather than taking our agile practices halfway there and then saying “hey I know, let’s do DevOps now”, work on making agile everything it possibly could be.  Once you feel comfortable with your automated tool stack and delivering every iteration, then move to Continuous Delivery and DevOps.

Posted in agile, Agile Adoption, Agile Benefits, Agile Development, Agile Executive, Agile Leadership, Agile programming, Agile Project Management, Agile Software, Agile Software Development, Agile Teams, Agile Tools, Continuous Delivery, Continuous Integration, DevOps, Software Craftsmanship, Test Driven Development, what is agile | 1 Comment

VersionOne & Collaborative Leadership Team Partnership Accelerates Agile Adoption

VersionOne & Collaborative Leadership Team Accelerate Agile Adoption

Highlights

  • Strong partnership gets agile teams up and running four months ahead of schedule
  • Deep knowledge to help people at all levels adopt agile and lean practices
  • Extensive functionality to ensure business alignment and team collaboration

Challenges

As part of a large agile transformation initiative, one of the largest agribusiness and food companies in the U.S., needed an experienced consulting team and an agile ALM platform that could help them reach their goal of getting more than 25 agile teams, across several delivery groups, up and running over a 12-month period.

The company needed assistance with constructing a plan, and coaching the teams while working with executives through the process change. Since the company was using disparate systems, they also needed one platform that could help them manage initiatives across the organization, break the work down across multiple teams and programs, while ensuring alignment with business goals. At the same time, they needed a way to foster better collaboration across the teams with different agile work styles.

Solution

The company engaged with trusted partner, Collaborative Leadership Team to evaluate how VersionOne Lifecycle could support the overall rollout plan at all levels. After an evaluation of many agile ALM vendors, the company selected VersionOne for the team’s responsiveness, as well as the extensive platform functionality that would help their teams easily adopt and scale agile across the organization.

Benefits

The partners quickly engaged with the customer’s delivery teams and groups to implement the joint solution and get the company’s agile transformation started. The Collaborative Leadership Team had deep knowledge of how to apply agile principles and how to support people in adopting agile and lean practices.  And with VersionOne Lifecycle, the company gained the ability to successfully plan, track, collaborate, and report within the platform, so that everyone could have visibility into the work being delivered. In fact, one of the managers said, “The TeamRoom just blows the socks off of navigating in Rally. We needed an easy way for teams to get the information they needed.”

Working together, Collaborative Leadership Team and VersionOne were able to get all of the teams and delivery groups to a stable and productive state four months ahead of schedule.  It was fantastic to see how the consultants became trusted and well respected advisors throughout the organization, while allowing the teams the ability to be self-reliant and to continuously improve on their own.  At the same, it was great to see how people at all levels in the organization were able to start using the VersionOne and start seeing the results of a successful implementation right away.

 

Posted in agile | Leave a comment

Connect with VersionOne at Agile2016

Connect with VersionOne at Agile2016

Dates: July 25 – 29
Location: Hyatt Regency, Atlanta, GA
Event URL:    https://www.agilealliance.org/agile2016/

VersionOne is proud to be a title sponsor of Agile2016. The annual Agile Conference is always exciting for us, but this year we are especially excited because Agile2016 is being held in our hometown, Atlanta!

The VersionOne Diner

If you’re planning to attend the 2016 Agile Show in Atlanta, be sure to stop by the VersionOne Diner—our booth—and get All You Can Eat Strategy, Development and Delivery. This is a great opportunity to learn about the VersionOne Enterprise Agile Platform and how VersionOne has been serving up 100% genuine agile since 2002. Also stop by the VersionOne booth to register for our daily raffle. There will be a new winner each day.

VersionOne Speakers

Be sure to check out these presentations from VersionOne team members:

Career Growth, Recognition, and Continuous Learning for

Software Craftspeople
Steve Ropa
Tuesday, July 26 – 10:45 am – 12:00 pm

In this presentation Steve Ropa will share a Software Craftsman approach, based on his experience of many years and many development organizations, to help further the learning and career development for your team. 

Intentional Learning – Map a Successful Strategy
Claire Moss
Wednesday, July 27 – 2:00 pm – 3: 15 pm

In this workshop inspired by Dan North and Chris Matt’s work in skills mapping, you will chart your own learning adventure based on where you are now, and where you want to be in the future.

A Hands-On Introduction to Exploratory Testing
Claire Moss
Thursday, July 28 – 9:00 am – 10:15 am

In this hands-on introduction to Exploratory Testing, attendees will bring a laptop, pair with a buddy, hear a little theory on test design, open a real application, and get to testing.

Purpose Driven Teams
Matt Badgley
Thursday, July 28 – 3:45 pm – 5:00 pm

This session will explore the science and power of purpose—how purpose enables engagement, improves team morale, and can improve performance. Matt Badgley will share some simple techniques that leaders and team members can use to help clarify their purpose.

Agile2016 Overview

Hosted by the Agile Alliance, the Agile2016 conference is one of the best opportunities to meet fellow agile practitioners, from all disciplines, sharing their knowledge, experience, and passion about agile. More than 2,500 agile practitioners from 40 countries are expected to attend this year’s conference which includes over 200 sessions on agile related topics spanning 18 tracks including: Leadership, DevOps, Enterprise Agile, Government, and more.

Agile2016 attendees will walk away with practical and pragmatic strategies and tactics for furthering agile in their teams and organizations.

Connect with VersionOne at Agile2016

We look forward to welcoming you to our hometown, Atlanta!

Posted in agile, agile 2016 | Leave a comment

What is Agile Leadership?

What is agile leadership?Have you ever faced one of the following challenges with your agile adoption?

  • Executive teams who want you to be agile, but still require all the traditional metrics and reporting
  • Middle managers who feel threatened by agile and seem to be working against you
  • An organizational culture that seems to run counter to an agile way of working

If you are experiencing any of the issues above you are not alone. After working with hundreds of organizations and thousands of people these are the most common themes that have emerged. Rather than giving up on your agile adoption, it’s time to bring agility to your organization’s leadership team. You need agile leadership. Let’s examine why…

In any business there are two main roles; people working “in” the business and people working “on” the business. Agile methods, like Scrum, do a great job of addressing the roles and responsibilities of people “working in the business”. For example, Scrum says that we need a product owner; someone responsible for guiding the team to build the right product to meet the needs of the stakeholders. Most agile methods however, do not address the roles and responsibilities of those “working on the business” – AKA “management”.

Some agile experts have taken a stand and said that we don’t need “management”, that we should fire anyone with a leadership title. That is one view, albeit an unfortunate one. Another view is that we need people who are fully dedicated to; planning and setting a vision, building an agile culture, and supporting those doing the work.

My colleague Pete Behrens says that “agile leadership” is the glass ceiling that prevents our organizations from becoming agile. We need to break through this ceiling if we are to build truly agile organizations.

Now that we have examined why we need agile leadership, let’s define what it is…

To come up with a definition, I first looked at the values of the Agile Manifesto (http://www.agilemanifesto.org). In order to be an agile leader we need to:

  • Remember that it’s all about the people (individuals and interactions)
  • Focus our efforts on delivering business value (working product)
  • Form and respect the partnership with our clients (customer collaboration)
  • Plan and be willing to react in the moment (responding to change)

I also examined some of the fundamental principles of agility:

  • Transparency – When I graduated from college I worked for a small startup. One day they called us into the conference room to let us know the company was in dire financial trouble. At this point we were so far into the red that people had to be impacted. The owners of the company felt like they were protecting us from this knowledge. Because we didn’t know the company’s financial situation, we couldn’t do anything to help them. Agile leaders work hard to be open and honest with their communication. They make sure that all needed information is out in the open and easily accessible.
  • Continual feedback – Agile leaders abhor practices like the annual performance review. Instead of bottling up feedback and delivering it all in one fell swoop. Agile leaders provide feedback in the moment where it can add the most value.
  • Inspect and adapt – Agile leaders use retrospectives to frequently pause and examine the output of the team and the way that the team works together. These retrospectives allow for everyone to get better at a more expedient pace.
  • Embrace failure – By running short low risk experiments and “failing” we learn rapidly. An agile leader sees failure as an opportunity for their teams to grow, not something that should be prevented at all costs.

Finally, there are few practices I have learned:

  • Be a servant leader – Key tenants of servant leadership include; taking care of needs not wants, building and using influence rather than abusing power, and leading by example.
  • Focus on strengths – Agile leaders get to know their team members on a deeply personal level, which allows them to know a team members strengths and weaknesses. Rather than focus on the losing battle of shoring up weaknesses, agile leaders focus on building strengths instead.
  • Be vulnerable – I used to think that emotional intelligence meant stopping our bodies natural reactions to stimuli and choosing to react in an “appropriate” way. Now, I know that stopping and bottling up emotions only leads to health problems. Agile leaders are comfortable with expressing their emotions in front of their team. They realize that “being real” leads to strong relationships and greater team intimacy.

Combining what the Agile Manifesto, Agile Principles, and my own experience; I came up with the following definition of an agile leader…

“Agile leaders are inclusive, democratic, and exhibit a greater openness to ideas and innovations. With a passion for learning, a focus on developing people, and a strong ability to define and communicate a desired vision, they possess all of the tools necessary to successfully inspire others and become an agent for change within any organization.” – Center For Agile Leadership

Would you like to meet a real life agile leader? I would like to introduce you to Joe Kirk (https://www.linkedin.com/in/mrjoekirk), CIO at the Tennessee Department of Transportation. Joe has built a truly agile organization. A few of his major accomplishments include:

  • Shifted his departments culture from one where everyone couldn’t wait to retire, to one where everyone can’t wait to complete their next sprint
  • Built out co-working spaces so that his teams can collaborate
  • Recently hosted an innovation day that produced several promising product ideas

Wondering how you can become an agile leader yourself? Or perhaps you know a leader who wishes they could be more agile?

There are a number of new offerings coming onto the market today, such as our Certified Agile Leader® program. Also, in April 2016 the Scrum Alliance announced their new Certified Agile Leadership program, which follows a similar pattern to our program. We hope that there will soon be a convergence of the two programs, since they have the same goal in mind. To learn more about becoming an agile leader please visit http://www.centerforagileleadership

Posted in Agile Leadership, agile practices | 2 Comments

Connect with VersionOne at TriAgile 2016

Connect with VersionOne at TriAgile 2016

Dates:  Thursday, June 30, 2016
Location:  McKimmon Center, 11101 Gorman St., Raleigh, NC
Event URL:   http://triagile.com

Event Overview

VersionOne is proud to be a gold sponsor of TriAgile 2016. This conference is a wonderful opportunity to bring people together from all disciplines to share their knowledge, experience, and passion about agile. More than 500 agile practitioners are expected to attend this year’s conference which includes over 30 sessions on agile related topics spanning leadership, value, culture, technical practices, scaling, and more.

This year’s opening keynote features Jurgen Appelo, an internationally acclaimed author and speaker, who is pioneering management to help creative organizations survive and thrive in the 21st century. The closing keynote is Andy Hunt, an award winning author, thought leader, and Agile Manifesto signer.

TriAgile 2016 attendees will walk away with practical and pragmatic strategies and tactics for furthering agile in their teams and organizations.

Connect with VersionOne

We’re looking forward to seeing you at TriAgile 2016!

Posted in agile, Agile Software Development | Leave a comment

The ‘Game’ of Agile Compared to Football: Draft Day

What is Agile Compared to Football
More than 30 years ago Hirotaka Takeuchi and Ikujiro Nonaka wrote an article titled ‘The New New Product Development Game,’ which compares product development to rugby. This year’s NFL draft inspired me to make a similar analogy to American football. This is the first in a series of articles comparing agile and football around the major events:

  • Draft Day
  • Training Camp
  • Kickoff Game
  • Super Bowl

A football organization has a team of coaches with different experiences and strengths who are experts at football. Not only do they know the rules, but they specialize in one area (offense, defense, and special teams). Some are very inspirational, some are great with the owners of the team and some thrive on being in the trenches with the players. To be successful, they have to know what makes their players tick.

  • Agile coaches are experts in agile and gravitate to various areas of focus (enterprise agile, new transformations, team level coaching, engineering best practices, etc.)

Team management and coaches are given a budget to spend. On draft day, they pick their top college and trade picks based on position, experience, potential, and how much they cost. The players receive a salary for the season and therefore the cost of their salaries are fixed.

  • Agile teams are fixed and therefore the cost of labor doesn’t change.

Coaches recruit a cross-functional team for the different positions needed for the game (quarterback, receiver, guard, tackle, kicker, etc.).

  • Agile teams are made up of individuals with all the skill sets needed to deliver value (developer, tester, user experience, customer representation, DevOps, etc.)

The team is made up of multiple individuals that play the same position so the coaches have options when deciding who should participate in each play.

  • Agile teams can also have individuals with the same skill set. However, the team, not the coach or ScrumMaster, decides who should work on what.

Players are designated as first line or second line to indicate the stronger player. Even so, they don’t want a single point of failure, so they make sure all levels are as prepared and as skilled as they can be.

  • The agile team succeeds together and fails together so it’s in their best interest to build up the weakest link by pairing the stronger member with the weaker.

Each play has a main position and a secondary position so players can help out in time of need.

  • A team member may primarily be a developer, but can help out by executing test cases (not for their code of course) or with documentation.

The team captain designation is a team appointed position indicating the player is a leader on and off the field.

  • Some agile teams may also designate a member as a team lead. That individual is performing work along the side of the other teammates and provides guidance to and outside of the team.

Stay tuned for the rest of the articles in this series:

  • Training Camp – July
  • Kickoff Game – September
  • Super Bowl – February

Find out how VersionOne can partner with you to build winning agile teams for successful agile transformations.

Posted in agile coach, agile process, Agile Teams, what is agile | Leave a comment

Agile Metrics – Measuring What Actually Matters

agile-metrics-measuring-what-actually-matters-800x328

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”.

puzzle

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:

sequence

culture

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.

radars

clarityClarity

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?

performancePerformance

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.

leadershipLeadership

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.

CultureCulture

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?

foundationFoundation

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

consistency-is-key-when-scaling-agile-800x328

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.

Sources:
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

bug-bashing-for-beef-800x328

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:

bugbashersevent1

bugbashersevent2

 

 

 

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

still-scrumming-after-all-these-years-800x328

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