Beiträge

Läuft, …dank BCM

In Zeiten von Cyber-Attacken, Lieferengpässen und zunehmendem Verlust von Wissen durch den Weggang von Mitarbeitern entlang der Wertschöpfungskette eines Unternehmens wird das Thema Business Continuity Management, kurz BCM, zu einem immer grösser werdenden Erfolgsfaktor in der Geschäftswelt. In diesen Tagen fehlen Computerteile von zuliefernden Unternehmen genauso wie notwendiges Know-how, um den Status Quo im Wettbewerb zumindest zu halten. Der Ausbau ist ein anderes Thema. Einer meiner grössten Management-Vorbilder sagte einmal “Alles Projektmanagement ist Risikomanagement”. Das ist in diesen unruhigen Zeiten wahrer den je. Das Entgegenwirken von Risiken beschränkt sich nicht mehr nur auf die Bereitstellung eines neuen Servers oder PCs, wenn diese ausfallen. Vielmehr wird die gesamte IT-Organisation und ihre Prozesse, sofern sie mittel- oder unmittelbar an der Wertschöpfung des Unternehmens beteiligt ist, hinsichtlich ihrer Ausfallsicherheit kritisch betrachtet. Das es nicht erst eine Pandemie braucht, um Unternehmen auf dieses Thema zu sensibilisieren, sollte klar sein. Auch ohne Pandemie müssen Unternehmen regelmässig Risikoanalysen und -bewertungen durchführen, um nicht durch eventuell vorhersehbare Krisen überrascht zu werden und dann im schlimmsten Fall den Geschäftsbetrieb einstellen zu müssen oder sogar in Regress genommen zu werden. Wie eingangs erwähnt sind auch Cyber-Attacken und Ransomware nur eines von vielen Risiken, die nach geeigneten Angriffspunkten Ausschau halten.

SPF Consulting AG - Insights -BCM

Die ISO 22301 gibt eine geeignete Hilfestellung in Form eines Frameworks entlang der Wertschöpfungskette eine Ausfallsicherheit zu planen, geeignete Massnahmen zu etablieren, regelmässig zu validieren, zu überwachen und kontinuierlich zu verbessern. Wurden diese Massnahmen definiert und sind integraler Bestandteil des unternehmensweiten Risiko-Managements spricht man von einem Business Continuity Management System, oder kurz BCMS. Nimmt man zum Beispiel die IT-Organisation, so ist der erste Gedanke die Ausfallsicherheit der Systeme. Was auch legitim und sinnvoll ist. Ein zweites Data Center was gespiegelt wird ist hier eine sinnvolle Lösung. Was aber wenn Daten mit krimineller Energie manipuliert oder sogar gelöscht wurden? Dann ist das Konzept der permanenten Spiegelung zu hinterfragen. Das sind aber dann Details die individuell geklärt werden sollten. Die ISO 22301 betrachtet die Themen Planung, Unterstützung, operative Umsetzung, Performance-Messungen und -Verbesserungen. Unterstützt wird diese Norm durch diverse assoziierte Normen, die beim Aufbau eines BCMS unterstützen. Die ISO 22313 gibt eine Hilfestellung wie die ISO 22301 anzusetzen ist. Die ISO 22317 liefert ein Muster wie eine Impact-Analyse durchzuführen ist. Wichtig wäre an dieser Stelle auch noch die ISO 22318 zu erwähnen, die sich mit der Ausfallsicherheit von Lieferketten und deren Zulieferer beschäftigt.

 

SPF Consulting AG - Insights -BCM

Bei allen Normen und Frameworks, die man hier einsetzen kann, steht und fällt es mit der Akzeptanz der involvierten und damit verantwortlichen Mitarbeitern. Die Prozesse zu definieren und später auch regelmässig anhand von simulierten Ausfällen zu validieren steht auf einem anderen Blatt. Deshalb ist unsere Empfehlung anhand langjähriger Erfahrung in diesem Bereich, dass sämtliche Prozesse und Arbeitsanweisungen für den Notfall zu den Dokumenten des BCM-Owners gemacht werden sollten. Der Fachverantwortliche, der für ein System oder eine Lieferverpflichtung zusammen mit seinem Ansprechpartner auf der Supplier-Seite verantwortlich ist, muss sich in diesen Dokumenten wiederfinden. Er muss sogar das Gefühl haben, dass er das geschrieben hat. Nur so wird im Notfall ein maximales Engagement erzielt und die Wahrscheinlichkeit, dass es einen Unterbruch in der Wertschöpfungskette gibt maximal minimiert. Denn auch in Bereich BCM gilt: Diejenigen, die die Notfallpläne definieren, sind selten diejenigen die sie später ausführen müssen. Gegenseitige Akzeptanz und Unterstützung ist somit erfolgsentscheidend.

 

Fragen? Kontaktieren Sie uns!

Ihr Ansprechpartner: Harald Schmidt
E-Mail: harald.schmidt@spf-consulting.ch

Harald Schmidt

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
Email: sufi.mohamed@spf-consulting.ch
Twitter: https://twitter.com/agile_sufi
Kontakt: https://www.spf-consulting.ch/kontakt/

«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.

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

Dein Kontakt

Sufi Mohamed

Sufi Mohamed
Email: info@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/

«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.