Enabling Agility

Archive for March, 2009

In some companies it’s possible to try Agile software development on a small out-of-the way project.  This is one of the easiest ways to get started.  You try something, show results and then move up to a larger-scale project.  But in some companies, there isn’t anyplace out-of-the way, and every project must engage with complex organizational structures and processes.  In these companies the best strategy for success may be to choose the opposite kind of project: one that is critical to the company and visible.

Why?

Your first Agile project will probably be one of your most difficult.

• A dedicated, full-time team is critical for success.  Most organizations who are not structured for Agile, have their people spread across many projects.  This will be one of the most difficult obstacles to overcome.
• A strong Product Owner, with deep understanding of what a customer needs, is critical for the project’s success, yet it may be difficult to find someone to fill this role.
• A dedicated team room works best for Agile projects.  This might be difficult to secure.
• The role of testers changes dramatically in Agile.  Testers are part of the Agile team.  Instead of testing at the end of the project, they are testing regularly, alongside the developers.
• The team needs the ability to regularly test new software in an integrated environment.  In many companies that is difficult to arrange or the controls around the test environment make it very difficult to test multiple times per day.
• It is likely that the management team will have a format for status reports intended for waterfall projects.  Agile teams usually can’t complete these reports since their measures of progress are entirely different.  The management team will have to learn a new status reporting methodology.
• There is documentation, but it will most likely not be the same documentation that has been produced in the past.  It will take a while for the rest of the organization to get used to the changes.
• Functional managers have been accustomed to moving team members between projects like interchangeable parts, but this will really hamper progress on an Agile team.  This will be a challenge for the functional managers to accommodate.
• People are probably used to having a comprehensive set of requirements up-front.  Not having this will likely make them uncomfortable.
• Even though project plans are often wildly inaccurate, people are used to having them and will be may be uncomfortable without one until they learn how things are managed on an Agile project.

With all of these challenges you’ll benefit from strong senior management support.  You won’t get that level of support if you’re working on a low-visibility project; the burden for solving most the the challenges outlined will fall to the team.

My recommendation is to find a project that is critical to the company and get the management team on board.  Let them know what the challenges will be and enlist their support.  If possible, have them communicate what you are doing and why you are doing it to the rest of the organization.  Use the management support when you need it.

It takes work to change an organization, but if you choose the right project and get the right support, you are more likely to be successful.

Agile is particularly good for managing projects where you have significant uncertainty about what you want to build and how you plan to build it.  It can help you cut time-to-market and costs while increasing customer satisfaction.

Here’s an example.  Imagine you want to enter the market with an analytics product that provides your customers with insight into patterns and trends within their employee population. You have various sources of data available (payroll, performance management, organization structure, industry pay ranges, state and region demographics) and a general idea of the things your potential customers might be interested in learning. This is a perfect project for Agile.

Why?

Agile is an iterative process. You build a little, you show results, and you use that feedback to guide what you build next.  Your potential customers probably have some general ideas of what they would like to see, but won’t really know until they get their hands on a system they can play with.  It would be pointless to try to get all of the requirements right up-front, because your potential customers won’t be fully able to articulate what “right” is until they see something. Much of the time you’d spend putting together a comprehensive requirements document would be wasted, since the requirements will change significantly as the project progresses.

Similarly, trying to fully understand the architecture and data requirements up front is also going to be difficult.  You certainly will have some idea of what data you’ll want and how you’ll want to structure it, but you will probably have to evolve this architecture as the business requirements evolve.

You would be less likely to choose Agile for a project where you were performing a set of tasks very similar to one you have done in the past. For example, if you have call centers in five locations, and you are adding a sixth, it probably makes sense to update the project plan you’ve used for the other call center build-outs. You have a really good idea of the requirements up front and how to execute against those requirements. Limited iteration is needed.

