Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Focus on Fundamentals (#26) – The WISCA Redux

bullet.jpgBy: James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company

 

Author’s note: The Focus on Fundamentals blog series addresses the challenges that limit applications solution delivery success.

 

When I began working in software development over 35 years ago (it’s hard to believe!), we used to refer to the WISCA Phenomenon which we often encountered on our projects. In this context, WISCA doesn’t mean the Washington Interscholastic Swim Coaches Association or the Wisconsin Society of Certified Acupuncturists, it means “Why isn’t Sam/Sally coding already?” It was shorthand for saying that stakeholders were complaining about the amount of time it was taking to specify requirements for an application under development or that the developers had fallen into the trap of coding software before they had a clear understanding of what was required by end users.

 

I believe the WISCA Phenomenon is just as prevalent today. However, now it is appearing under the rush to apply Agile Scrum processes to every project, without a clear understanding of what factors make a successful agile project. For many stakeholder executives, ‘agile’ has become the latest silver bullet that they hope will slay the applications development monster.

 

I certainly do not want to be misunderstood, the Agile Scrum process has an important place in software development, but in many cases the drive to apply the agile process has been for the wrong reasons and it is being applied to the wrong types of projects.

 

Agile is often viewed as the corrective action for in-progress development projects because the projects are being managed poorly and are plagued by problems such as:

  • Project scope is poorly defined or non-existent—stakeholders (both from the user community and the project team) do not have a clear, common understanding of what the application must do; i.e., they do not have a well-defined prioritized scope.
  • Project Managers do not manage issues—they do not ensure that open issues are tamed, but let them run wild until they cause significant delays or cost overruns. Also, risks are not mitigated with clear plans and ownership, resulting in an increased number of issues.
  • Processes are applied haphazardly—well-proven best-practice processes (e.g., test-driven development, peer review, continuous builds, or end-to-end artifact traceability) are jettisoned because they are perceived not to add value or take too long to accomplish, or are applied by rote without practical common sense.
  • Business Analysts take too long to write requirements—they do not know how to create abstractions which communicate clearly and precisely; instead they specify too much detail, particularly how (i.e., design) the system should work rather than what it must do.
  • Software is not developed iteratively—releases are monolithic with delivery times on a scale of years, rather than monthly or quarterly.
  • Software development teams fall prey to Parkinson’s Law (i.e., work expands to fill time available). They generally have no sense of urgency to complete their work, particularly if they are concerned about finding another assignment after their current one ends.

 

Software development project teams are their own worst enemies because they do not think clearly about their mission—which is to produce quality software as rapidly as possible.

 

In response to these failings, stakeholder executives believe that they can cut costs and have systems developed faster if they just switch their projects to agile. However, it is clear that they often do not understand the Agile Manifesto and Principles. For example, you will often hear comments such as:

  • There are no Business Analysts in Agile Scrum. The generic, default Agile Scrum framework does not include a formal role for a Business Analyst (BA). However, it also does not include formal project manager, architect, developer, tester, or trainer roles. It identifies only a generic ‘scrum team’ role which includes the activities performed by these specialized roles. However, Agile Scrum teams continue to manage work, conduct analysis activities, design and code software, manage configuration items, and test the emerging application. Each Scrum team needs ‘generalist-specialists’ who can do analysis work, write code, test software, and manage work assignments.
  • There is no documentation in Agile. The Agile Manifesto states as a goal: “working software over comprehensive documentation”. This does not mean that teams will not produce documentation. They will produce only what is needed, when it is needed.
  • Agile means “no design”. Projects applying agile techniques need at least as much, and probably more design and planning than some other types of projects to ensure that each added feature fits into the functional and technical architecture and to minimize refactoring.

 

An agile project can be plagued by the same issues as are often seen in other types of projects. Applying the Agile Scrum process is not a cure for poorly managed client relationships. It is not an idiot-proof process for building application software. And, success on agile projects sometimes depends on heroes as much as in other projects. Unfortunately, many of the folks rushing to apply the Agile Scrum process don’t know what they don’t know.

 

The Agile Scrum process can be applied successfully in many different contexts, but it must be applied after proper due diligence. Much has been written on the pros and cons of applying agile techniques, how best to apply them, and on what types of projects to apply them.

 

For reference, consider the following blog entries written by agile coaches at HP:

 

 

Previous Focus on Fundamental blogs by Jim Hughes:

 

Previous blogs in the Producing Quality Software series by Jim Hughes

 

Other blogs by Jim Hughes:

 

Jim-150X210.jpgAbout the Author

 

James (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Ana...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.