Improving Efficiency in Knowledge Work: SDLC Vs Agile

As you have seen, agile methods are developed quickly; they reportedly work; and users are customers who are directly involved. While it is true that projects developed by agile methods often require tweaking to work properly, agile developers admit that tweaking is part of the process. The agile approach implies many short releases with features added along the way.

Researchers (Davis & Naumann, 1999) developed a list of seven strategies that can improve the efficiency of knowledge work: reducing interface time and errors; reducing process learning time and dual processing losses; reducing time and effort to structure tasks and format outputs; reducing nonproductive expansion of work; reducing data and knowledge search and storage time and costs; reducing communication and coordination time and costs; and reducing losses from human information overload. They believe this is important, since based on their study of a group of programmers, they claim that the best programmers are five to ten times more productive than the worst ones. They further point out this ratio is only two to one for workers in clerical or physical tasks. Their suggestion is that software can help improve many situations.

We use the standard, traditional systems development approach of structured methods to compare and contrast how structured approaches versus agile methods would implement the seven strategies proposed to improve the efficiency of knowledge workers.

While adopting more software may indeed improve performance, it is reasonable to suggest that changing an approach or methodology may also improve performance. Consequently, we will examine each aspect of knowledge work productivity through lenses from both structured and agile methodologies. Table illustrated below lists the original seven strategies for productivity improvement and then explains what methods are used to improve the efficiency of systems development for both structured and agile methodologies.

Strategies for Improving Efficiency in Knowledge Work	Implementation Using Structured Methodologies	Implementation Using Agile Methodologies
Reduce interface time and errors	Adopting organizational standards for coding, naming, etc.; using forms	Adopting pair programming
Reduce process learning time and dual processing losses	Managing when updates are released so the user does not have to learn and use software at the same time	Ad hoc prototyping and rapid development
Reduce time and effort to structure tasks and format outputs	Using CASE tools and diagrams; using code written by other programmers	Encouraging short releases
Reduce nonproductive expansion of work	Project management; establishing deadlines	Limiting scope in each release
Reduce data and knowledge search and storage time and costs	Using structured data gathering techniques, such as interviews, observation, sampling	Allowing for an onsite customer
Reduce communication and coordination time and costs	Separating projects into smaller tasks; establishing barriers	Timeboxing
Reduce losses from human information overload	Applying filtering techniques to shield analysts and programmers	Sticking to a 40-hour workweek

In the upcoming sections we will compare and contrast structured approaches with the agile approach. An overarching observation about the agile methodology is that it is a human-oriented approach that permits people to create nuanced solutions that are impossible to create through formal specifications of process.

Reducing The Interface Time and Errors

Systems analysts and programmers need to analyze, design, and develop systems using knowledge work tools that range from Microsoft Office to sophisticated and costly CASE tools. They also need to document as they develop systems. It is important that analysts and programmers are capable of understanding the interface they use. They need to know how to classify, code, store, and write about the data they gather. Systems developers also need to quickly access a program, enter the required information, and retrieve it when it is needed again.

Structured approaches encourage adopting standards for everything. Rules set forth include items such as, “Everyone must use Microsoft Word rather than Word Perfect.” They may be more detailed instructions to ensure clean data such as, “Always use M for Male and F for Female,” thereby ensuring that analysts do not unthinkingly choose codes of their own, such as 0 for Male and 1 for Female. These rules then become part of the data repository. Forms are also useful, requiring all personnel to document their procedures so that another programmer might be able to take over if necessary.

In an agile approach, forms and procedures work well too, but another element is added. The additional practice of pair programming assures that one programmer will check the work of another, thereby reducing the number of errors. Pair programming means that ownership of the design or software itself is shared as in a partnership. Both partners (typically one a programmer, often a senior one) will say they chose a programming partner who desired to have a quality product that is error-free. Since two people work on the same design and code, interface time is not an issue; it is an integral part of the process. The authors have noted that programmers are quite emotional when the topic of pair programming is broached.

Reducing the Process Learning Time and Dual Processing Losses

Analysts and programmers learn specific techniques and software languages required for the completion of a current project. Inefficiencies often result when some analysts and programmers already know the products used while others still need to learn them. Typically, we ask that developers learn these products at the same time they are using them to build the system. This on-the-job training slows down the entire systems development project considerably.

A traditional, structured project requires more learning. If CASE tools were used, an analyst may need to learn the proprietary CASE tools used in the organization. The same applies to the use of a specific computer language. Documentation is also a concern.

Using an agile philosophy, the ability to launch projects without using CASE tools and detailed documentation allows the analysts and programmers to spend most of their time on system development rather than on learning specific tools.

