agile lifecycle

Agile methodologies and organisational agility

The world is dynamic meaning that change is inevitable. Industries force businesses to keep up with these changes. No matter how long your project takes to realise, many aspects of your environment will be subject to change. Throughout the course of your project, many changes can occur in your customers, industry, competition or even your team(s). Adopting agile methodologies means cultivating a flexible outlook that adapts to dynamic industries. It’s called “Agile” because of its ability to accommodate change. Agile methodologies emphasise partitioning work into iterations, with each iteration delivering a minimal viable product (MVP), or enhancements of said product. The MVP helps the customers experience your product. Despite the changing environment of which your business is subjected to, the only measure of progress in such contexts is literally the delivery of the MVP, or functionality your customers are expected (or should) use. Agile methodologies are intended to help your team minimize production loss, and to avoid developing unwanted aspects of your product (or features).

Learn how to be a successful visionary Agile Leader.

Agile Methodologies and organisational flexibility

Even now, companies implement complex approaches in an attempt to secure the uncertainties of the future. This method is often rigid, inflexible, and unresponsive to the dynamics of the industry, often referred to as the „waterfall“ approach. Adapting to the changing milieu helps companies respond to customer feedback, which is crucial to your product’s success. This feedback helps you make implementations wherein your customer gains a new (and better) understanding of your product. Throughout the course of the product’s development, especially after you’ve introduced it to the customer, wouldn’t you rather augment the product than engage in an entire re-planning process? This is exactly where agile can help you. Agile methodologies can be scaled, with respect to your project demands, number of teams, and the scope that project entails. When using an agile method keep in mind that:

  1. Agile does not limit developers to certain techniques or methods. This gives space for your team to innovate and discover optimal ways for implementing requirements;
  2. Agile is flexible enough to permit adaptation to your organisation;
  3. Agile methodologies employ variable approaches, such as different software development techniques.

The transition phase between each iteration is focused on acquiring customer feedback. Early detection of issues found in your product, from the customer’s point of view, will help you adjust your product accordingly. The team engages in consistent and constant testing to ensure that customer feedback is seamlessly integrated. When the team receives the customer’s feedback, they use it to determine the context of that feedback and where it fits among their priorities. A common thought is that, „there is no planning in Agile if all you do is evolve iteratively“. In some cases that may be true, some aspects of your product may spontaneously evolve without you being aware of its direction. It’s important to give room, and possibility, for this to occur. Nevertheless, agile methodologies encourage planning under the condition that those plans are flexible and responsive to those environments where those plans are situated. According to Shane Hastie, the Director of Agile Learning Programs for ICAgile and founding chair of the Agile Alliance New Zealand, agile should not cause your team to ignore design principles. Agile still needs analysis to review impactful decisions and assess what changes are necessary. Shane Hastie expressed that, “There is nothing in the agile manifesto about not planning the overall structure of the product from the beginning”. This integrated natural alignment towards planning allows agile companies to lower their risk by working on what is actually necessary, and avoiding waste in the process of the project’s realisation.


Agile Methodologies and customer feedback

agile methodologies customer feedback


The diagram above represents how the iterations (also called sprints) (could) work. Keep in mind that a cycle, or aspects of an iteration, may be adapted to the team’s purpose. The diagram above is merely an example of a possible iteration cycle. The cycle perpetuates infinitely, there is no end to it (unless the project has really come to an end). Each cycle releases a functional prototype, or improvement of the prototype, to stakeholders and customers. The upcoming iterations are based on feedback obtained during review cycles of previous iterations. The ‘requirements’ phase is where the business defines what is needed. This depends on the initial purpose of the project or customers’ feedback on previous iterations. After defining the requirements, the team responsible will begin the development phase. Once development is complete, acceptance tests begin to ensure quality compliance. The team tests regularly, and actively, throughout the entire engagement of the work. When ready, the developed prototype is released to the customer. Feedback is gathered from customer, and stakeholders, who use this product. This feedback is reviewed thoroughly by the developing team and thus the cycle begins anew.

Apart from changes in customer’s needs, other changes are expected to take place such as in the economy, laws, team, business competition, etc… It may not be necessary to accommodate all of these industry changes, but some cannot go unnoticed. If these industry-impacting changes are not properly accounted for, the organisation may suffer the consequences of its neglect. Agile methods help businesses reduce the impact of these unplanned occurrences allowing you the flexibility to adapt on-the-flow to changing organisational dynamics.

