Agile Data

Adopting Evolutionary/Agile Database Techniques

Follow @scottwambler on Twitter!

This site has presents a wide range of philosophies, proven techniques, and one or two reasonable theories about effective ways to go about the data-oriented aspects of software development. What it has not done is discussed what you need to do to succeed at them. Until now. in this article I describe how your organization can adopt the agile database techniques described at this site. My expectation is that it will be difficult for many organizations to adopt agile database techniques. It is not because there is any inherently complex about them, the problem is due in the most part to cultural inertia. To successfully adopt these philosophies and techniques you must:

  1. Change the way you look at software development
  2. Understand the challenges you face
  3. Actually try it
  4. Block non-agile co-workers
  5. Be realistic
  6. Let us help you become agile

1. Change the Way You Look at Software Development

The philosophies and techniques described at this site have several significant implications for your organization. My experience is that you must accept that:

2. Understand the Challenges you Face

You also need to understand the challenges that you are likely to face when introducing agile data techniques into your organization. My experience is that the most difficult challenges that you will need to overcome are not technical in nature but instead are people oriented. At the risk of promoting stereotypes, I have found that experienced IT professionals, novice developers, and managers all seem to have their own unique challenges that need to be overcome. Let’s look at each group one at a time.

Experienced IT professionals, often people with twenty or more years in the industry, likely:

Novice IT professionals are also struggling with learning agile techniques, although they face different challenges. They likely:

Managers within your organization have their own unique issues regarding agility. They often:

  • Can’t provide adequate resources for your team (or simply do not understand what they are).
  • Have had bad experiences in the past with new techniques and is unwilling to try yet another one.
  • Believe that agile software development is another fad and will go away after a few years.
  • Don’t realize that an agile development team requires other parts of the organization, including both IT groups such as enterprise architects and data management/administration, to work in an agile manner as well when they interact with the team.
Agile Database Techniques
Everyone needs to approach agility with an open mind, ideally without any preconceptions. They need to look at the big picture, recognize that they have serious problems that aren’t going to go away unless they act. Ideally everyone needs to work with, and be mentored by, experienced agile developers in order to learn these new approaches. Although it is possible to bootstrap your project team, and even your entire organization, into agile software development you are much better advised to seek the help of people who have gone before you. Education and training in agile software development is also important although not as critical as good mentoring.

Experienced developers and managers need the opportunity to try these new ways, and more importantly be given the time it takes to break themselves of their “bad” non-agile habits. Novice developers need to focus on education/mentoring as well as simply gaining experience. Novice developers will likely learn agile techniques easier than experienced developers will as they have less baggage to discard along the way.

3. Actually Try It

There is a significant difference between theory and practice. You can read about something all you want, but until you try something you truly won’t understand it and its implications. At some point you’re going to have to get your feet wet and try this stuff out on a real project.

Remember the adage
"In theory, theory and practice are the same,
but in practice, they are not."

4. Block Non-Agile Co-workers

A common strategy is to start with a pilot project that tries the new techniques in practice so you can gain some insight into how they’ll work within your organization. Although this enables the individual team to be agile the challenge is that the rest of your organization is still following your existing, non-agile approach. The implication is that they may expect certain models or deliverables to be delivered at specific times in specific formats, or they may require status reports or other management artifacts, or they may require you to follow their non-agile procedures. Ideally you should negotiate away the need to venture into this bureaucratic morass, realistically you often can’t and therefore you put your pilot project at risk of failure (exactly what many of the bureaucrats are hoping for).

One way to overcome this problem is to assign one or two people on your team to be a blocker. In North American football the primary goal of a blocker is to prevent the other team from sacking your quarterback or tackling your receivers, either of which would cause your play to fail. In software development a blocker attends the meetings of the bureaucrats and produces the work products that they require, freeing up the rest of the team to focus on the activities that actually lead to building your system. The blockers effectively implement a “process façade” around your team that makes it appear to the rest of the organization that your team is following their existing procedures. This satisfies the bureaucrats, yet prevents them from meddling with the people that are doing the real work. Although it sounds like a wasted overhead, and it is because it would be far more effective to divert both the blockers and bureaucrats to efforts that produce something of value, the advantage is that it enables the rest of the team to get the job done. The role of blocker is often taken on by your team’s project manager or coach, although in the past I have let this be a revolving role on the project so as to spread out the pain of dealing with the paper pushers.

5. Be Realistic

The following list describes several important factors that you need to consider when bringing agile database techniques into your organization.