Being Flexible in the Face of Agile

Using Confluence and a Person-First Process to Manage Complex Projects

Part I

By practice, Agile development is held up by two key pillars: collaboration and iteration. These foundational elements allow teams the safety-net of plan and process, while also bringing in an iterative workflow which is hard to find in more traditional Waterfall methodologies. Yet within the safe space of this malleable home, there seems to be a constant problem facing teams using this framework: flexibility. Surprisingly, and almost completely counter to its intention, Agile frameworks buy into a “bend don’t break” planning process, allowing its flow to only shift in the face of a major change in priority or philosophy. For example, say your intention is to build an app that helps a company settle their expenses. During development of the settlement features, you determine its first necessary to chart the sales activity that led to these settlement practices. As part of Agile’s core functionality, this change is a simple one; a simple definitions requirement meeting, planning session, and restructuring of resources is all it takes to make this change. But at its core, these activities require a fundamentally non-organically human mindset of flexibility. To shift priorities after months of development work means to change learned daily actions by developers, most of whom spent most of that time learning the requirements to build a functional solution. Shifting these priorities brings in a human element of change that is quite difficult in project planning. As a project leader, how do you not only plan for a material change, but also a mental change? My goal in this article is to give you tools and tricks to stay one step ahead of the change, allowing you to bring the flexibility back to Agile.

Successful Agile Development Requires a Person-First Process

Just as any team is only as good as the sum of its parts, such can be said about a process and its inputs. By extension, all the inputs to a process must be managed by a set of officers of said process. Want to increase development time-to-market? Shorten the flow of completed object to quality assurance. Want to improve stakeholder communication? Set up standard operating procedures to properly direct information. In both scenarios, the process update requires a unit of change occurring at the initial input: the person.  While we as project managers are comfortable dealing with these units of change in all steps of the developmental process, we often forget that the key cogs in these processes are people who can choose whether they follow the agreed upon frameworks.  Setting up a proper quality assurance flow means nothing if those managing both sides of the flow fail to act in the proper method. And therein lies the question at hand: If a tool’s responsibility is to improve a process, and you are the one responsible for the tool, are you then by extension responsible for the person at the other end of the process? The answer is fundamentally, yes. To properly manage a project is to properly manage the individuals with the same care and concern that you manage the inanimate inputs. This is not meant to be a ground-breaking directive—of course the human element is important in project success—rather a call to manage change at that person level. Let’s revisit the example above involving the shift of priority to charting sales activity. A proper flow of events involves an initial discovery session to uncover the new necessary outputs, a gathering of steps required at the inputs to ensure those proper outputs, and a delimitation of tasks across the product team. All-in-all this process is straight-forward, not necessarily time-consuming, and quite manageable for a single project manager. That is, until you understand the need to manage at a person level. The initial discussion around outputs now must involve a full scraping of knowledge gained by the development team on their previous directives. Questions such as “how did your current work uncover the need for a shift in priority?” or “what knowledge-gaps do you currently have that would prohibit you from shifting priorities?” are now vital in ensuring the project team feels connected to this shift. This makes the input gathering extremely straight-forward as the initial step came with a team “buy-in”. If the development team buys into this notion that the project necessitates the collecting and curation of sales activity in order to unlock the settlement processes, the developers will not only attack this new initiative with a plate full of information but also with an excited vigor; “I can genuinely impact the success of this project”, they would say; “I am excited and motivated to move forward”, the unspoken driver for their development. As shown above, this person-level development cycle must begin at the initial requirements definition stage. After answering the basic iterative questions— “Is my project still on track?”, “Will a change on one end impact a requirement on another?”, “How will my project shift if I were to have to rebuild a component?” — the project manager must decide whether to include the development team in the initial requirements gathering. Throughout managing projects for my clients, I’ve had the opportunity to speak to several Project Managers who swear by this notion: “Keep the project flow separate from the development flow”. In other words, let the developers develop and the managers manage. While a sound theory in the growing world of matrix-based organizations, this notion, in my opinion, is fundamentally wrong. Notwithstanding the slippery-sloped nuance that comes with any discussion around siphoning of information, to block off the team in charge of enacting change from the room in which the change is decided is precisely what causes the frustrations of being a part of a project team with ever-changing targets. How can I, as a developer, be fully capable of developing, if I’m not aware of the potential shifts ahead? I’ve experienced several situations where a shift in priority was discussed without the Lead Developer, Lead DevOps & QA engineers, nor any of the Development team present. The shift was completely necessary, in theory minimally impacted the project, and should have been able to be completed without any change of resources. But in each of the cases, the project was delayed by at minimum a month; additional meetings were needed to explain the basis for the change, the developers needed time to re-learn the internal mechanisms, and not surprisingly, the overall team morale was damaged. If I am required to enact change, shouldn’t I be a key player in the discussion of this change? If we had simply taken the time to intelligently involve the development team in the change process, the project would have stayed on track and the team morale would have been at an all-time-high. Agile is meant to be a flexible, iterative process, but unless the human inputs are considered when making change, the flexibility will only work in theory, not in practice. It is your role, then, as the Project Manager to introduce flexibility back into Agile.

Part II

How to Accomplish this in Confluence

