Social, Agile, and Transformation June Update

It's been an interesting couple of months, so I thought I'd update readers of this blog on some exciting news

First, BusinessWeek.com relaunched its home page last week. As I tweeted last week, this project has been another success story on implementing the agile lifecycle in an enterprise. I can't disclose too much of the technology secrets behind this page, but what I can say is that we didn't directly use a CMS to produce the page and I would hardly label our approach "proprietary".

Second, I presented at the Mark Logic user conference last month, "Content, Community, and Agile Transformations at BusinessWeek". You can see the presentation below. Mark Logic also presented BusinessWeek and McGraw-Hill with an innovation award for launching Business Exchange. The photo to the left is me accepting the award.

Finally, it was pretty exciting to see this blog listed on the Top 200 Blogs for Developers (Q2 2009). Thanks Jurgen Appelo.

Content, Community, and Agile Transformations at BusinessWeek

View more documents from isacolick.

Top 5 Reasons Why Agile Development Spurs Innovation

Following an agile software development process does not guarantee innovation, but following this development process does increase the odds of teams producing more innovation and innovative solutions. The list below illustrate elements of the agile processes that increase the likelihood of innovation:

1) Agile development encourages cross functional teams and direct, frequent communication with stakeholders. Cross-functional teams bring people with different professional and personal backgrounds together to agree on what problems need solving and consider multiple solutions from different vantage points.

2) Agile delivery encourages business and technology teams to run, think fast, and deliver efficient solutions. Updating the backlog with the most important stories takes a lot of work and lots of thinking. Thinking, cross-functional teams that are running tend to be more innovative.

3) Agile delivery encouraged a product team to deliver features to the market faster and encourages teams to capture and use customer feedback in prioritizing enhancements - #innovation = the art of making great leaps forward via incremental #agile deliveries.

4) If your software teams spend too much time fixing bugs and addressing defects, there's little time to work on innovative solutions. Agile teams tend to be disciplined on process and practice defect avoidance strategies like test driven development (TDD). The team is motivated to spend more time working on new products and enhancements where one can be innovative, rather than fixing bugs.

5) Developers find agile a fun process. Happy productive people tend to be more innovative.

Maturing agile development without a maturity model

As you saw from my last post, I’m fairly bearish when it comes to maturity models. In many cases, maturity models are just tools used by consultants and sales engineers selling expensive ‘how to’ guides to senior IT executives. But even discounting these out, maturity models are guides to help managers size up their current processes, identify gaps, and leverage ‘off the shelf’ processes to gain a new level of process maturity.

Sounds great. Here’s the issue with agile – Agile, implemented as a collection of processes will only get teams slightly more efficient. It will improve speed to market, improve productivity (by cutting put wasted efforts), and help address defects. Awesome right? Now going one step further:

Agile processes in its optimal sense needs to achieve a higher goal of organizational change, efficiency and innovation.

Ok, I know what you’re saying – get off the soap box. What do you mean? Let’s go into these goals briefly:

• Organizational change – Consider processes before and after agile development. The product backlog needs upstream mechanisms to set product strategy and vision, develop high level product requirements, conduct user experience testing, and set priorities. These and other concerns need to wrap a technology department’s partnering, development, integration, and deployment processes. All of these are affected by agile.
  

• Efficiency – Consider what tools and processes the IT organization needs to improve its productivity? Better bug tracking? Improved functional testing? Better gathering of technical requirements?

• Innovation – Innovation touches a broad set of concerns, so here’s how I would summarize: Are you researching, prototyping, and developing solutions in the most strategic areas of your product or service and leveraging the best talent you have available? Are you identifying talent deficiencies and considering options to invest in your resources or seek new resource opportunities when needed?

Ok, so how do you use mature agile, effect organizational change…?

Two simple answers:

1) Give your teams some leeway to self organize properly and build internal processes. Processes are never fully contained within a team’s structure and by influencing those in the periphery, a larger change can start to take shape. The team has to figure out and develop its processes.

2) Use your agile process to prioritize process creation and improvement. Recognize that process is always in a state of flux and improvement, so when improvements are needed or opportunities identified use an agile / SCRUM process to schedule, commit, and measure improvements.

Next post: SCRUM for Process Maturity

Agile Does Not Need A Maturity Model

This post, Does Agile Need Its Own Process Maturity Model caught my attention. Now there's nothing wrong with the article or some of the concepts, but I feel compelled to throw in my two cents on maturity models in general and especially applied to agile software development.

In general, I've only seen maturity models used in one way - to sell enterprise executives either software or services. They sell expertise in a simple one page diagram and essentially say, pay me to develop your process. As far as maturing practices or educating teams, these tools are usually useless.

Bottom line, if you want to mature a process then roll up the sleeves, learn your organization, recognize what process improvements are needed to meet business goals, set process goals and align your teams to improvement. This is especially true with agile practices since the choice of what processes to establish and areas to mature needs to fit a business need and priority and these improvements can be managed through the scrum process.

Now the evolution described is reasonable; (1) Core Agile Development (2) Disciplined Agile Deliver (3) Agility at Scale - but what is called "core", "disciplined" and at what "scale" is going to differ by organization.

Here's an example. I know one development team in an enterprise that's perfectly happy managing their backlog in a web accessible spreadsheet. Their team is in one location and they are largely working with independent development teams. They will be the first to admit that a spreadsheet is not sufficient, but it's good enough given their size, location, and process. Now one day they may have greater needs; they may have to make stories more verbose, or perhaps they need better story tagging or metrics capture. It's at that time they can write a story "Identify tool options for agile project management" with acceptance criteria based on their needs. This can be followed with additional stories "Develop POC with tool X" and later "Rollout tool X".

My advice: Keep it simple, and build process maturity (agile, software delivery...) into an agile process.