Increasing Business and Technology Throughput

  I came across Twitter in a discussion on LinkedIn a few months ago and recently wrote a blog entry on how it might support agile software development practices. However, I've only recently had a chance to explore its actual effect on a project.

I'm currently the project manager for a global, content management implementation and I've been working with a colleague, Raul Pavon, on how to effectively communicate/colloborate with a team of developers and subject matter experts scattered across the globe and in almost every timezone.

One requirement for this project from the executive sponsor was ensuring high degrees of visibility into project progress. We're applying a number of agile principles to support this goal but we were struggling on how best to 'scrum' on the goals we're trying to accomplish during each sprint. The challenge is that many of the team members are more than 8 hours out of alignment in terms of working hours, which made it logistically difficult to get everyone together at the same time. It occurred to me that Twitter might be a useful mechanism to understand what team members were working on and any roadblocks/issues they had encountered. I shared this idea with Raul who rapidly embraced it and we began to explore how to best leverage the tool.

One aspect Raul immediately identified was that this moved the daily scrum process into a highly collaborative, real-time model that freed itself of the contraint of gathering a team together every 24 hours to update on progress. Using Twitter, the same scrum updates are being provided without the artificial delay of getting people together in a room and it's also much easier to extend this to a global context. Raul, who is about to get his Black Belt in 6 Sigma coined the term "Lean Scrumming" for what we were doing. We also discussed how this technique might also support a 'swarm' theory where the project team begins to form an collective awareness of group progress and adapts to priorities and obstacles by responding together (similar to a swarm of bees or school of fish moving in tight formation but in a fluid and adaptive direction).

It's early in our experience with this technique but we wanted to share some initial experiences and see if we can harness perspectives/comments from other members of the community. Some suggestions on what we've learned so far:

• Setup: Twitter itself took a few attempts to setup. It's a good practice to have someone guide each team member on how to configure their cell phone to receive the Twitter text messages. You also need to make sure each member has an SMS enabled phone (I doubt you can even buy phones without that feature these days) and a Text Messaging plan.
• Establish guidelines on what to send as an update. We're focusing on only project related tasks (we decided that knowing when someone goes to lunch or for a coffee wasn't that important) and issues/problems. This is a bit different from the social interaction aspect of these tools.
• Update regularly, every 2-4 hours is useful to keep an active pulse to the project.

Some things we wish Twitter had:

• More integration with task lists/project management tools. It would be nice if a team member could simply highlight a task in their Outlook task list and it would send a Twitter update.
• Contact groups. Currently you need to manually add someone in order to follow them, having a list so you can filter the types of messages would be useful.
• Intranet application. A version that ran inside a corporate firewall and authenticated to a corporate directory would be a big plus for wider corporate usage.

We'll keep more posts coming on our experience and feel free to share comments and perspectives.

Posted by Bryan Campbell at 12:30 PM | Permalink | TrackBacks (0)

One of the biggest challenges of Agile development is introducing its ideas and techniques beyond the project team using them.  Project teams tpically see direct, and often immediate, benefits of using agile techniques but for those outside of the project it takes the right leadership and direction to enable agile adoption across the enterprise.

 

Recently a colleague and mentor at BMC Software, Israel Gat, was interviewed for Agile Thinkers regarding his experience in introducing agile techniques at BMC Software. It's an interesting article and provides a good overview of the 'success criteria' required to introduce agile approaches across a large organization. This is one of the more challenging aspects of managing agile projects since oftentimes there are other groups and stakeholders that don't have the same understanding or experiences with agile techniques. Without an effective organizational champion it can be difficult to extend agile beyond the project level which saps it of its real benefits which can be applied across an organizational's entire value chain. The Agile Thinkers blog collects first hand experiences from leaders who have been at the forefront of introducing agile techniques across their organizations. These experiences are invaluable in culling ideas on how to approach the common problems that often confront culture and organizational change.

However, what particularly impressed me by the Agile Thinkers blog is it also draws upon agile thinkers that in my opinion see the next progression in agile development (a topic I covered on my personal blog called Post Agilism). Authors and thinkers like Alistair Cockburn, Tom Glib and the Poppendiecks, all see agile as focusing on 'business value' and emphasizing discipline and measurement to drive continuous improvements. All of these authors bring some refreshing pragmatism to agile development particularly those of us involved in managing these kinds of initiatives.

Posted by Bryan Campbell at 08:18 AM | Permalink | TrackBacks (0)

There is really no limit to the number of ways to create and customize an System Development LifeCycle and to some degree every organization and, to some degree, every project needs its own flavor of an SDLC.  However, every SDLC should address the following ABCs:

A - Adapt the Process:  One size doesn't fit all, IT projects come in many shapes and sizes and its important to adapt the SDLC process to reflect the project's needs.  This not only includes ensuring roles, activities and artifacts are adapted but even iteration length and communication strategies.

B - Balance Stakeholder's Priorities:  Projects always have more than one stakeholder, the first stakeholder that springs to mind is the business sponsor but IT is often a stakeholder as it attempts to ensure that the project aligns with standards and architecture goals, Accounting is a stakeholder as it measures the costs and presumably the benefits associated with a project, there could be Regulatory stakeholders who need to ensure that specific rules are adhered to.  Identify these stakeholders and ensure that their priorities are understood and balanced across the project.

C - Collaboration Across Teams:  One of the biggest failings of many projects is that teams don't work together, they simply create work products and 'hand them over the wall' to their counterparts.  Foster collaboration through shared goals/objectives, facilitated meetings, tooling and where possible colocation. 

D - Demonstrate Value Iteratively:  Rapid feedback is one of the most important ways to ensure that your project will deliver what its stakeholders need.  Emphasize 'value' by showing working software over documents and meetings as quickly as possible.

E - Elevate the Level of Abstraction:  Often times projects get bogged down in the minutiae of data tables, interfaces and technical design.  Understanding the goals of the project and abstracting to different levels of detail will not only make the project more manageable but go a long way to ensuring buy-in and increasing communication.

Using these ABCs as principles to guide your SDLC can go a long way to increasing its adoption and improving its effectiveness as well as allowing you to accomplish the next step in sequence F - Fantastic!

Posted by Bryan Campbell at 01:51 PM | Permalink | TrackBacks (0)