Enterprise Services
Showing results for 
Search instead for 
Do you mean 

The WISCA Redux

‎08-12-2014 06:06 AM - edited ‎09-30-2015 07:06 AM

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


Author’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.


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:


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



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.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. 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 lives in Toronto, Canada.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all