Archive for April, 2010

Selecting the Best Agile Pilot Team

April 22nd, 2010 by Bob DeMaria

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?

Is your Executive Team Committed to Agile Adoption?

April 20th, 2010 by Bob DeMaria

We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation.  #10 on that list was the Executive Commitment.  We all know that having an executive team committed to the success of a project of any kind is important, but in the Agile world it is even more critical.  Adopting Agile as a new methodology is a major shift in the way of thinking of how your business is being run, for the better.

As Agile adoption starts to take hold in your organization it can follow two different paths – from a motivated development team on up, or from an executive edict on down.  Either way you have decided to make a move toward Agile adoption, one of the very first hurdles you will encounter is executive buy-in.  Many changes are in store for your organization and to insure success you’re going to need to have that executive commitment.

First and foremost, let’s make sure the executive team has complete sponsorship of the Pilot project. While I will discuss selecting a Pilot team in a future blog post, you need to make sure that management is behind this launch. Management needs to be completely committed and willing to smooth any resistance that you may run up against as that pilot process starts to take off and Agile practices start to take hold.

Next is the area of trust and respect.  The people taking part in the transition need to do their best. There’re going to be a lot of changes happening within in the organization: the way people think, the way people function, the way teams interact.  Management really needs to be committed in changing to Agile development, and while there are going to be some pains and adjustments necessary, management will trust and respect that people on development teams are making the best choices for the organization.

Trust and respect is important due to the fact that Agile practices cause a major shift in the ways of thinking.  You’ve probably heard mention of the cultural change that Agile is going to impart on your organization. Executives need to be aware of a major shift in the way people think and the way people do business.

To expand on that just a little bit, it is necessary to ensure that the entire organization supports the transition to Agile development.  I’m not talking about just the development teams; we need to make sure that management understands that it’s going to impact the customers, and for the better. Agile is going to make the organization more productive, more effective, and more efficient, but it is going to cause changes and growing pains as we move towards that process.

One other area that I wanted to bring up briefly, is that going Agile does require an investment.  So management needs to understand there will be upfront investments in transitioning to Agile development and in turn, reaping the benefits of Agile.  That being said, rate of return on your investment can be very swift.  I’m tempted to say “will” be very swift, but obviously it’s going to depend on the successfulness of the project.

To understand some of those returns is to really understand the business benefits and value as well as making sure executives understand those as well, because there is a lot of value to the organization by adopting Agile. It’s not just making better, faster developers, obviously.  We’re talking about faster time to market.  Because we’re developing and shipping smaller increments of high-priority code we’re able to get that code to market much more quickly. That is obviously going to mean increased revenues by being able to hit the market need more quickly and get EXACTLY what the customer wants out the door. We’re going to be able to achieve an increase in revenue based on those features and those enhancements that are going out the door.

All of this because of the way the Agile development process is done and the way testing is baked-in and moved closer to the development cycle.

So all of those features that are getting to market quicker while increasing our revenues are going to be higher quality, as well.  Overall that’s going to greatly increase customer satisfaction as to the type and the software features they’re actually seeing based upon our Agile development.

Now that the executives are on board… how about we take a look at picking the Pilot?

Benefits of Agile Development for Your Enterprise

April 13th, 2010 by AccuRev

Due to the promise of large gains in quality, productivity, and market responsiveness, Agile software development has been making its way into the enterprise in recent years, but there have been plenty of bumps along the way.  Any change to the enterprise has hurdles to overcome, and successfully adopting Agile development requires change within the organization than we have seen in the development process over the past several decades.  For instance, as you transitioned from C++ to Java or .Net, did you find it necessary to make substantial changes to your org chart?  Most changes in the software development process have been either the result of technology changes, such as moving from C++ to Java or pure html to AJAX, or changes in architectural patterns such as the introduction of object-oriented programming and moving from client/server to SOA.

Enterprise Agile Development May Be the Answer

