by: Thomas Meloche

Introduction

The Jeopardy Game In our training series we provide instruction on software development including using Use Cases and encouraging Iterative and Incremental Development. We firmly believe in these concepts, however, they have now been stated so often in software development circles that they risk becoming simply buzz words. People tend to read into them whatever they want to in order to justify how they are doing development. We have seen instances where Use Cases were written, but no benefit was ever obtained. The teams simply didn't understand how to apply them. We have also seen several processes that are incremental but not iterative. This is a step in the right direction, but many major benefits are lost.  

In order to test your knowledge of core development concepts, and to move that understanding beyond buzz words, we have created a little exercise called the Jeopardy Game. The purpose of the Jeopardy Game is to test your knowledge of core software development concepts and to see how they can be applied to real projects.  

In the Jeopardy Game you will hear a sentence or two that describes an actual project. No additional information will be provided. Based on the sentence, you have to state if the project is in jeopardy or not. If you think the project is on track for success, state why you think it is on track for success. If you think it is on track for failure, state why the project is in jeopardy and what is a possible corrective action.  

Hopefully, you will continue to play the Jeopardy Game on your own projects. Listen to statements made on your projects, observe what you are doing, and then decide if your project is in jeopardy. As in life, you will be responsible for keeping your own score. Let's begin.

 <<Jeopardy Music>>

USE CASES for $100,000

The Answer is: We implemented the most technically difficult Use Cases first in our very first increment. We did this in order to eliminate the riskiest elements first.

Question: (mark one) Is this action likely to contribute to the project's success _____or failure____?

USE CASES for $500,000

The Answer is: We spent the last year producing a 500 page analysis document with a complete set of Use-Cases. We've just started to code but there is nothing working that we can show you yet.

Question: (mark one) Is this action likely to contribute to the project's success _____or failure____?

USE CASES for $1,000,000

The Answer is: We identified through analysis and design our core Use Cases and used them to determine all of the modules we needed to create. We then entered the module names into Microsoft Project and assigned an engineer to develop each one. We then asked the engineers to estimate how long it would take to implement them. Based on these estimates, it was determined that the project would take 10 months to complete. The engineers then began work.

Question: (mark one) Is this action likely to contribute to the project's success _____or failure____?

STAFFING for $100,000

The Answer is: We have identified several key positions we need filled on our project including an analyst, architect, and project manager.

Question: (mark one) Is this realization likely to contribute to the project's success _____or failure____?

STAFFING for $500,000

The Answer is: We have a budget to add four more people to the team, so we plan to do so.

Question: (mark one) Is this decision likely to contribute to the project's success _____or failure____?

STAFFING for $1,000,000

The Answer is: We had thirty people working on the initial analysis and requirements - they met each day in a conference room.

Question: (mark one) Is this action likely to contribute to the project's success _____or failure____?

POTPOURRI for $100,000

The Answer is: We built a GUI mock-up of the application while we were doing analysis and design and took it out to several of our customer sites to get their feedback.

Question: (mark one) Is this action likely to contribute to the project's success _____or failure____?

POTPOURRI for $500,000

The Answer is: The functional testing team currently has nothing to do. So we added them to the GUI design team to help document the GUI.

Question: (mark one) Is this decision likely to contribute to the project&apo;s success _____or failure____?

POTPOURRI for $1,000,000

The Answer is: I attended the Menlo Institute training class on software project management and bought and studied all of the books recommended.

Question: (mark one) Is this action likely to contribute to the project's success _____or failure____?

The Questions

USE CASES for $100,000

The Answer is: We implemented the most technically difficult Use Cases first in our very first increment. We did this in order to eliminate the riskiest elements first.

