A great approach under the right circumstances, agile is not a universal solution for successfully completing a software project. Some projects are simply not compatible with most agile practices. For such projects, NANW has been driving results in terms of project and rework costs, integration time, and improved quality as reported by customers.
Some time ago I published a brief article describing NANW (a Non-Agile, Non-Waterfall method of software development), and many people expressed interest in learning more about the framework. In this article, I answer some questions from readers and explain why the framework it is not a model somewhere in the continuum of the waterfall-agile spectrum.
1. What is “NANW”? And why don’t you find a better name for it?
NANW is a framework for the delivery of software solutions for business problems, focusing on the achievement of the expected results for cost, schedule, functionality and quality of the solution. This objective is pursued through the establishment of a disciplined, tailorable process, in line with what is recommended by the CMMI (Capability Maturity Model Integration) framework.
It uses an incremental and iterative model that focuses on fast delivery of business value through the implementation of an initial capability (which may include software, hardware, data dictionary, process changes, training, and other aspects of a comprehensive solution) followed by successive deliveries that expand and enhance the initial capability.
The framework allows requirements to evolve throughout the project lifecycle, but cannot be called “agile” because it doesn’t follow many of the agile principles (more on that in a later section of this article).
I chose a non-appealing name to designate this framework on purpose. Even though I have helped consulting firms and client organizations create their own flavor of NANW, and may continue to do so in the future, I have no intention of commercializing any version of it, or making NANW into a “recognizable brand”. I find it much more effective for organizations to use integrative thinking to create their own successful models for implementing IT-based solutions, as opposed to trying to conform to a commercially available framework.
2. How does NAWN compare to agile methods in terms of project results?
There are software projects that experience tremendous benefits from adopting an agile approach. In particular, projects that fit the agile sweet spot can be very successful using Scrum and other agile methods. For example, if you are building a single-purpose web-based application for a startup owner, agile may be an excellent choice.
For more complex projects, in particular with a large number of external dependencies and involving many decision-makers and geographically dispersed teams, NANW has helped organizations achieve superior results. Because of non-disclosure agreements I have with previous employers and consulting clients, I’m not able to provide specific data, but I have worked for organizations that went from 25% to less than 10% in customer-reported defects, and from 53% to over 90% of projects on schedule by adopting NANW.
Most of the software process improvement initiatives I’ve worked on happened in companies going from a low-maturity, non-agile software process to NANW, but in some cases measurable improvement came also from implementing NANW to rescue failing agile projects. Some agilists insist that, when agile doesn’t work, it’s because it wasn’t implemented correctly. In my experience, incorrect implementation, unsupportive organizational culture, and lack of skilled agile practitioners, as frequent as they might be, are not the only causes of failure in agile projects. A great approach under the right circumstances, agile is not a universal solution for successfully completing a software project. Some projects are simply not compatible with many of the agile practices. For such projects, NANW has been driving results in terms of rework costs, project costs, integration time, and improved quality as reported by customers.
3. What are the main characteristics of NANW projects, and what is behind its success?
The key NANW practices are:
-
The project’s purpose, scope, goals and measurable objectives are determined during project inception and refined, monitored and adjusted on a regular basis.
-
Overall projected size of relevant work products is initially estimated and then refined, monitored and adjusted on a regular basis.
-
Critical dependencies are defined, negotiated, and reflected in the project schedule.
-
A “minimum viable solution” (MVS) is defined, typically to be completed between 3 and 6 months into the project.
-
A roadmap is defined for enhancing the MVS in future cycles (typically with new software releases every 1-3 months), and then refined, monitored and adjusted on a regular basis.
-
Key roles (project manager, business analyst, interaction designer, technical designer, programmer, tester) are assigned to specialists in the respective domains.
-
First cycle of development to produce the MVS happens with business stakeholders and end-users heavily involved in reviewing relevant artifacts: as-is and to-be processes, functional specs, prototypes, mock-ups, working software, etc.
-
While the MVS is being produced, software requirements are being reprioritized and detailed for the next cycles, taking into consideration feedback from business stakeholders and end users.
-
Once the MVS passes user acceptance testing, it may be moved into production, or remain in the testing environment until ready to replace the previous system (when the software product is taking the place of a legacy system that cannot be retired until all legacy functionality is available in the new product).
-
Subsequent cycles of requirements-design-construction-testing are used to refine and implement additional requirements included in the product roadmap.
Some of these practices are aligned with agile principles, some are definitely not. There are 2 distinct aspects of NANW that help produce successful software projects:
-
attention to everything that matters to make a solution successful (not just working software); and
-
specialization of work.
Successful software projects require more than producing “working software”
In most projects, “working software” is not the only measure of progress or success. Planning, doing research, conceptualizing, modeling, documenting, are some of the tasks that may be as important as producing working software for the purpose of solving a business or user problem.
Typically a NAWN project includes a relatively short but in-depth, explicit requirements phase in its early stages, to minimize the problems that evolutionary requirements and design can introduce in more complex projects. Although there is always room to reevaluate, reprioritize and modify requirements, the business analyst strives to accurately articulate and anticipate the project’s needs as early as possible in the project life cycle. This approach makes it possible for critical, stable requirements to be identified and addressed in the initial architectural design, minimizing the risk of waste caused by avoidable rework.
The need for documentation
Even though agile practitioners insist that agile is not against documentation, only “excessive documentation” (a concept NANW also embraces), it’s common to see agile practitioners, including BAs working on agile environments, argue that “documentation should only be produced to the extent needed to generate working software”. Yes, requirements and design documentation are often needed to support the production of working software (as a reference for the programmers working on complex business logic, to communicate the details of user interaction design, etc.). However, the need to produce permanent documentation (written or in other formats, such as video recordings) may exist throughout the life of a software project in different circumstances, as illustrated by the following scenarios:
-
the team is preparing to hand off the project to another team that will maintain the product, and readable code plus automated test cases are deemed insufficient to explain system behavior or to clarify the reasons behind certain implementation choices that may affect future enhancements;
-
end-users will start to use a new product or feature, and need help understanding how to operate the software;
-
regulatory and compliance issues require a permanent record of implemented system behavior.
I’ve lost count of how many agile projects I’ve seen suffer delays because documentation wasn’t available for developers to understand what needed to change in a complex part of the code, for the compliance department to confirm whether proper controls had been implemented, or for the end-users to learn how to perform critical tasks. Agile proponents may argue that the problem resides with the agile team and not the approach, but when more value is placed in “shipping software early and often” than in other aspects of the solution, the risk that even crucial documentation will be treated as an afterthought will naturally grow.
The need for solid user interaction design
Same as with documentation, user interaction design is an area that tends to be neglected in many agile projects. It’s common for me to see teams using Scrum insist on including all design activities within the same sprint, an approach that often results in a rushed and ill-conceived user interface.
“Agile is all about build, push, evaluate, tweak. Oddly enough, design is all about build, push, evaluate, tweak, except we do it in our heads before we bother coding it.”
(Austin Govella, user experience architect)
While the ability to quickly adapt to meet needs that become visible only through the course of development is a positive aspect of agile approaches, working software built without intentional user interaction design often lead to usability problems and extensive, costly rework. In the NANW framework, a user experience designer is charged with modeling user profiles, the overall user interaction model, and the general “look and feel” of the application long before the project settles into a cyclic design model. In more complex projects, this approach significantly reduces the waste caused by the “build, push, evaluate, tweak” strategy that puts the burden in the end-user to identify what is wrong with the current interface and interaction design and tell the developers how to fix it.
Raising the quality of work through specialization
While agile approaches rely on the concept of the generalizing specialist (a person who is probably more experienced in one role, but can adequately perform other roles in a project), each member of a team assigned to a NAWN project focus on doing what they do best for the length of that project.
A typical NANW project has different individuals acting as project manager, user interaction designer, business analyst, system architect, technical designer, programmer, tester. These individuals may be performing the same role in multiple concurrent projects, when the project doesn’t require their attention full time. In some cases two roles are combined (e.g., a BA or programmer with solid knowledge of user experience design may wear both hats).
Granted, specialization is easier to achieve in large organizations, or in firms with budget for contracting external help in a project basis. However, insisting on having the same person perform project tasks requiring vastly different skill sets, more frequently than not will result in project issues much more expensive to correct. Having people with the right skills to perform each project task can significantly decrease the number of iterations it takes to get the details right, which positive impact in the cost and length of the development process.
As explained by David Wright in his book Cascade,
With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time performing the other roles than an appropriate specialist would, and is distracted from being productive in their primary role.
4. Would you recommend NANW as a stepping stone for an organization interested in adopting agile?
Definitely not; NAWN is not a framework somewhere in the continuum of the waterfall-agile spectrum, that could assist progress toward the goal of becoming an “agile organization”. It makes no sense to transition from waterfall to NANW and from there to an agile method, as if you were moving up in a “maturity model”, in particular because there is no “one-size-fits-all” method for software development into which an organization should aspire to evolve.
Many agile practitioners believe that, because it’s built on the foundation of feedback, learning and change, agile is always and everywhere applicable. According to this view, agile principles can be used in any type of projects because “we try, learn, adjust and try again”. You are welcome to share this opinion (I’m sure there will be plenty of readers in the comments section objecting to my views), but in my experience, practices associated with agile approaches are not intrinsically “value-adding”: they must be aligned to business needs and goals in order to provide true value.
NANW was born before agile, and did not evolve from the waterfall model. It doesn’t follow many of the principles behind the Agile Manifesto. It supports “agility” by recognizing that, as important working software is, there may be other project assets equally as important for the purpose of producing business value in an efficient and effective manner.
Such assets may include:
-
throw away prototypes used to test interface and interaction design assumptions before starting development;
-
business scenarios developed to resolve any conflicting views;
-
business rules that will be used to automate data calculation and validation;
-
logical data model that an interlock project may need early on to be able to timely handle project dependencies.
Agile methods can, and should be used, in projects for which they are a good fit (ideally, a project involving a small, self-organizing, collocated team working directly with a product owner). Hybrid methods combining agile and traditional approaches can also be very successful when the selection of practices is made based on the value they add to the project, as opposed to the need to adhere to a commercial method.
NANW is simply an additional option that organizations should consider when a project may benefit from having a clear set of goals and measurable objectives, solid governance processes to deal with external dependencies, and specialized roles to ensure the right questions are asked and the appropriate models are developed at the right time.
For such projects, NANW tends to provide better results than agile approaches by enabling broader discussions about requirements and design to happen outside short iteration cycles. In more complex projects, NAWN makes it easier to bring together the requirements of different segments of stakeholders, avoiding the fragmented views that can be developed using a just-in-time requirements discovery model. The framework promotes ease-of-use by involving a specialist in user experience design early in the project. It may significantly reduce refactoring costs by promoting a more systemic view of the solution and ensuring that the discovery of critical functional and non-functional requirements, as well as of usability issues, happens as early as possible in the project, so they can be addressed in the initial architectural and technical design.
Compared to agile approaches, perhaps the most important contribution from NANW to the successful delivery of complex software consists in its ability to promote a clearer distinction between change needed because of the emergence of new requirements (worth embracing) and wasteful change caused by insufficient time and thought spent upfront truly understanding the underlying problem (to be avoided).
* * * * * *
Author : Adriana Beal received her B.S. in electronic engineering and MBA in strategic management of information systems from two of the most prestigious graduate schools in Brazil. For the past 10 years she has been offering consulting assistance throughout the software development life cycle for organizations implementing large, complex software projects.