Let’s quickly recap how we’ve gotten to this point.
- Aggressive and Invested Requirements Gathering
- Relentless Ideation
- Atomic Preparation
- Torrential Communication
If you hadn't noticed, this whole series of 9 articles is really organized into 3 distinct areas: (1) getting the project off the ground, (2) the build out, and (3) the close out. The first three articles of the series focused on part one and we're now in the middle of the build out phase. We kicked off this phase last time with Torrential Communication and continue on now into the part where you actually do stuff. Today it’s about Constant Collaboration.
By now you realize that none of this is rocket science (this is harder), but there is still a fine line between doing these things well and doing them poorly and that can have an exponential impact on the project. Here are three ways that we try to ensure that our collaboration is legitimate enough to actually produce the fruits we’re after.
There is always a debate about redundancy versus specialization, but it always leaves you feeling like you want both. You don’t want to be redundant to the point of waste, but you don’t want to be specialized to the point of single points of failure. Sharing knowledge is a great middle-ground because the idea isn’t that everyone is fully steeped in everything and an equal expert on all areas - it just means that those things that a team member knows more about are on some level communicated with the rest of the team, which has a great bang-for-the-buck value. I might spend two days figuring out DFP integration, but I can spend 30 minutes reviewing the solution (and the decision making process) to the team and now everyone feels a lot more comfortable if they need to fix a bug or make a change and they also have the benefit of awareness of the existence of something that may impact or be impacted by the component they’re working on. Over time, this also raises the whole team’s skill set because while one person may focus more on databases, another on front-end theming, and another on web services - they all have a sense of what everyone else is doing and become naturally more flexible members of the team.
Combine Work Frequently
On a pragmatic level, we find merging our work frequently to be tremendously effective at identifying issues earlier and raising awareness. Everyone working in silo mode for 2 or 3 days and then merging can take hours to unravel sometimes, especially considering the tricky nature of Drupal 8’s new configuration management. This is made much more possible by Atomic Preparation, but can be done in any system. Yeah, ideally we aren’t pushing code that breaks things, but that’s why we want to build smaller, modular pieces so that you don’t have to finish 30 hours of work to then find out if you have 12 code conflicts with your teammates. This is also a great feedback loop because people tend to notice early on when someone does something they don’t understand or find strange. It also allows us to program a lot closer to a corporate standard, which makes editing someone else’s code a lot easier.
Touch in Constantly
This may appear to be implied by the other topics above, but it’s pretty distinct. Yeah, you might see other’s code frequently or talk about approaches frequently, but there’s also the element of just regularly “touching in.” As mentioned in Torrential Communication, regular standups and sprint kick-offs and retrospectives are important, but so are check-ins on individual work. One way we’ve implemented this concept is to follow the idea that if you are somewhere close to half your ticket estimate, you should have a decent sense of how good things are going and should pull in the team lead if you are in doubt. This is a chance to help boost the efficiency of things before it’s too late (ie: I’m 10 hours in on an 8 hour ticket and no where near done). Usually, it just takes a set of experienced eyes to adjust direction or free up a sticking point to get progress back on track. Otherwise, it might actually mean that we underestimated or under-communicated and expectations need to be adjusted. Again, all perfectly fine to do with smaller, modular tickets and before all the time has been spent.
The other half of this is that we really encourage people to pull others in as they progress if they want to run an idea by someone else or need help getting over a hurdle. A 5 minute loss of efficiency on my ticket to help someone else solve a problem they’ve wrestled with for the last hour is a worthwhile trade off. So touching-in from team to team lead or else just across the team are all highly encouraged.
Whew! The rate at which we’re blowing through this approach to project management really makes it start to seem easy! Actually, next time we’re going to slow down and talk a bit about some of the culture that needs to be built to foster this process because actually, it’s all a lot of work to pull off and it would be nice if we didn’t crush each other's hopes and dreams in the process. Next week is Constructive Accountability.
NEXT UP: Web Design & Development Process: Part 6 - Constructive Accountability