The Art of Project Management

Generally speaking, one of two things happen when we talk to our friends, families, and sometimes even clients about what it means to be a project management at a software development company: 1) their eyes glaze over, and they politely say: “Ohhh, good for you!” or 2) their eyes glaze over, and they politely ask: “But what do you actually… do?”  And you know what?  We don’t blame them.  The idea of project management applied to the complex and sometimes-insular world of software development can be hard to grok for someone not already steeped in our ways.  So pull up a chair as we explain what it is that our project managers do - how they add value to projects, and along the way hopefully demystify some of the tools and concepts that we leverage here at BRS in order to help our clients be as successful as possible.

Building Process

As we approach each day, we remind ourselves that at the core of project management is communication, efficiency, and transparency.  (Good PMs are also concerned with other important factors which all conspicuously start with the letter M, like minimizing risk, mitigating technical debt, and managing expectations, but for the sake of this primer, let's keep things straightforward.)  Everything that our PMs do on a day to day basis is ideally done in service of this trifecta.  “But,” you rightfully ask, “how do you actually do that?”  The answer: We build process!  By building and maintaining processes that everyone subscribes to, we help ensure that teams do their jobs to the best of their ability, while sidestepping endemic roadblocks like ambiguity, miscommunication, misaligned expectations, and scope creep.  

Now, we wish I could take credit for redesigning the wheel for each new project in order to build said process, but the reality is that BRS relies heavily on a few institutions for software development teams: Agile, Scrum, and Kanban.

Agile

Terminology is often a barrier to entry, so let's take this opportunity to quickly break down these concepts before I talk about how we use them at BRS to set projects up for success:

Agile is a philosophy that was collaboratively established in 2001 as a rebuttal to traditional project management practices (collectively referred to as ‘waterfall’).  The simplest way to differentiate the two is that Agile privileges constant iteration and collaboration rather than a rigid process with one final deliverable handoff.  The fundamental principles behind Agile are incredibly succinct, and we encourage you to read through them.  Kanban and Scrum, described below, are methodologies that give us the tools to put Agile principles into practice.

Kanban, Japanese for the card at the heart of the Kanban board, gives us a way to visualize, prioritize, and track all of the work for a given project. Staying organized using Kanban boards helps us control in-progress work to keep things manageable and productive for dev teams, and it promotes transparency by making it very easy to understand where different features are in the development pipeline.

Lastly we have perhaps the most well-known Agile methodology: Scrum.  Scrum is another framework that empowers development & product teams by structuring their meetings, defining roles, and introducing other core concepts like the product backlog, where a prioritized ‘wishlist’ of yet-to-be-developed features live, and sprints, which are increments of work within which the development team has clearly defined goals.    

We love when a plan comes together!

Alrighty, now that we’ve discussed our project management goals (build process to promote communication, efficiency, and transparency), and introduced some concepts to help facilitate said goals, it’s time to talk about how we put all of this in motion.  As we move forward, it’s important to understand that our clients are our product owners - that is, they are the ones with the vision of what we’re building - and as such take a crucial and active role during every project. Ensuring that clients understand this role, and their responsibilities throughout the project, is a very important piece to the PM puzzle.  At BRS, we boil the project lifecycle down into granular iterations, but project management focuses remain consistent: educate, coordinate, document, and help maintain momentum.  Let's dig in a bit further.

Educate

Many of our clients don’t have a background in software development, so it’s important for me to be an evangelist and advocate.  Clients will be sitting in on demos, sprint reviews, managing a backlog, and regularly adding clarity around design and definition, and we love this constant communication. It’s what makes us so successful! Heading into a new project, our PMs are the go-to resource for questions regarding process, implementation, or simply: “I don’t know who to ask, but here we go...”  

COORDINATE

The other half of process education is its actual design and execution. We’ll work together to determine sprint length, set cadences for sprint reviews, retrospectives, and demos.  We’ll define workflows and communication paths for managing our Kanban boards, so you can see exactly what’s being worked on and when it’s ready for testing.  We’re here to make sure all of this happens in a way that makes practical sense for both teams, and to ensure that we’re agile when we need to be, and tweaking our process as necessary. 

DOCUMENT

Mentioning ‘documentation’ conjures up images of court stenographers and technical manuals, but in the software development world, good documentation means that our teams have everything at their disposal to create the best products.  Actionable info, is how we refer to it. In practice, good documentation means well-defined user stories, up-to-date Kanban boards, and a frosty backlog filled with regularly defined/prioritized work.  This is good documentation, and the resultant ‘everything in its right place’ feeling is one of the best parts of a PM’s job.  Don’t get us wrong - BRS will still build more traditional documentation as deliverables during different stages of our projects, but using our tools to their fullest potential to stay organized is a core part of process-based documentation.  

MAINTAIN MOMENTUM

In Scrum, one of the primary responsibilities of the ScrumMaster role (yes, that exists) is to remove roadblocks for team members.  We think about this often, as it’s also a core competency of our PM role.  Now, this doesn’t necessarily mean actually solving problems on behalf of team members, but rather ensuring that everyone has access to the appropriate resources, meetings, time, and problem-solving tools in order to to successfully detangle issues as they arise.  “Maintaining momentum,” in this context, can mean many things: it might mean helping a product owner define a particularly challenging feature.  It might mean facilitating an internal meeting with resources from another team who have important institutional knowledge to bring to the table. Maybe it means doing an organizational pass on a development board to ensure that we have traction on all in-progress work.  Perhaps it’s reviewing sprint reports and burn-down charts so that we have an eye on our team’s velocity.  Part of the fun of PMing is finding new and effective ways to make sure teams are rocking and rolling.

Wrap Up

And there you have it!  A breakdown of some of the responsibilities our project managers, and some tools that we bring in to ensure success. This is certainly not a soup-to-nuts comprehensive breakdown, and you still may be wondering exactly what a sprint is, or why keeping a backlog organized is so important to the success of a project, and that’s okay!  There are plenty of fantastic resources out there if we’ve piqued your interest, and hopefully in the meantime you’re able to walk away with a better understanding of the role project managers play at BRS.