Have you ever been on a project where no one seems to know what’s going on? Your team followed the Scrum process by the book and delegated tasks—and still, no one seems to know what to do next.
In the previous installment of this series, we stressed the importance of a rigid structure (sacred rule #1), whether you’re in an agile environment or in the jazz club. But you shouldn’t assume a project will succeed just because you have certified scrum masters on your team. Case in point: would you want the world’s best scrum master leading a construction project if he came from an IT background?
Sacred Rule #2: Know Your Genre
As project managers, it’s important to understand the nature of the projects that we’re leading. Our team’s success depend on the skills of our techies, developers, and other experts on our teams and leadership that can relate to them.
This doesn’t mean that if you’re managing a software development project, you should be able to program IBM’s Watson.
But, I will argue that you should have a basic understanding of how software development works (architecture, modular design, client-server models, etc.), or your project is in trouble.
Honing Your Craft
Going back to our jazz illustration: if you’re a classically trained musician, memorizing a couple sets of chord changes (sprints), such as the ubiquitous twelve-bar blues, isn’t enough to perform well with a jazz group.
In fact, most professional jazz musicians (like classically trained musicians) still practice scales, patterns, chords, licks, etc. six or more hours per day. An overambitious classmate of mine in music school even attempted an “Uberman” polyphasic sleep pattern so that he could practice nearly 22 hours per day – though he quit after falling asleep at his piano in the middle of a performance.
Similarly, project managers must devote the necessary time to studying the subject of their projects to remain in sync with their team members and to be able to work agilely in the long run.
Whether you go by project manager, ScrumMaster, or something else – if you’re running an agile project, you need to understand the “genre” of your team’s work at a deeper level than if you were to take a “waterfall” approach (a linear approach in which you plan the entire project out at the beginning so that all task dependencies, constraints, critical paths, etc. are laid out in front of the team).
If you take an agile approach, you speedily deliver fully-functional features in iterative sprints. As fruitful as this approach may be, you could easily fall behind on tasks if you neglect to study up on the overall topic of your project.
Let’s take a hypothetical example: You’re midway through a sprint in a web development project, and your client has requested changes to an approved wireframe. However, your developer has called in sick. Now, you must figure out how to move forward with the request and make up for lost time to later complete the Sprint Backlog.
It would help to know the following facts about the web development process, which almost certainly is NOT detailed on your Scrum board.
• The front-end developer cannot begin “Implement Custom Calendar CSS” until the backend developer completes “Install “Calendar Plug-In.”
• After the “Approve Wireframes” phase is complete, no more changes can be made to the wireframe layout, or else “Implement Homepage HTML” will have to be restarted.
• The “Install CMS Platform” task will take 4 hours no matter if one or four people are working on it. However, the “Upload Page Content” task can be reduced from four days to one day by adding three extra people.
Of course, you could convene the entire team to solve the problem, but as a team leader, you’d risk disrupting the team’s rhythm.
Even with the best project structure and individual talent lined up, whenever you have a lot of unique people working together, a lot can still go wrong. In the fourth and final part of this series, we’ll examine why it’s important to Work with the Rhythm of Your Teammates.