What – is – Failure? Now, this is a bit controversial to many methodologists who give the opposite advice. Let me explain why I believe doing the most technically difficult Use Cases in the first iteration may put your project in jeopardy. I believe that the idea of eliminating risk early is a good one. But those who think the risk is in a difficult Use Case have probably not recently built a team. A good process should try to eliminate the risk early in the development process. However, the risks involved in producing an effective development team are more important than the "technically risky" Use Cases. In my projects where a new team is being asked to work with new technology, which is almost every project, I try to have the initial increment be quick and clearly successful. It is important to demonstrate a working process to the team. The team must congeal and learn to work together. If possible, I always do a few of the technically easiest Use Cases in the first incremental release and make my first incremental release short. Once the team is working as a team (usually in just two weeks), then I will assign the team to do the technically higher risk use cases.

USE CASES for $500,000 The answer is: We spent the last year producing a 500 page analysis document with a complete set of Use-Cases. We've just started to develop software but have nothing working that we can show you yet.

What -- is – Failure? Now, why would this statement leave one to believe that the project is in jeopardy? They are using Use Cases after all; they must be doing a good thing right? Unfortunately, no. First off, they are clearly not using an incremental and iterative process. Although there are a few exceptions, most any project you are involved in should never spend a year in analysis without several complete incremental releases and complete iterations. We cover several reasons why this is true in our Secrets of Software Success class and probably the most important reason is requirements drift. Analysis that is a year old that has never been expressed in a working software system is a very old analysis; requirements change, technology changes, competitive markets change. All of which will make this year-long analysis effort quickly obsolete.

The project, in fact that inspired this "answer," experienced the following situation. The company that was responsible for the project acquired a new department. This event changed many of the fundamental analysis assumptions. The year long analysis effort was completely abandoned. The project never delivered a working software system, although it did produce a nicely bound document that no one ever read.

USE CASES for $1,000,000

The Answer is: We identified through analysis and design our core Use Cases and used them to determine all of the modules we needed to create. We then entered the module names into Microsoft Project and assigned an engineer to develop each module. We then asked the engineers to estimate how long it would take to implement them. Based on these estimates, it was determined that the project would take 10 months to complete. The engineers then began work.

What -- is -- Failure? This is a common problem. Unfortunately it is a million dollar question. Use Cases are often correctly used to drive analysis and design and are then abandoned when it comes to implementation. Use Cases should drive the entire development process, including implementation. A project should be implemented by Use Cases. Use Cases should be assigned to developers not classes, functions or modules. The developers should create functionality, one Use Case at a time. After a Use Case is completed the code is tested and integrated. Then coding on the next Use Case can begin. This is how Use Cases should be used to drive implementation. Of course Use Cases can also be worked on in parallel in order to hasten development.

A project may still be successful even if Use Cases are not employed but the project will probably run into extensive problems during code integration. This is because developers who create subsystems and classes in isolation will not usually see how their effort relates to end user needs. If programmers are focused on developing isolated modules and classes instead of Use Cases they will probably not see any meaning output until after the code developed by others is integrated with their own. This may not occur for days or even weeks. And when it does, dozens of new bugs and incompatibilities are usually discovered. Employing Use Cases helps eliminate many of the negative aspects of code integration.

STAFFING for $100,000

The Answer is: We have identified several key positions we need filled on our project including an analyst, architect, and project manager.

What – is – Success? This answer gets a success rating because they understood enough to recognize that analyst, architect and project manager are, in fact, different roles. It is important to recognize the need for an analyst and an architect. Analysts are used to help understand the core business requirements and create the Use Case and business models. Architects help create the design model and create the framework for implementation. Both roles are important and for the project to be successful should be filled by people who have been specifically trained in analysis and software architecture. 

STAFFING for $500,000

The Answer is: We have a budget to add four more people to the team, so we plan to do so.

What – is – Failure? It is a good idea to never ask consultants this question. They will always feel compelled to answer "yes," because of the desire to increase the number of billable hours. As a consultant I feel compelled to point out that this is a misleading question or in this case "answer." What should be asked is, should I add any more staff to the team, and if so, what types of skills do we need? Never add programmers for the sake of adding programmers. On most of the projects I have witnessed there are too many programmers. A large team usually slows the project down. If you do have the budget to add more people, consider adding non-programmers as well as programmers to the team. A well balanced team should include hardware engineers, usability specialists, network engineers, writers, testers and project managers, just to name a few. All should be working to support the development team. Work to build well-balanced teams. 

