20 Years Agile: Project success and management methods-Bernhard Schott-DCT Consultancy

Success or failure of a project depends on many factors, including choice of the optimal project management method, agile, classic, or hybrid.
20 years of Agile Project Management: in 1999 Kent Beck published “Extreme Programming” followed in 2001 by the Agile Manifesto and the Agile Principles.
Since then, the world of software projects has changed massively – successful in agility!

There are success-factors for projects less often, less prominently discussed – some of them are presented here with concrete examples:

Pragmatic requirements management
Nonfunctional requirements
Documentation
Quality Assurance (QA)

Classical (waterfall) projects feature a start and an end point and a linear project plan constituted from pre-defined steps. Such procedure is adequate for a one-time activity based on well-established technology and practice. Well known technology and practice implies meaningful expectations in terms of functional and non-functional requirements.

Agile projects establish an iterative development process. Software development technologies are young and changing quickly. Typically functional requirements change during project runtime. This requires a project organization that allows developers to focus and work systematically while taking advantage of dynamic technological progress.
In agile projects, development departments can work continuously – a project is presented as process to the developer teams.
Processes are continuous and, while running, are improved, modified, and adjusted.
Key to success of agile methods is such iterative approach inclusive frequent (daily) exchange with the customer.

Agile versus upfront requirements specification: Another important innovation of agile methods is to admit bluntly that it is not possible to know everything in advance.
In classical project management uncertainties are reflected by time- or cost-buffers – by all experience an insufficient approach.
In agile project management open questions are managed and controlled in iterative practice.
Different from classical project management agile iterative practice extends to topics which are strictly statically defined in classical projects: requirements specification. Comprehensive requirements specification is replaced by a collection of User-Stories with the intention to define usage requirements without technological stipulation. Developers shall be free to decide on tools and technology by their own judgement.

Customer requested project management methods

Often the project management method is not a choice.
Customers tend to request certain models (e.g. “V-Modell” for German Gov projects). In other cases, an established developer team prefers a specific (agile) method.
It should not stop the project from being successful: project management methods are simply tools. And not the tool as such but how the tool is used determines success of the project.
Often problems in projects have nothing to do with the chosen management method – at least not with the question for agile or waterfall.
Elements found in the Agile Manifesto were in use in many successful classic projects: for example continuous communication with customers to re-adjust requirements – secret sauce or best practice in old-school project management.
Iterative approaches were also in use long before Agile Manifesto, but often in a disguised way as iterations were perceived to be costly.
Even project management frameworks well known as “extensive” include agile methods meanwhile, for example the German Government project standard V-Modell XT (PDF), version 2.3. English translation of version 1.3 V-Model-XT-english

Prioritization of Requirements and Goals

Many problems in projects are not related to the chosen management method at all – not specific for Agile nor Waterfall.
How straight forward or difficult a project is going to be is often decided during preparation phase: Are goals and requirements clearly prioritized or just put in stone in a static „must have“-list? Prioritized means here, the most important goals need to be achieved to close the project successfully. Correct and precise definition of requirements is often possible only while the project is already running. Quite usual this results in bloated static lists - increasing efforts on tasks potentially not contributing to project success. BRUF (Big Requirements Up Front) is a name coined for such an approach. Note: reference 6 focusses on Agile projects although the issue appears in all other methods as well.
BRUF goes along with the additional risk that new information (new requirements) is kept secret as beyond scope and not to be discussed.
An obvious advantage of establishing a culture of discussion with the customer is the possibility for introduction of new findings into the project, assuring customer satisfaction.

Pragmatic Approach: A management-model independent pragmatic approach on requirements is to distinguish between goals and requirements and establish a prioritized list of such project goals, to be used further on as success criteria for the project.
Project success is when the top L goals are reached and additionally N of the M following group of goals. The choices for N of M is agreed with the customer in close consultation and continuously followed up and verified (culture of discussion) during project lifetime.
Requirements derived from goals are not BRUF stipulations but results of inner-project system architecture, system design, and discussion with the customer.

