Track and document your QA process with zipBoard
Sign up and start collaborating with your team! No credit card required.
09 Sep
People are the best and the worst part of a team. That may sound harsh, but people are what make a team tick and people are what complicate its working most. So much of project management is about getting it right for the people, more than getting the technical side of it correct.
We’ve heard it a million times you need to find the right people for your team, not the best people. But even with the right people, team success is not guaranteed. Every team has different personalities. Team members are different when it comes to thought process, work-ethic, problem solving and their approach to collaborating within the team.
There is no ideal size or setup for a team. Tech organizations are still experimenting with how best to create a team and how to set them up for successful functioning. Whether you’re doing lean or agile or waterfall or what not, the bottom line is that you cannot have a team functioning without definitions and strategy.
I came across this great post by Jason Fried on Signal vs Noise, describing how the Basecamp team is set up and how they work. The first thing that struck me was how well it documented the thought process and rationale behind their team setup and strategy. I greatly admire the work culture and level of transparency at Basecamp, but more than that I admire the fact that Jason Fried chose to make such a concentrated effort to put everything their team does into specifics. I believe it reflects the in-depth understanding of project management and processes that every part of the piece is so clear about Basecamp’s policies.
For a quick summary, here is how Basecamp breaks down its work:
- Each development cycle is six weeks long, with some flexibility over how to adjust depending on priorities and requirements.
- Every feature to be added either goes into a major list (the Big Batch) or a minor feature list (the Small Batch). A single Big Batch feature may last the entire six-week cycle while 4–8 Small Batch features are tackled during the six-week cycle.
- Each team is made up of either 2 people (1 programmer + 1 designer ), or 3 people ( 2 programmers + 1 designer). Nevermore than that. This way teams stay clear of complexity.
- People elaborate on ideas for features in the form of extensive pitches before the cycle begins and which pitch is selected for the lists depends on Jason (CEO), David (CTO), and Ryan (Strategy).
- Before each cycle begins, all pre-planning is as detailed as possible and tries to scrutinize every aspect of the project. Between each cycle, the team teams take a 1–2 week break to recalibrate and work on future strategy.
This is an abstracted walk-through of the process but gives an idea of the clear and concise project management skills in place. Of course, this approach cannot be adopted for every team or organization and indeed, Jason Fried admits there is “more art than science” to this method. But the idea that I’d like to focus on is that this art is not arcane. It can be initialized, instituted, refined and adapted for individual cases by putting in place a system where documenting the process is a crucial part of the larger picture.
The other thing of note is the level of fluidity and room to maneuver provided for teams. Having small teams is a big boon to ensure a flexible approach. Also having short cycles of development (like 6 weeks in Basecamp’s case) ensures that resources are not locked in for a very time in one place. The fact that even teams are assembled ad-hoc based on areas of interest further reflects the flexibility of operations.
The strategy you put into place to support your team is so important to how productive your team will be, especially in the long run.
There are a number of benefits of doing this:
Clarity for the team
One is that you clarify the process for everyone on board. Whether that’s an existing team member or a new hire— everyone has a clear understanding of what the steps are and what the expectations are. If the team is an active participant in defining the process the adoption of the process is much easier.
Long-term planning
Hindsight is 20–20, but that doesn’t mean foresight cannot be refined as well. Long term planning can be efficient if the start and end points are predefined. Working towards satisfying different customer needs and prioritizing various product features inevitably leads to teams needing a process which is flexible and scalable as per needs. Whatever development model a team follows, planning for expected hiccups and bumps along the way is a good idea in every case. Resources are easier to allocate and objectives & key results (OKRs) can be set.
And yes, I can imagine not every team will have charted out plans for months or years ahead, especially given how volatile the technology landscape is today, and how quickly requirements can change. But the essence of long term planning is not deciding point A, point B and every minuscule step in between, rather anticipating direction and goals in the broad sense.
Where can it go wrong
By articulating one’s own process, teams are forced to examine the pros and cons of it. Once it is solid words on paper that you have to explain to others, you start to see the loopholes and missing pieces that you hadn’t anticipated before. This is where you can refine the process over many cycles. Discard what isn’t working and figure what sticks best for your team. With each new iteration, the time it takes to define structure will reduce while you’ll be moving towards a higher output from your development cycles.
A quote that some attribute to Einstein while some to a Yale professor gets it all too well:
“If I had one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.”
Final Thoughts
If you think a project management software will solve your issues, then you’re missing the point. Having a good software for project management is not an end-all solution for charting out your team’s processes.
Adding to the chaos of an undocumented and undefined strategy is the rapid deployments that teams strive for in the current technology landscape. Imagine the bliss of a time where teams worked in isolation without interruptions and distractions. Now think about users popping up in that bliss to tell you continuously what’s wrong or what more they want to see. The bliss then has deadlines and deliverables that spiral out of control pretty quickly.
Also, in no way do I advocate sticking to a capital letter process like waterfall or agile for each and every scenario. What I merely advocate is a defined structure within which a team can do its best work — whether that’s following Google’s Design Sprint model, or Eric Ries’ Lean UX approach, or coming up with what works best for your team.
Iterate on your Organization, just like it’s a Product
Kudos to Jason Fried for sharing Basecamp’s process. The part that I have not mentioned till now is that Jason admits it has taken them a decade to refine this process. It’s never too late for your team. You can start working towards defining and planning better as well. If Basecamp’s success is a good motivator for starting your journey down this, then consider Jason words added juice when he says (and I’m paraphrasing a little), think of your company as a product too; just like iterating on a product, iterating on your company’s processes can help to find new ways to improve how you work.
Is your team struggling to collaborate effectively? If web development collaboration is your team’s issue, zipBoard is the answer for it. Design feedback, review tool, project management and tracking tasks — all in one. zipBoard is the tool for getting all stakeholders in sync — whether that’s managers, developers, designers or QA testers.
©️ Copyright 2023 zipBoard Tech. All rights reserved.