Embrace your inner agility today!


Dein Kontakt

Sufi Mohamed

Sufi Mohamed

«Dediziert den Wert Ihrer Teams aufdecken.»
Die Erfahrung von Sufi im agilen Beruf hat ihm geholfen Prozesse, Ziele und den Wert von Teams zu identifizieren. Mit Know-how im Agile Requirements Engineering und verschiedenen agilen Methoden (Scrum, SAFe, LeSS, Kanban, ScrumBan, etc….) engagiert sich Sufi dafür, die Qualität Ihrer Teams und deren Affinität zu agiler Mentalität aufzuzeigen.

Agile Project Management vs Waterfall Project Management

How To Apply Agile Project Management

Agile project management relies on interative methodologies to plan and steer (or guide) projects. Inspired by agile software development, agile projects complete their work in many small pieces spread over a given period of time. These are called iterations. Iterations happen in a predictable, cyclic pattern with defined start and end dates (usually two weeks). In agile software development, an iteration implies a software development lifecycle whereby the result is presented to stakeholders and project team members in order to receive feedback on the use and application of the functionality. The outcome of the iteration is critiqued and its feedback is acquired to determine the next steps in the path of realising the big picture. Validating the iteration’s result is absolutely critical in agile software development in order to confirm, or debunk initial assumptions of the developed software.

Agile project management strongly benefits from early insights acquired during the feedback process, and also issues during the course of the project. Simply put, responding to change could mean the life and death of projects: how will the recently acquired insights affect resources and the budget? When is the expected timeline for the project’s realisation? Can we really do the project with the insights we’ve acquired since the previous iteration?

Learn how to be a successful visionary Agile Leader.

Agile Project Management vs. Waterfall

Before explaining what agile project management is, let’s talk about what it isn’t. There are variable project management life cycle process models such as linear, incremental, iterative, adaptive, and extreme (Wysocki, 2014) and the conditions of the project typically determine what process model makes sense. The traditional waterfall project management style applies the linear process model of project management. Waterfall project management styles depend on a plan-driven approach and are resistant to change—they come with heavy documentation and expectations, rigid mockups, requirements that have been so thoroughly (or not) reviewed and plans so strictly organised that changing even the smallest aspect of it can cause a cascading effect of unpredictability. Incremental project management process models are quite similar and to the linear models: the only difference being that requirements and project scope are delivered incrementally rather than all together before the start of the project.

Agile project management uses a change-driven approach. Change is fundamental and encouraged in agile project management approaches—after all, it would be nice to know early if changes in the work will result in unexpected consequences. A business wouldn’t want to continue with everything as planned and not leave room for the unexpected and unplanned. This ongoing collaboration and open communication is encouraged, from those who create the product to stakeholders who have a stake in the direction of the product—there is a vested interest throughout the entire agile project management lifecycle process model. Agile project management improves upon the waterfall (linear) model by incorporating planning as part of the incremental activity, and resolves those plans iteratively.

Agile Project Management vs Waterfall Project Management

Agile Project Management vs Waterfall Project Management

The greater the project’s uncertainty, the more space for change is required. Adaptive and extreme project management process models encourage uncertainty but it may be difficult navigate the terrain with an uncertain perspective. Thus, agile project management has been favoured in most organisations, small to large scale agile project implementations.

What is Agile Project Management?

Agile project methodologies partition projects into smaller pieces which are completed in periodic intervals from the design phases, testing, and quality insurance. These intervals are called sprints, a popular term for an iteration used by one of the most popular agile development methodologies called Scrum.

Sprints are typically short bursts of intense productivity that begins and ends in intervals of two to maximum four weeks. Agile methodologies rely on specialised teams to release functionality as soon as they are completed (and tested). This continuous release cycles allow teams to see the effect of their deployments and if unexpected consequences arise (not found in testing), allows teams to fix those issues quickly and redeploy.

Agile project methodologies empower companies to reduce large-scale failures and to quickly react to uncertain conditions throughout the project’s lifecycle.

How does Agile Project Management work?

Throughout the course of an iteration, agile teams adopt an assortment of best practises (quality assurance, software craftsmanship) as well as continuous adaptation.

Agile teams incorporate and develop an environment that promotes automation, error-free deployments, and early detection of errors in product development to speed up the release deployments and testing procedures. They adopt DevOps best practises (and mentalities) to synthesise an environment that is capable of continuous deployment, continuous integration, and continuous improvement.

