When we think of hybrids, we generally think about cars and going green.  There are also a handful of other hybrids that come to mind, hybrid bicycles, hybrid golf clubs, and even hybrid dogs (this was a new one to me…).  In general, hybrids are the union of two similar functions that have a different focus combined to do one thing really well, meant to give you flexibility and adaptability without sacrificing quality.  Let’s take a hybrid golf club for example; it’s a combination between a fairway wood and a long iron. It gives you the ability to hit a golf ball long distances with pinpoint accuracy, and often from a tough lie.  The best of both worlds.

So how does this apply to adopting Agile across the enterprise?

Real World Agile as a Hybrid Process

Well, let’s say that we’ve already gone through and had a successful Pilot Team, and now we’ve started to scale Agile across the enterprise.  As this process begins to take shape any large organization will likely have a mixture of teams; some that already adopted Agile, some that may be in the process of migrating to Agile, and others still running a more traditional (waterfall) approach to software development. You may also find organizations that will always have a need to use the traditional approach. Many of the Agile purists out there may not agree, but there will likely always be projects or products that people feel are not a good fit for this methodology. Having these two processes coexist seamlessly in your development organization would fit the definition of a “Hybrid.”

With that in mind, the ability to support a Hybrid Process, or a term we’ve used lately – Real World Agile, is extremely important to being successful at your Agile implementation. We see this impacting three areas of your Agile adoption:

• Support ongoing waterfall development alongside Agile development
• Support transitioning to Agile as adoption spreads across your enterprise
• Support changes to your Agile methodology as you inspect and adapt

So let’s talk about each one of these in a bit more detail.

Supporting two different development methodologies requires the ability to enforce a structured, traditional, waterfall approach while also being able to adapt to a more dynamic Agile approach.  In order to deliver a single product, this requires parallel support for the methodologies of both teams. Facilitating the integration of stories from the Agile team and integrating that with the code from the traditional team are necessary for this delivery. You must also be able support the tools that support both of those methodologies; for example a newly implemented Agile project management tool and an in-house issue tracking system, coexisting in this heterogeneous environment.

To aid in the transition to Agile, we also need flexibility to migrate a traditional development team and their traditional process to an Agile development methodology cleanly, quickly and easily. Taking them off a very restrictive branch and label-based tool, which might put constraints on how they are implementing your process is going to impact and impede that adoption from an Agile methodology perspective.

Lastly, we’ll need an ability to support a variety of processes with multiple development staging areas to accommodate work-in-process, code reviews, testing, and accepted work of the Agile team. Each one of these staging areas will need continuous integration functionality, one of the practices adopted very early in the migration to Agile. And as we know from one of the key Agile principles, inspect & adapt, we need to be able to change this process as we decide what works and what doesn’t work during our retrospectives.

Support for all three of these process variations will not only determine how easy or how difficult your migration to Agile goes, it may very well determine the success of your Agile adoption across the enterprise. And as the use of Agile methodologies continue to expand throughout the industry, the need to support a hybrid process inside organizations will become more prevalent. Without the proper principles, practices, and tools, the methodologies of Agile and waterfall will not coexist as seamlessly as the functionality of my #4 Hybrid club. Fore!

Is this rational?

Way back in my first job out of university, I was working in Washington, DC, as a Navy contractor, helping manage changes to an electronic countermeasures system.  Ah, those were halcyon days, when I was young and innocent green and scared of my own shadow.  There was this one person I had trouble getting along with, not so much because he was a mean person, but mostly because he would make wild statements and push the team in directions that didn’t seem logical to me.  Sometimes, he would advocate for decisions that seemed to me obviously to be bound for failure.  He was overbearing and he was old.

(Actually, he was about the same age I am now; a disturbing thought as I look back.)

Because he was old and I was uncertain, I couldn’t bring myself to disagree with him out loud.   I eventually was able to describe the situation to my boss, who responded with a statement that has never left me.  He said, “There are people who have 20 years of experience, and there are people who have one year of experience repeated 20 times.”

Culture of the Agile Process

