Archive for April, 2010

Choosing the Right Agile Project Management Partner

April 30th, 2010 by Bob DeMaria

agile project management partnersIn the last post we discussed the benefits of choosing the proper Agile tool stack for your Agile migration.   Another very important aspect of migrating to, and being successful in, an Agile implementation is also # 6 on our countdown of the Top 10 Agile Success Factors; selecting the right Agile project management partner.

As you can probably imagine, I don’t just mean a tools partner. I am talking about much more than that. I’m talking about a partner that offers training, provides coaching.  I’m talking about support and professional services, I’m talking about tools, and most importantly, I’m talking about how all of these pieces of project puzzle fit together during a successful Agile implementation.

You’re going to need experienced people who actually know how to do Agile and know how to do Agile right. That means knowing the pitfalls too, knowing where the landmines are and knowing how to avoid them. Your developers have been refining and perfecting their development methodology, their traditional methodology, for years. It’s tough to break habits. Knowing how to do Agile right and knowing where to watch out for pitfalls is very important.  Without that knowledge it can be very easy to fall back into old habits when you run into your first set of speed bumps.

It’s also very important to have somebody who is very experienced in Agile project management, not just project management.  Agile project management, as many know already, is in fact very different. So to make sure the project is successful we need to make sure that somebody is experienced in Agile project management.

If you are looking at putting tools, services, training, and coaching in place, another important aspect is having a single point where you can go with any questions or issues. Services and support gives you that “one neck to ring” when you require assistance. The last thing anyone wants to do is have eight vendors in the mix, and every time you have a problem you’ve got to go check with each one of them, and then they start pointing the finger at the other folks in the room. So having all of that information from a single vendor is obviously very, very critical, and can ease the implementation and rollout, thus making your Agile implementation more successful.

Lastly, it is making sure the partner can not only implement at a team level, but also to help you expand across the organization. So not only somebody that can get your Pilot team up and running and maybe some of the smaller teams that are beginning to explore Agile, but be there as a resource to guide you through your Agile maturity on the road to a successful Agile adoption across the enterprise.

In summary, the right partner? I would recommend a single vendor with Agile project management experience and the ability to scale Agile across your organization.

Do You have the Proper Agile Tools?

April 28th, 2010 by clucca

We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation.  Number 7 addresses the question of a tools stack. Once Agile coaching and training is complete, now we can think about tools.

Agile manifest declares:  ”Individuals and interactions over processes and tools.”

But we believe that this statement doesn’t mean you should forget your tools stack entirely. It’s really about making sure that your toolstack helps facilitate those interactions between individuals.

So it’s no surprise to us that when we hear about people rolling out Agile, they don’t even consider upgrading any of their tools. Studies have shown that new teams that do not invest in Agile tool sets, automated testing and continuous integration, start to struggle around the 10th iteration (4-5 months). The backlog of bugs and to-dos become so great that teams have to stop what they are doing and do a “maintenance” iteration, where they do massive amounts of QA or stop and do code reviews for an entire iterations. If we think about it, this kind of seems like traditional development model doesn’t it? Are you really Agile if you can’t deliver something which is “done” after every iteration?

The problem? Your current toolstack was designed by people who had traditional development models in mind.

Agile tools must help you build a testable, deploy-able app every 2 weeks like clockwork.

Your tools don’t actually facilitate shorter development cycles, they actually hinder you by getting in your way. Your tool stack shouldn’t be the impediment in your Agile rollout.

Lets start with an Agile project management tool. This is the obvious tool to replace in your stack. Converting your traditional issue tracking system to an Agile one will give you the speed and visibility to help your teams practice Agile on a day to day basis.

Traditional source control management systems also hinder the process by following a “waterfall” like model of isolating code changes and leaving them on branches. Most SCM vendors know this is a problem, which is why their solution for an Agile branching methodology is to consolidate branches, or have entire teams work on one branch. This doesn’t make sense. All of your scrum teams should be able to function together and in parallel, while integrating work together on a regular basis.

