Managing Risk in Agile Projects - StarChapter



Managing Risk in Agile ProjectsDan S. RomanIntroductionIn Recent years Agile is considered a viable option to traditional Project management delivery. Considered and implemented since late 1990s in Manufacturing, Agile become very popular in the first decade of this century due to the success of software development frameworks like Extreme Programming and Scrum. Project Managers were interested form the beginning in the new way of building projects. According to the state of Agile survey, 30% of the respondents are Project managers from the 1st edition started in 2007 to the most recent one completed in 2019. Risk Management is a core competency for a Project Manager and regardless the predictive or adaptive delivery approach, the way we manage risk will always be a critical success factor for the success of the project.This article is analysing how risk is perceived and managed in projects that use Agile practices, what is the impact how Agile adoption will impact the management of risks in projects and in the organisation as a whole.Enterprise Risk ManagementMost Agile, predominantly Scrum, teams have a very simplistic view of risk. None of the Agile frameworks have a section that indicate how risk in managed by that particular framework. “Scaled” approaches are basically using traditional project risk management practices without any recommendation that is specific to an Agile delivery.Figure 1 presents risk from an Enterprise point of view. Most organisations, that are not built around a software product will have a very small software development team. Information Technology (IT) is not a core competency, but a supporting function, usually part of the Corporate Services Division, along with Accounting, Marketing, Human resourcing, Procurement etc. Most IT projects are implementing Out of The Box (OOTB) solutions like collaboration tools, Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM). If an Application Development Team is still present, their role is mainly maintenance and support, sometimes undertaking small changes or customisations. Frameworks like Scrum or even scaled ones like SAFe were developed by software 18891252444115Figure SEQ Figure \* ARABIC 1- Enterprise Risk ManagementFigure 1- Enterprise Risk Management188912538671500consultants and in many organisations using them without integration in a Project management methodology, like PMBOK, will be a significant challenge.Moreover, Enterprise Risk Management is a separate function in a large organisation dealing with a wide variety of risks, from financial and reputation risk to safety risk. It is PMO’s responsibility to align the Risk Management practices and tools with the Enterprise policies and procedures related to risk. Agile Risk ManagementManaging risk in Agile projects or environments can be easily done using established practices and tools from the planned approach. Risk Management is an established and mature discipline and in the absence of an alternative way of managing risk defined in the Agile frameworks, it should be relatively easy to adapt practices to an Agile delivery approach. The first step in managing risk in any organisation is to establish the context, especially the risk appetite. An organisation that is risk averse or has a very conservative and hierarchical structure, with formal reviews and sign off, will struggle to adopt Agile. Agile in itself will be perceived as a risk to the organisation and controls will be put in place to limit and control change, contrary to the core Agile value of embracing change, therefore embracing risk.To be successful in implementing Agile, from the risk management perspective, the tools and practices used by Agile teams must be integrated and aligned with the Enterprise way of managing risk. PMO and Project Managers will need to act as coaches for their teams, explaining the importance of Risk Management and educating their team members that splitting work in small deliverables doesn’t necessary reduce the project risk. A project can fail even when the deliverables are completed on time and on budget, if the client is not ready to implement and use the outcome of the project.The Risk BoardKanban boards are very popular among Agile Teams. Kanban boards technique is not part of the Scrum framework, used by more than 60% of the Agile teams, according to the State of Agile surveys. Due to its simplicity and lack of better Scrum tools, it is de facto the most used planning tool in conjunction with the Product Backlog.An easy integration is the creation of a Risk Board, either adding risk cards on the same Kanban board or as a separate board. Using a familiar tool makes change management easier but the Project Manager will still need to act as a coach and get the buy in from the team that managing risks is beneficial for them rather than a project governance requirement.-80010765175AcceptedAccepted-1333590170MonitorMonitor5143500744855Backlog Tasks0Backlog Tasks514350011430Escalated to Risk Register0Escalated to Risk Register8763002392045Figure SEQ Figure \* ARABIC 2- The Risk BoardFigure 2- The Risk Board8763000The Risk Board is split in 4 areas, each holding cards (post-it) describing the risk. The four areas are:Risks that were identified by the team but accepted. Those are risks that either have a low impact or low likelihood to occur. They can be also risks that will cost more to prevent than the estimated impactRisk that will be monitored. Those risk are more significant that the accepted ones but not significant enough to take actionRisks that become Backlog tasks, someone in the team will need to do something about themRisks that can’t be addressed by the team and are escalated to the standard Project Risk register. From team’s perspective they become the solely responsibility of the Project ManagerThe main purpose of the Risk Board is to educate the project team about the importance of managing risks. It is an opportunity to not only find and manage risks but also for team building and for creating and maturing self-organisation.Cards included in the backlog will have an owner, similarly the ones in the Monitoring area can be owned by a team member. It is a good way to show member’s contribution to the team effort and eventual success.The second step, once a culture of risk awareness is established, is to educate the team members in one of the main benefits of Agile delivery: positive risk taking, also called opportunities. Most of those will be a team decision, some even requiring agreement with the Product Owner. Things that will hardly be accepted in a risk averse organisation, like releasing without lengthy testing, relying on customer’s understanding that an early delivery will bring early benefits and non-structural changes or fixing small defects after deployment to production is a better cost-benefit alternative for the client.ConclusionManaging risk in Agile environments must follow the Manifesto for Agile Software Development principle of ‘uncovering better ways’ rather than following a prescriptive way. It should be based on trust, collaboration and embracing change rather than formalised and imposed by a governance framework, or worst by the desire to be seen as Agile. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download