Example for suboptimal requirements management

Unfortunately not rare is the mistake to define elements of a not yet developed system design upfront and list them as requirements.
Example: Requested mandatory use of server product by supplier X in version Y.
Background: When asked for rationale, it was argued a company license was purchased already for this product. Also consultancy Z recommended the use of this product. (Z is sales partner of X).
Solution approach: In the course of further discussions it was revealed, that license costs were to be charged on the project nevertheless. Further several feature licenses were not covered by the company license. System-Architecture preferred a different solution. Customer’s own departments for security and privacy expressed doubts on the product’s compliance. Finally it was possible to deviate from the requirement and select a technically suitable and cost efficient alternative solution.

Examples for agile failure and success

As stated before, project management methods are just tools. The outcome depends on how you use them. Here two real world examples:

An example for suboptimal agile development
An example for successful agile development

The first example describes failing requirements management and insufficient interaction of product manager and developers.
The second example shows reasons for success of agile development, especially QA and documentation.

An example for suboptimal agile development

An ISV with important customers in Government-sector develops a middleware for HPC load balancing. Development organization is agile (Scrum); product strategy reduces the number of self-developed functions in favor of external (Open Source) components. In return, installation process includes lots of downloads, OS-updates, and dependencies.
Installation at a secure site fails since no internet access available.
Second try, a customized installation-DVD replaced the missing internet access. After installation done customer complains that previously demonstrated graphical features do not work. Those make use of Google APIs which are available online only. Also customers from Oil&Gas (e.g. vessel based HPC cluster) report this problem.
What went wrong?
The nonfunctional requirement “Installation and operation must be possible offline” was lost - although originally included in DoD. The DoD (Definition of Done) list is in sole responsibility of development team – product-owner only delivers his requirements.
What seems doable for short projects fails for long running continuous product maintenance of complex applications and middleware. The product-owner or product manager needs to accompany his product and raise and maintain understanding of boundary conditions and customer requirements in the development teams frequently. Not once but frequently: developers’ daily work focusses on the module they are working on – the full system is beyond their scope in this moment. Also, development teams tend to hire specialists for specific tasks - but these guys have never heard of system context and so are prone to get trapped.

An example for successful agile development

A successful ISV for complex system-middleware recognized early, that his customers were betting their existence on the stability and performance of his middleware product. To meet this responsibility product- and development-strategy were defined accordingly.
Produktstrategy: SOA: components (aka services) are either self-developed or well controlled and packaged along with the product.
Self-contained install – DVD install works, almost no OS-patch-level dependencies.
Backward compatibility – cmd syntax and API stay unchanged for released features although new features added over time.
Development Strategy: agile with strong commitment to total system quality
Information Development (Documentation): different from web/UI projects, for system-middleware correct high quality documentation is a must. Developers’ responsibility is to deliver technical documentation along with their code. ID is testing the new code based on the documentation provided by dev. When documentation is found sufficient, ID declares their go to the release.
QA (Systemic tests and quality assurance): While developers’ unit tests verify a specific piece of code is functional, only systemic tests reveal whether the full system works with the new code, under various boundary conditions, customer configurations, and also under high load. When successful, QA declares their go to the release.
Outcome: Stability, reliability, and performance of this system middleware is legendary. Over many years a top price point was achieved in a highly competitive market despite low cost and free alternatives.

Note on documentation
No, there is no contradiction to the agile Manifesto.
The Agile Manifesto states (citation) “Working software over comprehensive documentation”. Here, documentation is understood as project documentation and reports – internal documents.
When customer facing documentation is essential for the value of a product – like in the case of system-middleware – documentation is as functional to the product as all and any of the other user-stories – as important as “working software”.

20 Years Agile: Project success and management methods

Customer requested project management methods

Prioritization of Requirements and Goals

Example for suboptimal requirements management

Examples for agile failure and success

An example for suboptimal agile development

An example for successful agile development

Recommended reading:

Links

FEATURED TAGS