Up to this point, we’ve talked through these situations philosophically, but how does one tactically accomplish this new form of “open management”? Almost all project management software has what can be referred to as a “collaborative documentation center”. These areas can be used not only for requirements definition, but also for project charters, team availability charting, meeting notes, and focus groups. For the purpose of this article, let’s focus on Confluence, an Atlassian product tied into Jira, that is commonly used in Agile projects. A good way to start is to ensure a strong project charter always guides your decisions. What was our agreed upon end-goal at the start? How does this change of activity impact the stakeholder’s wants and needs? Confluence makes it easy to organize your thoughts in pre-made templates, like the “Project Plan” template below:

Including the development team in the production (or presentation) of the project charter is a vital step in connecting to the “human” side of the development: If they are more aware of the overall goals of the project, they are more likely to feel accomplished when working toward them. This project charter is especially important as we get deeper into a project, especially when it comes to scope creep. If our activities are nominally contrary to the initial goals set-forth, it should not be completed unless you are willing and able to alter the initial project charter. Put more simply: If a change in priority requires a change in the original project scope, the necessary steps must include the stakeholders who impacted the initial charter. This shift of priority is one of the major causes of developmental stress within a project, and it’s not for a reason you might initially guess. Yes, fundamentally, changing the focus of an entire project is stressful, but the stress is more tied to a positive eagerness to begin, or a negative nervousness to absorb all the necessary new information. And because of this, it’s when these shifts occur in a vacuum that the development teams begin to freeze. If the development teams are not included–at least tangentially—to impactful project scope discussions, the team’s psyche will be impacted, and the timeline will greatly suffer. So how does one “include” a team who is inundated with daily developmental work? By utilizing tried and true decision-making practices found in tools like decision matrices. These tools help organize thoughts, look at the pros and cons of any decisions, and, perhaps most importantly, attempt to quantify the impact of any changes to the project. Confluence provides a very handy “DACI (Driver, Approver, Contributors, Informed): Decision documentation” template, which can help guide both the decision making process and the roles associated with that process.

The key differentiator between this type of decision making process and others is the incorporation of the project roles into the process. How am I, the developer, or I, the project manager, impacted by this change? Furthermore, how do I impact this change? This tool helps drive empathetic management by incorporating the human-element into the equation, in a way that goes deeper than just pure resource allocation management. This unlocks a true collaboration that is a key to success in an iterative environment. To truly succeed in an Agile environment, all decisions made must be properly scrutinized to achieve replicable success. If decisions are made in vacuums, this hurts both the development team and the health of the project, as iteration requires collaboration. Which leads us to another key step in unlocking flexibility in an Agile environment: the retrospective. Often maligned—and usually skipped—this process is an inclusive way to improve processes, remind the team of directives, and speed up overall development work. The retrospective can be done in any way that fits the team, but Confluence has a nice “Start, Stop, Keep” model for you to organize your retrospective thoughts in the “Retrospective” template:

Using Story Linkage to Keep Developers Up-To-Date

While I can comfortably say we’ve covered physical steps you can take to keep your project team informed through the plan (project charter), decision (DACI matrix), and reviews (retrospective); we are still missing a fundamental cog in this information journey: You, the project manager. For, as you may already know, there is a fine line between keeping the team informed and keeping the team overinformed; the difference between an eager ear and a tired one. You play a vital role in the empathetic execution (trademark pending) of the project, and you can accomplish this through three key steps. Step 1: Do the dirty work. It may not sound that important, but if you can stay on top of the flowing winds of information, you can significantly impact a developers’ ability and interest in completing a task. Take the extra time to take notes in the meeting. Update the stories with detailed information. Link the information to the proper meeting note page in Confluence. As you can see below in a Jira story example, its okay to go a bit outside the box and provide information that may not perfectly fit into the way you normally write stories if it provides an additional level of detailed needed to complete a task:

Step 2: Pre-Plan. Pre-Plan, Pre-Plan. This encompasses everything from refining the backlog, to setting up the planned sprint before sprint planning, to organizing stories by assignee, epic, and estimated amount of effort. It’s natural to look at a list of developmental tasks and to think: “I don’t know enough details to be able to plan this sprint” … and that’s okay! The more information you provide ahead of time, the more time you can spend discussing with the developers the tasks at hand and less around them trying to figure out where capacity should be focused on. By providing a framework, you are allowing them to express their opinions, which simultaneously helps you to fill in the blanks. Trust me when I say that when you fully buy-into the notion of the “Pre-Plan”, you not only save a significant amount of time, but you are able to describe the necessary task more accurately. And Step 3: Actively Listen. Listen to your team. Listen to the stakeholders. Listen to the developers. When you become an empathetic listener, you begin to lead naturally, and your team trusts that you have their good intentions in mind.  Then, when you have fully felt the air of the team, you begin to implement the active side of the coin. Your listening births ideas and your questions uncover new ways to solve problems. When you ask your team for input, they give it to you knowing that it won’t just die there, it’ll blossom into something else. By asking for help or clarification you are putting your team in a position of trust: they must trust that you are asking to help them, not to save yourself the work. In a project where change is in the air, this final step of trust is truly what unlocks the flexibility you seek. Because when your team trusts you, any change that comes your way can be dealt with logically, efficiently, and empathetically. And at the end of the day, that’s what it’s all about.

Scott Hakim, Senior Consultant

Sources

Note: All templates are available through a confluence cloud or server license. You can find out more information here: https://www.atlassian.com/software/confluence