Agile project management requires that agile teams iteratively evaluate their time and efforts as they continue throughout the course of their work. Metrics such as velocity, burndown and burnup charts allow agile teams to measure their work. Here, agile teams acquire a baseline potentiality of the ability of their team (not all teams have the same metrics).

Agile project management does not require a project manager, because the work of the PM is distributed among agile teams (the teams know best how to deliver their work, and what effort is required. From this, teams are able to synchronise their work in a timely way). In project-delivery focused waterfall methods, a project manager was essential because the company was developing projects and not products. This difference is essential.

Dedicated Product Owners are those who set the goals of the project, in a timely way, with agile team for which their work is dedicated. Together with the product owner, agile teams handle scheduling, report project progress, and measure the quality of their work. Some agile approaches like Scrum deploy an agent dubbed the Scrum Master whose role is a facilitate the relationship between the Product Owner and the agile team, by removing impediments and facilitating workflows, processes, and simplifying communication to shepherd the project to its completion.

Agile project management, in some cases, may still make use of the project manager, except not in the same role as that person once had in the traditional waterfall process. Rather, the project manager is a coordinator and facilitator, relaying information and supporting the project’s development in a more tertiary capacity rather than administering teams. Rather than the previously held taskmaster role in the linear process model, the project manager is transformed into a visionary leader.

Since agile teams no longer need a project manager to tell them how to do their work, the priorities and evaluate risks for them, agile project management demands a lot more from agile teams. Agile teams know how to do their work, what is important, and when those things can be done and so, organisations place a lot of trust in agile teams to steer and determine their work. Companies that adopt agile project management have to empower teams to take the appropriate actions and to maintain the delivery pipeline at all times. Agile teams must also be able to communicate with stakeholders, product owners, and with other teams—social competence is fundamental.

History of Agile Project Management

Continuous development, continuous deployment, and continuous integration is not new to today’s vernacular. It has been around since the mid 20th century and it has been practised in various forms throughout the decades, championed by visionaries in software engineering and software craftsmanship. While waterfall project management techniques were gaining ground in the 1990s, James Martin’s 1991 publication introducing Rapid Iterative Production Prototyping (RIPP) became the foundations of what is now practised in Rapid Application Development (RAD).

In recent years, the agile methodology known as Scrum has gained significant momentum. Scrum is an agile methodology that has three roles: Product Owner, Development Team, and Scrum Master. The product owner works with a development team to create a product backlog, which is them prioritised in according to business value in order to deliver features, fixes and the overall software to production. The team delivers this in rapid increments.

With the increasingly dense, and sophisticated world of software engineering, technological innovations, and connected systems, the 21st century demanded an evolved way of navigating the growing complexity. Rapid response is not only a expected, but desired.

Wysocki, R. K. (2014). Effective project management: traditional, agile, extreme. Indianapolis, Indiana: Wiley.

Dein Kontakt

Sufi Mohamed

Sufi Mohamed

«Dediziert den Wert Ihrer Teams aufdecken.»
Die Erfahrung von Sufi im agilen Beruf hat ihm geholfen Prozesse, Ziele und den Wert von Teams zu identifizieren. Mit Know-how im Agile Requirements Engineering und verschiedenen agilen Methoden (Scrum, SAFe, LeSS, Kanban, ScrumBan, etc….) engagiert sich Sufi dafür, die Qualität Ihrer Teams und deren Affinität zu agiler Mentalität aufzuzeigen.

Du redest zu viel! Oder nicht?


Kennst du diese Situation? Du sitzt in einem Meeting und der Zeitplan läuft aus dem Ruder weil eine Person mal wieder 50% der gesamten Gesprächszeit für sich beansprucht. Die übrigen Teilnehmer, längst daran gewöhnt, schalten auf Durchzug, beginnen ihre E-Mails zu checken oder warten einfach ab. Der Wert der Information ist gering und je länger das Meeting dauert desto mehr sinkt die Stimmung, es beginnt zu nerven.

So oder so ähnlich gibt es im Geschäftsleben viele Situationen. Das Verhalten einer einzelnen Person führt zu Missstimmung, Demotivation oder Resignation und erschwert damit ein konstruktives Arbeiten.