Sustainable and repeatable success with Agile requires the same sort of framework put in place with your traditional development projects across the enterprise.  The end-to-end traceability, progress and status roll-up, portfolio management, and inter-project coordination that you have with your traditional development projects will be just as critical on your Agile projects.  After all, Agile is not the goal, it is only the path to higher quality, greater and more rapidly delivered ROI, and increased customer satisfaction.
Not only will you need a framework that encompasses all of your Agile projects, you will also need a framework which can encompass all of your projects, regardless of methodology. Doing this is likely to require re-tooling, training, and integrating multiple tools across projects.

Agile in the Enterprise Requires Top to Bottom Involvement

Adopting Agile without understanding the principles and without creating a proper ecosystem for its survival, Agile may be destined to fail. I’ve visited far too many companies whose first attempt at adopting Agile failed because the extent of their investment was a single visit from an Agile coach. In these circumstances, few people are usually on board initially, and many skeptics exist because of an insufficient effort invested in preparing for success.
Adopting Agile development requires breaking down mental barriers and building up new skill sets. There is nothing particularly hard about actually implementing any of the specific Agile practices, but many of them are counterintuitive and do take a bit of practice to get used to. Don’t underestimate the amount of effort required; it is at least on the same order of magnitude as taking a team very used to writing in C++ and moving to Java. There’s nothing particularly difficult about such a transition, but there are many subtleties which must be learned and it takes some time to build up the same base of experience.
Committing to the effort required and funding the necessary training, coaching, and retooling requires involvement from the top of the engineering organization all the way to the folks in the trenches.

Your Enterprise is Optimized for Traditional Development

Actually doing Agile development is relatively straightforward, much as going 60 miles an hour is easy to do driving on an uncongested highway. As the original challenge of fast travel was a lack of cars, highways, and driver education, the main challenge with going Agile is creating the proper environment for Agile to take root and expand.

Over the years, your enterprise has done everything it can to provide the proper environment for traditional development to thrive. But what is considered fertile ground for one crop can be a difficult environment for another crop. Consider how all of the following have been tweaked over the years to optimize for traditional development. I’m sure you can think of more.

• Where people are physically located

• The reporting structure (silos)

• Your software development tools

• Homegrown tooling and scripting

• Metrics and reports

• The budgeting process

• Skill sets, training, work habits

• Process documentation

• Fixed bid contracts

Each of these are like the rumble strips on the highway, reinforcing the form and function of traditional development. The form and function of Agile development is very different. Instead of helping, the infrastructure that is currently in place to reinforce and optimize traditional development very often discourages effective Agile adoption.  Consider the simple example of budgeting.  If budgeting is currently based on the cost of features promised for the fiscal year and governance that rewards the delivery of those exact features and punishes variances, that will not only reduce the chances of a successful Agile adoption, it will also significantly reduce the potential benefits of Agile.

Agile in the Enterprise Requires a Hybrid Approach

A full top-to-bottom transformation to Agile development will likely result in significant changes to the organizational reporting structure, physically moving people from one location to another or even rearranging their workspaces (whether it is down the hall or across continents), and changing the interaction between people at all levels, from customers and product management all the way to developers and the folks in operations. For most enterprises, a change of this magnitude can’t (or won’t) happen overnight. For most people, a hybrid environment will be part of their experience for many years. And of course, there may be some projects that you have no intention of moving to Agile.

Partnering With AccuRev to Bring Agile into Your Enterprise

The process of each of our customers is different, ranging from small collocated shops to large distributed organizations with locations across the globe, from Agile eXtreme programming to CMMI level 5 waterfall. We understand a wide range of methodologies and how they interface.

At AccuRev, our core expertise is process improvement. Adopting Agile in the Enterprise is all about process improvement. That’s why we’re excited about our new offering, AgileCycle, which has everything you need to go from where you are to where you want to be. With AgileCycle, you don’t need to worry about doing a big-bang transformation. We’ve got the expertise, coaches, trainers, consultants, and of course the tools that will allow you to transition to Agile at your own pace while smoothly integrating Agile, iterative, and Waterfall methodologies and your existing tools across your enterprise.