Welcome to part 6! You are either at this point deeply invested in this thought process or you’re really running out of things to distract yourself while browsing the internet. Either way, welcome! Here’s where we’ve been so far.
- Aggressive and Invested Requirements Gathering
- Relentless Ideation
- Atomic Preparation
- Torrential Communication
- Constant Collaboration
Everything we talked about last time with Constant Collaboration is focused heavily on actions, but today is a lot more about culture and attitude. Accountability is often a word that comes with a lot of baggage, but it doesn’t have to. Making it constructive can change the whole picture and actually make you grateful for the accountability in place because ultimately, it makes everything and everyone better.
You may be shocked to the point of spilling your coffee on your laptop while reading this, but again we’re covering 3 important concepts that help build Constructive Accountability.
Peer review is one of those practices that sounded kind of annoying when I first had to do it and now I utterly depend on it. At Ashday, we basically kick each task ticket (which is small because of concepts discussed in the post on Atomic Preparation) into QA where another developer, when between tasks, will pick it up and test it. This is mostly about functionality, but occasionally digs deeper into code review, and is a fantastic tool for both keeping developers fresh and also always having two sets of eyes on all the modular pieces that make up the whole. It also levels the playing field a bit because - let’s face it - not everyone tests at the same quality. This is also why Torrential Communication is so important throughout because you can’t really test something if you don’t know all the requirements and you don’t really grow without feedback on what you’re doing.
Solutions over problems
This is really just a mentality, not a task - but it makes a big difference. Part of the reason it’s on here is because I’m constantly reminding myself of this as it’s hard to do. It’s very easy to get caught up in what’s going wrong, who caused it, etc, but the best outcomes very frequently come from “Ok, let’s learn from this and quickly move to solutions and growth.” So how does this manifest itself? Well, at Ashday we rarely use GIT commit history to find out who did something that went wrong unless we need to find out when it happened or maybe why. We don’t witch-hunt. The best thing is to simply respect each other, trust your team, and figure out what needs to happen. This means in a pinch, a developer who finds a bug in Peer Review may just fix it and then notify the original developer to keep them informed. Sometimes we’re not sure where the bug was introduced, but we just move forward and solve the problem. In general, it keeps everyone’s spirits up and it allows us to be more transparent about problems we find because there’s a confidence in knowing that you aren’t immediately on trial.
Now this all presumes you have a good team. Sometimes there are weak links and there should be a process for evaluating that, but that shouldn’t translate to a general culture of blame and shame. Good workers will self-generate enough shame (and respond positively to it) without making it a group attitude. Embarrassment is not a reliable tool for team-building and some personalities crumble underneath it.
When you focus on solutions over problems, that allows a sense of shared responsibility. It’s not “your bug”, it’s “our problem.” It’s not “my idea” and “your idea”, it’s our collaboration to come up with a solution. It’s our project and we all benefit when it goes well and we all suffer when it doesn’t. So this means that I’m actually happy that “you” found a bug in “my” code and fixed it because that helps everyone. It also means that I might go over on my ticket estimate to tend to some important things that I didn’t cause, but I let go of my personal pride and do it for the sake of the project and team. Again though, I know I’m not going to get intensely scrutinized at every turn which gives me the freedom to do that.
Shared responsibility also means that if requirements were too fuzzy, we don’t just blame the project manager, we also look ourselves to see if maybe we didn’t ask enough questions before beginning work. Similarly, we don’t just blame the developer for missing the requirements, we also reflect on how the sprint was kicked off or the ticket documented to think about how maybe it could have communicated it more clearly. Again, we share in the responsibility to build something great.
Next time, we move into the last phase of the project. Because we’ve come this far, why trash it now? We’re going to talk about how to land the plane safely and with high passenger satisfaction, starting with the idea of Immersive Demonstration.
NEXT UP: Web Design & Development Process: Part 7 - Immersive Demonstration