If you have a project where you have significant uncertainty about what you are building and how you are building it, Agile is likely the right way to go.  Using a waterfall approach on these types of projects will typically lead to excessive effort defining up-front requirements, significant rework, decreased customer satisfaction,  higher costs, longer time to market, and decreased sales (if it doesn’t do what the customers need, they won’t buy it).

I want to thank Ken Schwaber for providing me with the core idea for this post in his ScrumMaster course.

My wife got a book called The 100 Best Business Books of All Time, by Jack Covert and Todd Sattersten.  Moneyball: The Art of Winning an Unfair Game, by Michael Lewis, is one of the 100. Instead of reading the synopsis, I decided to read the whole book.

The Oakland Athletics managed to have success in Baseball while having one of the lowest overall budgets.  They did this by identifying the characteristics that were the most important for winning baseball games and hiring people with those talents, many of whom lacked other, less important, skills.  Other teams overlooked these players either because they undervalued the critical skill, overvalued the less important skills or simply because they didn’t fit the teams’ image of what constituted a “real” baseball player.

Now that I’ve read the book, I’m wondering how much companies overpay to get skills that don’t make a significant difference in their overall throughput.

It might be interesting for a manager to ask the question “if I had 20% less to spend on my team’s salaries, how would I do that”.

What are the core skills you think critical to your team’s success?  What characteristics or skills are less important?  Where are you missing skills you need?  Where do you have an overabundance of skills?  What skills are you willing to pay a premium to get?  What skills are you paying to much for?

How do you know what skills are really worth paying for?  Do you have any quantitative information to back up your decision?

Would the most important people on the team be the ones who were best able to train and develop others, so you could bring more college new-hires onto the team?

If you had to cut 20% of the total salary (not people) across your team (assuming you had total freedom to move people in and out of your organization) do you think you could do it?  Could you be spending you money more effectively?

Note: I’m not suggesting you cut your team’s salary by 20%. I think it is a worthwhile exercise to get you thinking about who you hire, how much you pay and why.

I don’t follow baseball, but found this book interesting and provocative.  I’d definitely recommend it to someone thinking about how to staff their teams effectively. If having a big bank account was the critical deciding factor in being a good baseball team, Oakland would never have made the playoffs. But they did.

The amount you have to spend on your team may not be as large as it has been in the past, but by rigorously looking at what you really need, can you still be as effective?

In the book “a simpler way” by Margaret J. Wheatley and Myron Kellner-Rogers, there’s a paragraph that got my attention.

“Life is intent on finding what works, not what’s “right.” It is the ability to keep finding solutions that is important; any one solution is temporary.  There are no permanent right answers.  The capacity to keep changing, to find what works now, is what keeps any organism alive.”

In software development, teams are often asked to follow practices that seem to impede effective work.  I’ve seen them respond by pretending to follow the formal process while doing what works behind the scenes.  Instead of being open about what they are doing, they conceal it.  And they incur the additional work of making it seem like they are following the official process by filling out the approved project templates.

How much more productive would it be if teams could talk openly about what they were doing, and other teams could learn from their experimentation?  How much more engaged would an organization be where experimentation was encouraged?  Where people talked openly about what they learned?

Have you been part of an organization that has encouraged experimentation with process and open discussion about the results?  How did it work?  What was it like being part of that culture?

I’m planning to start a branch of Scrum Club in Nashua. It provides people with a opportunity to learn about Scrum, practice their skills and network. Right now I’m getting the structure in place and could use a team of folks to help. Please let me know if you’d like to be involved. We’ll use Scrum to run the process of setting up the group.

Here’s a link to the Scrum Club web site:

http://scrumclub.org/

I met the woman who founded the organization when I was in Los Angeles in January, through George Schlitz, and decided I wanted to become part of it.

The first session they held was a “Startup Weekend” which just completed in LA (http://startupweekend.com/ ). I think we’d try to do the same thing.

Send me email if you want to be involved in getting the club started (bobfischer@me.com ). One thing we’ll have to do is get registered as a non-profit, so anyone who has experience doing that would be a big help.