STAFFING for $1,000,000

The Answer is: We had thirty people working on the initial analysis and requirements - they met each day in a conference room.

What – is – Failure? I once met several of the people who underwent this particular form of torture. They met most of the day in a conference room to discuss a really big project they were to develop. This analysis went on for the better part of a year. By the time I met some of the participants, the project had already been abandoned. They had found it too difficult to capture the requirements. This is no surprise. I suggested to the team members that if they ever found themselves in that situation again they should pick 4 of the 30 people to capture the requirements. The four should be solely responsible for the capture and recording of the core Use Cases. The other 26 should be sent on an exploratory tour of the Bahamas. They can be brought back one at a time as requested by the core team to provide their particular expertise. The rest of the time they should enjoy the beach. More useful work will actually get done this way, and everyone will enjoy work more.

POTPOURRI for $100,000

The Answer is: We built a GUI mock-up of the application while we were doing analysis and design and took it out to several of our customer sites to get their feedback.

What – is – Success? From the customers point of view, the graphical user interface is usually the most critical aspect of the application. It is always a good idea to take early mock-ups to the customers in order to obtain feedback. It's important to test and retest interface, always with new people to see how they respond. Is the interface easy to understand? Are the primary Use Cases that represent tasks that people will do everyday simple to use?

In one project that I recall, the group that was building the GUI mock-up, or prototype, was actually building the second-generation version of a medical imaging system. They did not assume that the first generation system was built correctly but instead went directly to the user community. They watched how the users worked. They observed how users attempted to use the new interface. They asked the users what they felt they needed in the software to better do their jobs. In this process, which actually occurred in an iterative manner over several months, the development team visited over nine different user sites with multiple prototypes. They talked directly with at least 20 different users, listened to their feedback, and sought to incorporate it into the next product. When the application was finally released the user response was overwhelming – they loved it – one user said it was the first time anyone had actually designed a system for them. Not only were the users delighted, Marketing and Sales bragged that they could demonstrate the system right out of the box without having to read manuals or practice operating it for long periods of time. They also loved comparing their new system to the cumbersome software offered by their competition. Everyone benefits when a system is designed that is easy to use and intuitive; a system that is designed with extensive user feedback.  

POTPOURRI for $500,000

The Answer is: The functional testing team currently has nothing to do. So we added them to the GUI design team to help document the GUI.

What – is – Failure? There are several reasons that this statement is likely to result in failure. First, the functional testing team should always have something to do. The fact that they have nothing to do is highly suspect. Is all the equipment in place and up to date? Have they created a test plan that encompasses all of the Use Cases? Have they automated this test plan? Do they understand the product they are testing or can they learn more about its functions? How quickly can they run the entire functional test suite? Are there ways that the test suite can be automated to make the functional testing go faster? Is the functional test team trained on testing practices? Are there courses available that they could take to update their skills? Have they ever formally studied testing? All of these questions and more should be asked before the functional test team is reassigned from testing assignments. I have never met a test team that didn't have more work they could do to improve testing. Be careful if they ever say that they have nothing to do. Something is probably seriously wrong.

In a particular example I recall, an extremely skilled and experienced team was in the process of creating a revolutionary new graphical user interface. They had received an extensive amount of feedback from the user community and were nearly completed with the design. A manager decided that the testing team didn't have enough to do and assigned them to work with the design team. The design team was then slowed down considerably since they had to explain and defend their decisions to the folks from the testing team. Simply adding people to a team may actually hinder progress. I figure that in this case, this decision probably cost the corporation about $500,000 in lost productivity.

POTPOURRI for $1,000,000

The Answer is: I attended the Menlo Institute training class on software project management and bought and studied all of the books recommended.

What – is – Success? This answer, I think, is a little self-serving but correct. I should point out though that the keyword here is studied. Developing software is one of the more complex activities that one can undertake. It is important to recognize that it is not something learned once in college then never studied again. The best project managers analysts, architects and software developers that I know make the process, practices and techniques of software development a life long study.

Best of luck keeping your projects out of jeopardy!