How To Develop Situational Awareness As a New Agile Coach or Scrum Master
We'll walk you through how to develop situational awareness on large and complex projects as a new Agile Coach or Scrum Master
CORE
·
Join the DZone community and get the full member experience.
Join For FreePicture this: You’re a Scrum Master or Agile Coach who was brought in to assist a team embarking on a large and complex project. You’re new to the organization, perhaps even to the line of business they’re in. You feel like you need to get up to speed quickly so that you can start contributing effectively, and your years of experience have taught you that every organization and every team is unique. You understand that for you to truly create value, you need to capture the unique context of the team and organization you’re now supporting – that is, you need to develop situational awareness. You need to understand what it means to be where you are, the people with whom you are working, and the history, people dynamics, complexity, and many other nuances of the team and organization.
And to be clear, here I’m not talking about project Inception/Inception Sprint/Sprint 0/Project Kick-off, etc. All of that comes later. Rather, the focus of this article is YOU – ensuring that YOU have a systematic way of acquiring, analyzing, and compartmentalizing the information you need in order to understand your surroundings well enough so that you can start contributing effectively to your new team and organization.
This effort to develop a broad understanding of your new environment could also help you (and your team) design a fit-for-purpose project initiation (inception/kick-off) process that leverages what has already been done in the past to develop a shared understanding of what needs to be done in the future and identify areas where the team needs to pay special attention. Have there been customer interviews conducted in the past as part of an effort to envision what an enhanced version of the existing product would look like? Were there any agile success stories from other projects in the organization that could be used as part of your ‘hearts and minds’ campaign to help foster an agile culture and mindset? Have there been any efforts to map the end-to-end flow of work as things stand now? Etc. Content that has already been developed - perhaps for different purposes, be it maps, artifacts, retrospective summaries, etc. could streamline many activities during project kickoff and throughout the project.
Figure 1: Assessment areas to understand the project context
Understanding the context means seeking answers to 4 main questions:
Who are the people involved in this effort? Who will be impacted (internally & externally)? what are their roles, needs, motivators, influence, hopes, concerns, stories about past projects, level of enthusiasm, etc.? Have the members of the core team been recruited yet? If so, who are they? How familiar are they with agile?
What work have we already done to understand the current state of things (the situation that the new project will hopefully improve upon)? Have we done any previous customer research/interviews, research on usability, value stream or end-to-end process mapping done that shows how work currently flows within the different systems, what the pain points are, journey mapping, any work with actual end-users to understand their current pain points/frustrations, etc.? Have there been any retrospectives or similar workshops in the near past to discuss what is working well and what is not? Can we leverage some of that work as we initiate our agile project?
What work have we already done to envision the future state? Have we done any visioning/discovery work already – possibly as a prelude to writing the business case? Do we have a clear understanding of what the expected outcomes of this project are? Have we discussed the scope & impact of change? Were there any workshops scheduled to discuss (even on a high-level) any proposed/preferred approach to platform consolidation & data migration? Can we leverage some of that work as we initiate our agile project? Do we have a ‘task force’ of early adopters that could help?
What is the background (of the project, organization, team, etc.)? do we have a track record with Agile projects of this size? Do we have ‘lessons learned’ captured from previous projects? How mature is our agile practice? What is our level of understanding/familiarity with agile concepts? What is the culture of the organization like (e.g. do we have any employee satisfaction surveys etc. that could provide an insight into how things are done)? Have we done any organizational culture assessment/modeling in the past? What is our track record with the vendors/partners who will be involved in this project? Are there any organizational tools/platforms we can leverage (e.g. online training platforms, knowledge bases, internal wikis, etc.)?
Figure 2: Context assessment – workshops and interviews
But what does that actually look like in real life?
What follows are real-life examples of how asking these questions helped me develop situational awareness as I engaged with a new team not too long ago (Pre-COVID).
Here’s a bit of background: My client, a large bank, undertook an ambitious project to completely revamp some of their main digital offerings. The organization, a 100-year-old institution, had a short and rocky history with Agile, but the new technology leadership team were adamant that Agile was the way to go.
I will go through how I applied the 4 broad areas of contextual assessment to develop a good enough understanding of the situation.
1. Learn About the People (Who Is Who)
Figure 3: People Category Assessment Dimensions
Dimension |
Assessment |
Goals, hopes, fears, concerns, enthusiasm for the project, optimism in success |
Alarming – overwhelmingly negative outlook, some stakeholders announcing that the successful delivery of the project will “hopefully put [another group of stakeholders] out of a job” |
Clarity of responsibilities of the different team roles |
Alarming – confusion over the different roles & who does what, organizational history of power struggles in similar sized-projects, distinct ‘us-vs-them’ language in referring to other stakeholder groups |
Familiarity with Agile across the board |
Little – most members of the wider team indicated that they had a vague idea about agile, a few had been involved in one or two agile projects in the past that went sideways and helped foment a sense of cynicism and distrust towards agile. Project leadership and stakeholders were open about the fact that Agile was ‘forced on them’ from the top, while most stakeholders expressed concern in what they believed was Agile’s “lack of rigor” |
History of prior collaboration among the group |
Most team members and stakeholders had a history of working together on 2 previous projects that were not successful for myriad reasons. Past conflicts did not seem to have been effectively resolved, which was manifested in how many of the people I interviewed spoke about their colleagues |
Faith in leadership & direction |
The project manager was new to the organization and most of his professional experience was in a different industry, and many were open about the fact that they did not have a lot of confidence in his leadership |
The assessment results above show that there was an obvious boiling tension that threatened to explode during project kick-off and beyond that would have jeopardized the entire project. Understanding this, and designing events, activities, and exercises that would help the team deal constructively with the lingering tension is the only way to achieve the outcome we desire and set the team up for success. The traditional team initiation events that work well in other environments and with other, better-adjusted teams would not have worked here. Again, coming to this realization was only possible because of this essential contextual assessment.
2. Learn About the Work Already Done To Analyze the Current State
Figure 4: ‘Current-state’ Category Assessment Dimensions
Dimension |
Assessment |
A shared understanding of the end-to-end process representing how we currently do things, mapped as an end-to-end process map, identification of any process inefficiencies, pain points, etc. |
There was no shared understanding of the end-to-end process. Stakeholder groups were mostly familiar with only their part of the value stream, but not the whole picture. Each group was familiar with how their part could be improved/pain points to be addressed, but not with how this would impact the overall, end-to-end process |
Availability of recent customer research, interviews, customer journey maps or empathy maps, identification of customer pain points/what customers & end-users would like to change about the current system |
None was available – the ‘customer-centric’ approach was new to the organization, and as such little regard was given to studying the user experience up close. The majority of the wider project team were not familiar with the concept of the customer journey and challenged the notion of the importance of a good user experience |
Availability of system usability assessment/survey results |
|
Availability of technical/architectural assessment of current systems, any identified weaknesses or pain points, security assessment, etc. |
The information security team had prepared an exhaustive analysis of the security issues present in the current system, and there was general consensus that the messy architecture was the result of years of neglect and modules being added on top of existing modules with little regard for the soundness of the overall architecture of the system. A workshop was held a year prior to my joining to discuss what an overhaul could look like, but no documentation of that workshop or any outcomes was captured |
Previous efforts towards improvement via retrospectives, problem-solving workshops, etc. |
Only the architectural brainstorming workshop mentioned above (alas no documentation). I was told that there were numerous attempts made in the past to address some of the persistent problems customers & other stakeholders faced, but no documentation survived |
As mentioned earlier, it is important to spend time understanding what work has already been done so that we do not end up reinventing the wheel. I have facilitated Inception Sprints/kick-off workshops where the team, division, or department had already done impressive value stream mapping, for example, or had previously spent considerable time and effort understanding and analyzing customer behaviors, patterns, etc. In situations like these, it is obviously prudent to start where previous efforts have stopped rather than re-do the whole thing all over again.
With this team, however, no such work had been undertaken. No customer research or analysis, no effort to share a common understanding of the challenges and impediments facing the end-to-end flow of work, and a little reflection on the technical design of the existing solution. All of this will have to take place during the kick-off.
3. Learn About the Work Already Done To Envision the Future State
Dimension |
Assessment |
Clarity on expected outcomes (definition of success) |
Business case had what its author described as wild financial forecasts – numbers that others I interviewed seemed dubious about. Nothing on the impact on user experience, customer satisfaction, operational metrics, etc. |
Clarity on any discovery/visioning work done, customer research etc. |
No such work has taken place |
High-level understanding of possible options to achieve platform consolidation |
A few high-level workshops had already taken place with project architects & developers brainstorming options with the organization’s technical leadership (chief architect & chief IS architect), but true to the organization’s siloed culture, no representatives from the business side were present – consolidation isn’t solely a technical problem |
4. Learn About the Culture and History of the Project & Organization
In addition to attempting to understand people's dynamics and the team’s perspective on the problem the project is expected to solve and what a successful solution should accomplish, I put a special emphasis on learning about the background & culture of the team, division/department, and organization. This helps us maximize the value we get out of project kick-off by customizing activities that address specific organizational problem areas and leverage the particular strengths of the team or organization. Here is an example of how trying to understand the culture of the team I had just joined helped curate parts of the kick-off process:
Figure 5: ‘Culture and Background’ Category Assessment Dimensions
Dimension |
Assessment |
Track record with Agile projects |
Only a handful of agile projects within the division – almost all have largely been considered failures. The failure was mainly blamed on Agile and there was a general impression that agile just does not work for complex, high-stakes projects |
Familiarity with agile principles, practices & mindset |
Minimal – a few team members & stakeholders had been involved in agile projects, but in one-on-ones, everyone (100%) were clear that they knew very little about things are supposed to work in agile, and the little they knew didn’t fill them with confidence |
“Lessons learned” captured from previous projects – agile or waterfall |
Although capturing lessons learned as part of the ‘close’ phase as defined by the PMO’s project management standard process, no project – agile or not – captured or documented any lessons learned. The team members and stakeholders I interviewed were happy to share anecdotes from previous failed projects (and a few successful ones) |
What the culture of the organization in general – and the division in particular – is like |
Reading anonymous comments from recent employee engagement surveys, and from my one-on-ones with the team, it was clear that the strongly hierarchical, command-and-control nature of the organization and lack of psychological safety would pose a real challenge to the team as we embark on a journey to be agile |
Relationship with (and track record of) the partners/vendors involved in this project |
The relationship was described as ‘difficult’ by almost everyone I spoke with. The vendor, a global IT sourcing company, had a long and complicated history in the organization with a few recent high-profile failures. The personal relationship between the vendor account managers and project leadership was fraught. The vendor was also known in the market for not getting agile – relying on heavy upfront planning and not engaging customers and end-users enough |
Experience with (and attitude towards) remote working, remote workshops, and tools |
Minimal – except for the occasional meeting participant joining over Skype, the organization had difficulty embracing working from home, which meant that most team members, stakeholders & partners have never been part of an intensive collaborative effort done completely online. The organization had a strict policy restricting the use of popular online workshop facilitation tools unless explicitly vetted by the infosec team |
My one-on-ones and the information I gathered helped pinpoint special areas of interest where a lot of attention needs to be devoted during project kick-off and later throughout the project. As I mentioned earlier, investing in this sort of high-level assessment helps ensure that project kick-off will be a success.
Opinions expressed by DZone contributors are their own.
Comments