We IT folks get no respect from the business world. And I’m mad as heck and I’m not gonna take it anymore! No more snide remarks from finance; no more insults from operations; no more blank stares and shoulder shrugging from the sales guys.

What am I doing to end this intolerable state of affairs? My colleagues and I are training people in the application of an awesome and agile combination of business strategy and system development tactics; we call it the “30-Day Blitz”. We’re seeing business people smile and say “Wow” when they experience the results. We’re also seeing a can-do attitude and what the French so beautifully call “esprit de corps” emerging in the IT development teams doing the blitzes.

In early May we began a 30-Day Blitz with the systems development group of a global electronics and software company. It started with a two-day agility workshop involving the business and IT stakeholders. In interactive exercises, we defined the business challenge and sketched out ideas for quickly addressing the most pressing issues. The IT director who is guiding the introduction of the blitz into his company culture accurately describes this as a “Socratic process of exploring options and testing assumptions.”

We agreed on the scope for the first blitz and created a conceptual design and performance requirements for a version 1.0 system – a “robust 80% solution” that the developers could deliver in 30 days or less (that’s 30 calendar days; and we don’t work weekends so its 20-22 working days).

The following seven days were spent employing the six core techniques to flesh out the details involved in the design of the conceptual system created in the two-day workshop. During that time we did a couple of half-day JAD sessions where business and IT people worked out specific design issues. In between JAD sessions, business people went back to their regular jobs but were available for quick meetings and questions. The development team investigated and worked out solutions to all the technical issues related to the system design.

System design was captured in a set of largely graphic specification documents: process flow diagrams; data models; a story board of user interface screens; and system architecture diagrams showing configuration of hardware and software. We wrote up a definition of the relevant business rules and processing logic but dispensed with lengthy and elaborate use cases and loads of written text specifications.

The graphic format of our design specs communicated well to the business users. They took one last look at the system design and gave us their thumbs up to go into the build phase.

The build phase is the “peddle to the metal” phase where the development team focuses their attention and energy like a laser; they had 11 days to turn the system design into a working system. We started this phase with the whole team reviewing the design specs and producing a detailed list of development tasks, no task lasting longer than three days. Then we organized these tasks into a day by day project plan and assigned people to each task.

Every morning we started the day with a short session where we reviewed and updated the project plan to assess progress made, identify problems, and constantly adjust our actions so as respond effectively and get the system built by our delivery date of June 1. We had our, “Oh no! What do we do now?” moments; what project doesn’t? The system builder leading the team was

You do not have flash or javascript support.

Average (6 votes)

Reply