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.

Amazon Cloud - Becoming a Storm?

When Amazon Web Services came out with S3 and EC2, I was skeptical even though I was and continue to be a strong proponent of SaaS. Why would I buy hosting from a large internet retailer when there are so many companies offering inexpensive hosting models?

One year later, I began using S3 via JungleDisk at home as a way to backup my hundreds of gigabytes of photos.

Then a couple of weeks ago, I saw a very compelling demo of Mark Logic, "a provider of infrastructure software for information-centric applications" (re: funding announcement) running on EC2. It was very compelling to see a new product built on their platform and deployed to EC2 in under 30 minutes.

So I went back and took another look at EC2 and specifically the EC2 Operating System and Software or in their language, "off the shelf" Amazon Machine Images. In a nutshell, some of the standard web platforms can be purchased and installed as images. Want Windows, ASP.Net, MS SQL - check, they have it. J2EE on MySQL - check they have that too. Oracle DB, DB2 - yup these are available.

As a Startup CTO, it was pretty easy to get hosting solved. Call one of a dozen hosting vendors, select hardware line, OS, number of systems, purchase via credit card, wait 24 hours or less, get root/admin access to your server farm, spend time installing your applications, figure out how to scale the application later.

Possibly today's version: All the steps above except (a) replace hosting vendor w/ Amazon, (b) get the software infrastructure (web platform and db) largely configured on purchase, (c) probably spend even less money on hosting, and (d) leverage Amazon services to scale.

Bottom line: If you aren't looking at the cloud, better start and get caught up quickly. For me, work in progress.

Good references:

• Business Exchange Cloud Computing topic
• 10 Things You Don't Need to do In The Cloud
  

Retaining and Growing Readers on Newspaper Web and Mobile Sites

I am from one of the last generations of ritual NY Times Sunday edition readers. I have fond memories of taking the tree with me to parks and beaches during the summertime to read the magazine and many of the other sections. I even found my first out of college jobs from a help wanted ad in the Times that my wife (then girlfriend) mailed to me while finishing grad school at the University of Arizona.

Flash many years later, and how do I read the Times?

Several years ago I became a web only reader but never signed up for Times Select despite missing my weekly dose of Thomas Friedman. When I got a blackberry, I became largely a mobile user and read most of the articles I wanted during my commute. Sometimes, I feel like I'm missing something when reading the mobile dining section while catching a glimpse of the full color print edition that the person next to me is browsing, but it still doesn't compel me to buy a copy.

And now of course there's my Twitter stream. I get most of the NYT articles that I would want to read from the NYT Business Twitter feed plus tweets from friends. So I don't visit the NYT mobile every day now. Now, even when the NYT finds a way to monetize mobile, my engagement will be limited to the articles I read with little opportunity to present related content or social experiences that would drive higher engagement.

Such is the difficulty of the traditional and newspaper publisher who is trying to retain subscriptions, increase digital readers, and increase engagement. It's a hard problem. News sites have to get very strong at working web analytics, understanding how to reach new audiences, and essentially targeting some of their writing based on audience needs. I will continue to read the NYT, they will just have to work harder to get my attention.

Business Responsibilities working with Agile Teams Part 2

See Business Responsibilities working with Agile Teams Part 1 where I cover some important responsibilities: Dedicating time to define requirements, setting reasonable customer expectations, and developing a methodology for prioritizing.

The list below is a bit more tactical and technical:

1) Learn the lingo and the process - Don't look at agile as a 'tech process'. When I discuss agile to business executives, I explain that when tech teams are successful adopting agile, it creates significant organizational change at the business level. One good way to insure a smooth transition is to learn the process either through participation, taking a training class, and ideally applying agile/SCRUM as a business process. This white paper, Agile Terminology Explained is a good quick read.

2) Avoid the need to add/change stories inside the iteration - which can be very disruptive to the team. Agile teams work in rhythms. At the beginning of the iteration, they are in thinking/planning mode. During the iteration, they are focused on stories and coding and at the end of the iteration they are closing out defects. Changes midstream create an imbalance. Now most teams are flexible (being agile) and will accept changes/additions, but this should be managed as an exception, not the norm.

3) Come to demos - Demos are when the team showcases the work of the iteration. The team goes through story by story and demonstrates the functionality. If business representatives or stakeholders do not attend regularly, they miss the opportunity to provide valuable feedback on the finished product. It also demoralizes the team. It doesn't mean that you have to attend every demo - I certainly have missed my share (sorry guys) - but attendance is key to a successful agile practice.

4) Help define acceptance criteria - Agile stories are most successful when the story is a deliverable or unit of result. The team will come up with technical criteria for acceptance, but these criteria have more meaning when they qualify a real business need.

5) Prioritize tech needs too! - Successful agile practices need to appropriate time to implement tech concerns. R&D efforts, managing support issues, addressing technical debt (when messy code needs to be fixed), documentation concerns, training...

More on agile? Great articles posted at the Business Exchange Agile Software Development topic.