The big difference between the two kinds of people is that the latter have lived their lives, reflected upon the things they’ve gone through, and learned from it all.  We often talk about Agile processes as being “empirical.”  What I mean when I say that is a team makes its commitments, and structures its delivery model around reality.  We don’t commit to delivering five times more in the next week than we’ve ever delivered in a week before.  We don’t abandon a practice just because we’re bored with it.  But the only way this reality-based planning and execution can work is if we go back and look at the reality we’ve experienced, review what worked and what didn’t and work to enhance the former and minimize the latter.

An excelling Agile team is continuously improving, and to do this it must be continuously inspecting.  We expect scrum teams to perform retrospectives at the end of every release and at the end of every sprint.  I encourage teams to also get into the swing of considering that every morning’s answer to the questions “what did I do yesterday?” and “what am I going to do today?” includes the implicit assumption that reflection on what you did yesterday informs what you are going to do today.  I am advocating for daily retrospection.

In rolling out Agile, foster a culture of continuous examination of what you are doing weighed against what you are trying to accomplish.  In addition to encouraging review of sprints and releases, continuously review your roll-out itself.  As you roll out new processes, regularly hold retrospections with the teams that are implementing and being affected by the roll-out, so that you can learn from their successes and help other teams avoid their mistakes.

Inspect and Adapt

The buzz phrase for this kind of behavior is “Inspect and Adapt.”  I see a lot of teams go through the motions of inspecting, but many of them don’t follow through with the second part.  Don’t bother to inspect something if you aren’t prepared to act upon the results.  An extended gripe session is nice to let off steam, but a team isn’t going to be enthusiastic about returning to the same old gripes sprint after sprint after sprint.  This is what happened to “lessons learned” meetings in the olden days: somebody diligently wrote up a report about the things we supposedly learned and then tossed the result in a filing cabinet and we would return at the end of the next project with exactly the same complaints.  When you are leading a team through retrospection, be prepared to act on the results (and make sure the team is empowered and resolved to act, as well).

However, if we come out of the retrospection with a prioritized backlog of improvement, we can plan that improvement into our practices and pull items off the backlog as we implement solutions.  We can all make commitments to the non-development activities that might be necessary to make our environment a better place.   If the backlog seems like it is filled with impossibly large problems, well, what do we do when stories are too big for our sprints?  We break them down.  Encourage the team to think of the smallest possible change they could make to improve their process.  Then encourage them to break that down smaller.  Then implement that first.

In this way, we can start being a team that has experienced 20 sprints instead of team that has experienced one sprint 20 times.

Number 5 on our countdown of the Top 10 Agile Success Factors deals with organizational change during Agile adoption.  As an external coach and trainer, I stand around in airports a lot.  I imagine we all have a story about the worst airport in the world.  The worst airport I regularly frequent is Denver International Airport.  The airport itself, to be fair, is a nice space.  The common area is open and airy, and although it is a largish airport, I never feel overwhelmed by crowds there.

Except for when I’m standing in the airport security line.

You’ve seen these lines at every airport.  The airport security experience is divided into two areas: waiting in line to show your ID/boarding pass and standing in line to be examined by metal detectors/x-ray machines.  Last trip out of Denver, I found myself in a line that was moving surprisingly quickly.  We all trundled through the maze of cordon ropes to get to the gentlemen who were checking IDs and boarding passes.  There were three of them and they were burning through the passengers at an awesome speed.  I was feeling good about their improved output.  Go airport security!

That was until I got through these ID-checkers and found there was nowhere to go on the other side because the two lanes of X-ray-ers hadn’t been able to absorb the impact of this improvement.  But the people behind me kept coming.  So, herd that we were, we kept trying to fit into the area between the checkers and the X-ray-ers, and our line got more and more crooked and bent away to the left.  The checkers were processing travelers with gusto. We filled up that space.  We spilled over into an area that was perhaps out-of-bounds.

I assume it was out-of-bounds, because that’s when we started getting yelled at.