Reducing the Time and Effort to Structure Tasks and Format Outputs

Whenever a project is started, a developer needs to determine the boundaries. In other words, the developers need to know what the deliverable will be and how they will go about organizing the project so they can complete all the necessary tasks.

A traditional approach would include using CASE tools, drawing diagrams (such as E-R diagrams and data flow diagrams), using project management software (such as Microsoft Project), writing detailed job descriptions, using and reusing forms and templates, and reusing code written by other programmers.

Systems development using an agile approach addresses the need to structure tasks by scheduling short releases. The agile philosophy suggests that system developers create a series of deadlines for many releases of the system. The first releases would possess fewer features, but, with each new release, additional features would be added.

Reducing the Nonproductive Expansion of Work

Parkinson’s law states that “work expands so as to fill the time available for its completion.” If there are no specified deadlines, it is possible that knowledge work will continue to expand.

With traditional structured methodologies, deadlines at first seem far into the future. Analysts may use project management techniques to try to schedule the activities, but there is a built-in bias to extend earlier tasks longer than they need to be and then try to shorten tasks later on in the development. Analysts and programmers are less concerned about distant deadlines than approaching ones.

Once again, the agile approach stresses short releases. Releases can be delivered at the time promised, minus some of the features originally promised. Making all deadlines imminent pushes a realistic expectation for (at least partial) completion to the fore.

Reducing the Data and Knowledge Search and Storage Time and Costs

System developers need to gather information about the organization, goals, priorities, and details about current information systems before they can proceed to develop a new system. Data-gathering methods include interviewing, administering questionnaires, observation, and investigation by examining reports and memos.

Structured methodologies encourage structured data-gathering methods. Structured techniques would normally be used to structure interviews and design the interview process. Questionnaires would be developed in a structured way, and structured observational techniques such as STROBE would encourage the analyst to specifically observe key elements and form conclusions based on the observations of the physical environment. A sampling plan would be determined quantitatively, in order for the systems analyst to select reports and memos to examine.

Knowledge searches are less structured in an agile modeling environment. The practice of having an onsite customer greatly enhances access to information. The onsite customer is present to answer questions about the organization itself, its goals, the priorities of organizational members and customers, and whatever knowledge is necessary about existing information systems. As the project continues, the picture of customer requirements becomes clearer. This approach seems relatively painless because, when the system developers want to know something, they can just ask. The downside, however, is that the onsite representative may make up information if it is unknown or unavailable or evade telling the truth for some ulterior purpose.

Reducing Communication and Coordination Time and Costs

Communication between analysts and users, as well as among analysts themselves, is at the heart of developing systems. Poor communication is certainly the root of multiple development problems. We know that communication increases when more people join the project. When two people work on a project, here is one opportunity for a one-to-one conversation; when three people are involved, there are three possibilities; when four are involved, there are six possibilities, and so on. Inexperienced team members need time to get up to speed, and they can slow down a project even though they are meant to help expedite it.

Traditional structured development encourages the separation of big tasks into smaller tasks. This allows more tightly knit groups and decreases the time spent communicating. Another approach involves setting up barriers. For example, customers may not be given access to programmers. This is a common practice in many industries. However, increased efficiency often means decreased effectiveness, and it has been noted that dividing up groups and setting up barriers will often introduce errors.

Agile methods, on the other hand, limit time instead of tasks. Timeboxing is used in agile methodologies to encourage completion of activities in shorter periods. Timeboxing is simply setting a time limit of one or two weeks to complete a feature or module. The agile method scrum puts a premium on time, while the developers communicate effectively as a team. Since communication is one of the four values of the agile philosophy, communication costs tend to increase rather than decrease.

Reducing Losses from Human Information Overload

We have long known that people do not react well in information overload situations. When telephones were an emerging technology, switchboard operators manually connected calls between two parties. It was demonstrated that this system would work until an information overload occurred, at which point the entire system broke down. When too many calls came in, the overwhelmed switchboard operator would simply stop working and give up completely on connecting callers. An analogous overload situation can occur anytime to anyone, including systems analysts and programmers.

A traditional approach would be to try to filter information to shield analysts and programmers from customer complaints. This approach allows developers to continue working on the problem without the interference and subjectivity that would normally occur.

Using an agile philosophy, analysts and programmers are expected to stick to a 40-hour workweek. This might be viewed by some as a questionable practice. How will all the work ever get done? The agile philosophy states, however, that quality work is usually done during a routine schedule, and it is only when overtime is added that problems of poor quality design and programming enter the scene. By sticking to a 40-hour work week schedule, agile methodology claims you will eventually come out ahead.

Contents