Spinnen wir die Geschichte etwas weiter: Irgendwann nach vielen solchen Meetings beschliessen einzelne Personen etwas zu unternehmen und beschweren sich in den 1:1 Gesprächen beim Vorgesetzten. Der Vorgesetzte erhält so über die Zeit von verschiedenen Personen Beschwerden über das Verhalten zu einem seinem Mitarbeiter. Irgendwann kann er diese Beschwerden nicht mehr ignorieren. Er nimmt seinen Mitarbeiter zur Seite und löst das Problem. Zum Beispiel indem er ihm mitteilt, dass er Beschwerden erhalten hat darüber, wieviel unnötiges Zeugs er an den Meetings erzähle. Vielleicht macht er es auch auf eine bessere Art und Weise, doch es bleibt ein Gespräch zwischen Chef und Mitarbeiter, an dem ein Verhalten bemängelt bzw. bewertet wird.


In den meisten Organisationen sind solche Situationen an der Tagesordnung. Es muss nicht die Gesprächszeit sein und auch nicht ein Meeting. Am Ende geht es darum, dass ein bestimmtes Verhalten, in einer bestimmten Situation immer wieder zu viel kreative Energie vernichtet. Die beschriebene Lösungsvariante über den Vorgesetzten ist ebenfalls ein äusserst übliches Muster. Wir sehen es in fast allen Firmen und auf allen Stufen, von Fachteams bis zu Geschäftsleitungen immer wieder. Die Hierarchie soll es lösen.

Zurück zum Titel und damit zu dir:

Weisst du, ob du zu viel (oder auch zuwenig) redest an den Meetings? Weisst du, ob deine Argumente verstanden werden, ob deine Sätze einfach und klar sind oder viel zu kompliziert? Weisst du, ob deine Körperhaltung die anderen nervt, weil du immer wieder mit dem Finger auf sie zeigst? Dein schlürfen aus der Kaffeetasse ist das Kaffegespräch? Hast du das gewusst? Nein? Du weisst all diese Dinge nicht? Ist dann nicht davon auszugehen, dass du auch andere wichtige Dinge nicht weisst? Vielleicht ein kritischer Projektstatus? Unzufriedene Mitarbeitende? Kunden die sich über dein Verhalten beschweren?

Dem Mitarbeiter, der 50% Gesprächszeit an dem Meeting „verschwendet“, hats einfach nie jemand auf eine gute Art und Weise gesagt. Ich meine damit keinesfalls den Chef, denn der ist am Meeting ja gar nicht dabei.

Oder die Mitarbeiterin die zickig mit den Augen rollt und die Stimme unangenehm quietschend anhebt, wenn ihr widersprochen wird – auch ihr hat nie jemand Feedback gegeben!

Agilität in der Organisation bedingt eine offene Kultur. Eine Kultur in der wichtige Dinge die die Zusammenarbeit beeinflussen angesprochen werden – positiv wie auch negativ. Damit sind nicht nur Arbeitsresultate, sondern eben vorrangig auch Verhalten von Menschen und Gruppen gemeint. Das eigene Verhalten kann man nur selber ändern und dazu braucht man Feedback.


Eine erfolgreiche Agilität bedingt ein in alle Richtungen durchlässiges Feedback, ohne Hemmungen oder Konsequenzen. Wie sollen sich Dinge verbessern, wenn keine Feedbackkultur etabliert ist? Wenn Misstände aber auch positives nicht angesprochen wird? Und am Ende: Wie soll sich ein Mensch jemals wertgeschätzt fühlen, wenn ihn nie jemand ernst nimmt und ihm Feedback gibt?

Feedback ist ein zentrales Element der Agilität, ein Element das in den meisten Unternehmen wie ein Mauerblümchen behandelt wird. Aber du kannst es ändern, denn du kannst heute damit beginnen! Es gibt einfache Mittel und Wege mit Feedback in deinem Unternehmen zu beginnen.

Wenn du wissen willst, wie du das am besten angehst, dann findest du bei den „Agile Professionals“ von SPF-Consulting die richtigen Ansprechpartner. Frag uns und wir schicken dir das „Speedback“ Paket.


Dein Kontakt

Martin Talamona
Martin Talamona

«Die Digitalisierung fordert die Unternehmen heraus, Veränderungsfähigkeit zu einem Erfolgsfaktor zu machen. Die agile Organisation ist der kreative Schlüssel dazu.»
Mit über 20 Jahren Projekt und Führungserfahrung in der Produktentwicklung, acht davon auf Geschäftsleitungsstufe ist Martin einer der wenigen „Hands-on“-Executives der Schweiz, der agile Transformationen von ganzen Organisationseinheiten erfolgreich geprägt hat.