So, I had to wonder, instead of yelling at us, couldn’t they have taken one of the guys off of ID checking detail and had him help with the X-ray processing?  Even if he isn’t certified on X-ray technology, he could be getting those bins lined up or helping people remember to take their laptops off or spotting those huge metal dangling earrings and full-arm-bracelets on the person in front of me before they try to get through the detector?

Similar Principles Arise with Agile Adoption

The same thing can happen with an Agile adoption.  It’s all well and good for a development team to adopt a few practices here and there and make their lives easier and improve their delivery.  Suddenly, you have a team that’s pumping out bits of code that can provide real value, but there’s some other group down the line that’s suddenly overwhelmed by this output.  The team is doing what it sees as its job and has optimized for release, but the local optimization impacts the overall system.

In Scrum, we start teams right off trying to help with this traditional optimization problem by pulling testing forward.  A delivery team is made up of developers and the testers and integrating their workflows. Involving them in the speed and planning improvements mitigates this firehose effect.

We’ve seen teams grasp this pretty quickly and Agile testing is no longer an oxymoron.  But what about the other teams that are affected?  We’re still seeing database teams and infrastructure teams that are segregated and isolated from the planning and execution of software development.  The marketing and customer-facing disciplines are often unable to understand how to go with the flow.  Since we care about full-delivery, the delivery is the full responsibility of a team and the best way to accomplish this is through a whole-team focus, a team that is composed of the right people to do the entire job, a cross-functional team.

Agile adoption is not just a whole-team effort, though; it’s a whole-organization effort.  Individual teams may adopt Agile, but without corresponding organization adjustment (creating the right truly cross-functional teams, scheduling vision and working packages to facilitate work management, creating a learning culture, supporting self-organization, etc), productivity increases will be washed away in argument and finger-pointing as other parts of the organization fail to have their gears mesh well with the teams that are changing.

Finding the Real Value of Agile Practices

Organizational structural change may be required, but it is only a tactical response.  The strategic piece is in the commitment to adopt Agile principles as well.  Agile practices work well because they map back to a set of Agile principles that guide personal interactions in the teams and super-teams.  The organizational leadership must be ready to lead the way by both showing and telling.  In the airport security example above, the root of the problem may have been an understanding and commitment to value.  It isn’t valuable to the customer to get through ID checking quickly.  The task is important, but it isn’t valuable on its own.  Sure the guys were doing a good job, but if I don’t get to my gate more quickly (without sacrificing security (there’s a whole post on quality wrapped in that parenthetical, eh?)), it doesn’t matter.  The value to the customer, and the thing that should be driving the entire group, is the final result.

However, if the high-performers are being rewarded for task execution instead of value execution, then there is nothing to encourage them to take up their Agile responsibilities and organize the workflow in such a way as to gain improvement.  They are being rewarded to look at local optimization instead of global optimization.  This is exactly what happens when you rate the quality of a tester on the number of defects she finds and on the developer when you rate only the number of new features she is delivering

An Agile organization encourages transparency and visibility because high-bandwidth communication between team members and between teams helps everyone involved perform and adjust as the work progresses.  We use burn down charts and taskboards to facilitate this communication and we have to recognize that it is the planning and execution of the work that is important, not the control of the initial plan.  This cannot work in a culture that is punishing me for showing that my tasks are going to take longer than originally planned. Only by giving you that information honestly and as early as possible, can we as a team do something about the problem.

Remember, you get what you measure for.  If we believe in the team-based and value-based principles, then our rewards and measures must reflect this.

We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation.  Next up is number 9, selecting an Agile Pilot team.  We mentioned in our last post that the Pilot team is one area we need executive commitment on. The next logical step in the Agile adoption process is getting the right Pilot team to use the Agile methodology successfully.

The success (or failure) of this initial Pilot team is really going to hold the success of your Agile adoption across your organization.  If this team were to fail, people are going to view Agile as a methodology that fails, and not necessarily the team itself.  So this could hinder or even kill the adoption of Agile across your organization.  Choosing the Pilot team is a very important first step as we start to move towards Agile adoption and implementation.

