Rod Claar

You might be thinking that my title would get a response from Homer Simpson (Doh!), but too many teams try to do Scrum or Agile in a rigid and prescriptive way.  There are a couple of main reasons that I see this. The first is the desire for new teams to “do” Scrum right when they are new to Scrum.  I resemble that feeling!  On my first Scrum project (several years ago) I defended the process against change rather than being open to process change.  Oh well, we all have to learn somehow!

Change for the sake of change is not a good thing.  Any process change should be driven from retrospective discussions and the desire to reduce or eliminate impediments.  What is holding your team and product back?  What was the root cause of the problems you encountered?  The team should discuss these issues and pick one or two top issues and agree to work on them and try to find solutions to them.  If that means changing Scrum, then CHANGE SCRUM!

The other major cause I see of process rigidity is on teams and projects that are large and complex enough to require an electronic system for tracking work items, making distributed team communication easy to find and use and reporting out status and progress.  There are a lot of tools out there and any tool, used to drive the team and project, can strip agility from your organization.  However nearly all teams have some distributed component and we all know that the last simple project was done in 1959!  This means that almost all teams and project need a system to help manage the project.

I’m a white board and sticky type of agilest.   Give me a team room with white boards and a bunch of multicolored stickys and I’m a happy camper!  Why? Because I know that the white board and stickys are NOT the project, the people and the conversations they have with each other are the project and the white boards and stickys are used to drive those conversations and track the work.

However for most teams and most organizations, my agile dream project just does not exist and trying to force it to be is foolishness.  Most organizations are going to need a tool.

What makes a good Scrum / Agile tool?

1) It must not have a fixed process flow.  The team must be able to tweak the process to fit their culture and organization.

2) It must be simple enough to enable not get in the way.  The team must drive the project rather than the tool.

3) It must produce status and progress reports that are customizable and accessible to the business.  Feedback is the process that keeps Scrum / Agile on
track in a world of changing priorities.  Having status and progress reports that truly inform the stakeholders and project sponsors of where the project is drives the prioritization process to meet business needs.

4) The process must have a business value driven approach.  In other words the project management tool must drive business value and make business value delivery clear to the team and stakeholders.  If a tool is a bottom-up project management tool, the team is building the trees at such a high rate of speed that the forest of business value is totally obscured.

How the team uses the tool and how the tool allows the team to focus on delivering business value is the main critical issue.  A tool must be flexible.

This week Daptiv released Daptiv Scrum that can be used in conjunction with their popular Daptiv PPM product.  These tools allow companies to manage and track all their work in one centrally visible source.  This allows the business to see the benefits of an agile process.  After configuring the system to match the process at the organization the team and management can be comfortable knowing that the team is driving the product rather than the tool.  Along with the standard Scrum roles of Product Owner and Scrum Master you can create custom roles to meet your need for engineering leadership, release management, configuration management and other custom role.

One of the biggest advantages of Daptiv Scrum is the ability to easily manage a story driven product backlog.  Priority changes are done via drag and drop right in the product backlog.

Daptiv Scrum also gives you the reporting artifacts you need to manage the scrum process: Sprint Burndown, Release Burndown, Sprint Summary including calculated velocity, Sprint Tracking, and Features by Product Category. They’re all here.

However one of the best advantages is the ease of setup and maintenance.  Built on a web model, Daptiv delivers automatic updates via the web which frees your team from updates and configuration issues.  This ISO 27001 Certified organization provides your team with the security, redundancy, uptime, maintenance and new features so your organization can focus on delivering business value.

For more information about Daptiv Scrum see their web site at <a href=”Daptiv.comhttp://www.daptiv.com/solutions/daptiv_scrum/index.htm”>Daptiv.com</a> See the press release at <a href=”http://www.marketwire.com/press-release/Daptiv-Inc-1001235.htmlhttp://www.marketwire.com/press-release/Daptiv-Inc-1001235.html”>http://www.marketwire.com/press-release/Daptiv-Inc-1001235.html</a> .

Oh! I almost forgot!  Play the <a href=”http://www.daptiv.com/escape/index.htm” target=”_blank”>Escape from Scrum Island</a> game!

I’ve been helping a pretty large team for a few months now.  Today I attended a user group meeting today on SecondLife delivered by Brian Harry of VSTS/TFS.  It is very clear that there are some issues that get exacerbated when you have a very large project.  

The first one that comes to mind for me is the formation of teams.  It seems that while some organizations are moving to cross-functional teams to some degree, the silos of discipline management still exist and tend to get in the way.   Brian Harry talked about the “Feature Crew” at Visual Studio.  These teams are cross functional but are created for specific feature sets.  These teams have specific goals and tend to be disbanded when the set of features are complete.  The team members often have multiple assignments simultaneously.  I’ll have to say that this is a step in the right direction in that the system and business capabilities are grouped with a team to deliver them.  This tends to help with the coordination of work between teams.  However the fact that they do not let the teams work together over an extended period means there is a lot of forming and learning about the team that is overhead.  

One of the other problems is the tracking and processing of bugs.  Because of the integration issues and the use of branching techniques to give the teams a relatively stable platform to work on, there are lots of bugs created and significant effort has to be put into managing and tracking them.  If you have a project with thousands of active bugs, you have a very big problem. 

However the biggest issue I’m seeing is the lack of visibility of the delivery of business value.  Huge projects are generally managed by feature delivery and bug rates and counts.  Most of this comes from the coordination of the work on the teams and the poor communication of vision down to the scrum team level.  This results in the scrum or feature teams doing massive amounts of interpretation on the requirements and the result is a bloated codebase with excessive complexity and enormous testing and integration issues.  Without a clear top-down expression of the vision for the product and the release the feature teams are virtually free to dump on the product.

All of these problems lead to release plan accuracy issues.  The traditional way this happens is slipping the ship date.  However the more dangerous risk is not delivering what the user needs.  How do we reduce the impact of these issues?

Firstly we should NEVER slip a ship date.  Our customers, users, clients need what we are building, otherwise they would not be paying for it.  They get no value out of software that they can’t use.

Secondly we MUST adopt a business value driven approach to managing the work and the teams.  This means that product and project management have to change.  Traditionally either the specifications/requirements are either so massive as to not be understandable or so limited they are little more than hand waving. 

To accomplish these two goals we have to prioritize the business value and constantly react to what the team is delivering.   The scope of the release WILL change, but if we have prioritized based on relative cost and relative business value we can deliver the important features on time.

This takes metrics and project status reporting. Brian Harry said that metrics should be about making you ask questions.  I could not agree more.  However the most important question should be about the progress toward delivering high priority business value.  If the teams were organized around business value items and the bugs were categorized by business value area then we could stop working on bugs that don’t impact the release plan.  We could also concentrate more on the quality of the code with the basic principles of cohesion, low coupling, testability and clarity.

It does not matter what tools you are using, the focus should be on the delivery of business value.  Track stories, bugs and scenarios in an appropriate way for your team, but concentrate, reward and deliver business value early in a way that will allow you to deliver business value quickly in the future.