Smaller iterations mean a faster paced development cycle. Some of the tasks that you used to do a handful of times over the course of a waterfall will now be done on a weekly, sometimes daily basis. This is where continuous integration and test orchestration come into play.

While you’re moving through a 2 week iteration, using continuous integration and automated tests suddenly becomes extremely important. Having these processes in place can help you avoid the 10th iteration problem we talked about earlier. You’re not going to have 4 months to regression test the application by hand in Agile.

The idea here is that your Agile tools must help you build a testable, deploy-able app every 2 weeks like clockwork. You will repeat this process over and over. Isn’t it time your toolstack provided you with clockwork development cycles?

Agile Training & Spring Training

April 26th, 2010 by JMartin

We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation. Guest blogger JMartin, of Rally Software, enlightens us on our next factor.

Number 8 is all about Agile Education, or as I like to call it, Agile Spring Training.  After choosing our Pilot team, it only makes sense they next need Agile training and coaching.

Another season of baseball has started.  Baseball seems to have such a long slog of a season.  It’s hard on the fans, that’s for sure.  I suppose it might be hard on the players, too, eh?  And even so, every year, there is still Spring Training.  The teams gather in the warmer parts of the country to practice and scrimmage and practice and work out and evaluate and practice.  How much does the average player make?  Couldn’t the teams be getting a better return on their investment if all this extra time players were using to train and practice was put toward “real” games with full-paying customers and sponsorship back home?

Obviously, training is important.  Spring Training helps provide and refresh the underlying skills of the professional baseball player so that he can move beyond his talent and perform with his coworkers on the field.  Even the most expensive players train.  Really, a successful effort of any kind requires some level of training.  For the players on the field, it is important to train them together to give them a common feeling for each others’ behaviors and to focus their vision on the same goal and approach as provided by their manager.  In the same way, teams adopting Agile should be trained so that they have an understanding of the process and so that they share a common language to help them have or improve upon communication about what’s going on as they dive in.  By giving a team a common language and skill set to operate with, we eliminate the kinds of hiccups in execution that are caused by incompatible expectations and other breakdowns in communication, as well to keep the players from getting lost.

Agile Training provides common languages and a pattern set for teams to understand and follow.

Did I stretch the baseball metaphor in there enough?  If not, think about this: after Spring Training is over and the season begins, are the players just released onto the field and left to play games on their own?  No, they go through the season with a staff of coaches who monitor their performance and help them plan and improve both their off-field training regimens and their in-game strategy.  Baseball teams get help in another way, too:  at the end of the season, the teams that are on-track for the pennant race do something interesting to their teams.  They start looking around for seasoned players.  The seasoned players aren’t brought in so much for their skills in playing the game itself (we’re relying on the younger, faster kids to do the hard work!).  You’ll hear sportscasters talk about how player X was brought in to provide experience and stability to the team as it hits the turbulent times of post-season play.  They help mentor the younger players both about on-field strategy and about dealing with distractions.

Agile training and coaching works in a similar way.  Training provides common languages and a pattern set for teams to understand and follow.  A good training set will provide muscle memory for the basic mechanics of Agile.  And an environment geared toward allowing team members to get the technical training and in-fill they need helps the team be ready to succeed in the game.  It’s great for the tactics. But very successful teams also get the help of a coach.  An Agile coach can provide help at the strategic level, helping to plan the agile rollout and watching team behaviors to suggest areas for extra practice or additional training.  In addition, a good coach is someone who has real experience.  When a need for help arises in the team, the coach can pull from her well of experience to give the team not just a way to strategize their way around a rock but a little bit of the confidence from having gotten through those rocks before.

Somehow, I went from baseball to kayaking.  I’d better stop before I bring in some curling metaphors.  The point here is that a successful agile adoption requires the creation of a culture of learning and that learning must be provided at the tactical/basic mechanics level and at the strategic/vision-oriented level.