Once again we’ll require support from upper management, but this time because running an Agile pilot is going to impact the teams around this Pilot team.  It’s going to impact their customer base. It’s going to have resistance from some developers in the organization and management in the organization. Everybody feels a bit of resistance towards change, right? Agile adoption is something that’s going to make us better, make our product better and allow the ability to deliver better features and better products to our customer base.

One area that I want to talk about is that the team needs to be properly trained and coached.  I mean this absolutely, sincerely.  I’m not talking about, “Let’s get one of the guys in my organization an Agile book and have him read it and then go teach the Pilot team on how to do Agile.”  I’m talking about a professionally-trained organization from somebody that knows how to do it, from somebody that has done Agile development before.  Someone who knows its pitfalls and can actually lead and educate your team on how to do Agile and how to do Agile right. That’s very, very important.

Next, the team should be committed to delivering features. The reason for this? One of the common pitfalls during Agile adoption is going after too big or too small of a product. To alleviate this problem, get the team to commit features, going after one particular piece of a larger product. For example, let’s say maybe you have a product that has a GUI portion, a Core portion and a backend database portion. We might suggest you go after the GUI portion of that particular product and allow that team to go Agile, so as to see some immediate and very visible results. Again, this is a great way to deliver something concrete, to see commitment, and to see goals being achieved. This is all based on selecting the right project for adopting Agile as a Pilot.

There are actually four areas of importance when considering a Pilot team; Duration, Size, Importance and Senior-level sponsorship. What I mean by duration is identifying a project that is not too short,  but not too long. We don’t want an extremely short project so people don’t have time to settle into a cadence and I don’t want to select something too long so it takes forever to achieve a goal – we might suggest 2 to 3 months.

We also want to look at the size of the team. We don’t want it too small or too large. So we’re looking at a single mid-size team. Too small, and people might think, “Agile worked for that little, small Pilot team but is it really going to work in our larger development organization?” And too large may give too much complexity for that first Pilot team. So it is good to start with a single mid-size team – need I mention the 7 +/- 2 rule?

The level of Importance of the project is critical to the visibility of success. The project that they’re working on should be important to the company. The GUI project that I mentioned, very visible. They have to succeed or there’s going to be a major problem with the product. So everybody is motivated to have that team succeed and when they do it’s going to be noticed.  Success or failure… it’s going to be very VISIBLE!

Lastly is the Senior-level sponsorship and having a key business sponsor to back up the Agile Pilot team. As we run into resistance or we run into problems, we need to have somebody there to fight the good fight and to smooth those things over.  Remember, this is the direction of the organization and it is in the best interest of the organization.

Great, so we’ve selected our Pilot Team… now what?

AccuRev is co-presenting a one-day seminar on Agile Development Transformation:

“Mitigating Risk with Agile Development: Great Software, Great Business Results.”

Where:10 Maguire Rd, Bldg. 1, Lexington, MA
When: Thursday, February 26, 9:30 – 3:30

Details and registration

Speakers: Rich Mironov (Enthiosys); Johnny Scarborough (GlobalLogic); Damon Poole (AccuRev)
Cost: $50 for qualified registrants ( List price $595 ). Seating limited to 50 attendees.

This one-day session will include detailed presentations, interactive exercises and open discussion on:

• Agile development approaches including distributed agile methods, the history of agile, and agile manifesto
• A detailed walk-through of Scrum, one agile approach
• The organizational changes required for successful agile adoption: executive commitment, cross-functional teams, and coaching
• Hear first-hand from one of your peers about how to bring about agile adoption and improved results.
• Roadmaps, releases, iterations and the iron triangle
• Business drivers, business value and customer collaboration approaches
• How to evaluate technologies when adopting agile

This seminar is intended for CTOs, Vice Presidents & Directors of:

• Software Development or Engineering
• Product Management
• Business Units

All attendees will receive free copies of two new books:

Scaling Software Agility: Best Practices for Large Enterprises by Dean Leffingwell
The Art of Product Management by Rich Mironov