We're talking over the next few posts about the changes in mindset and procedures that become necessary when your development team grows beyond one or two developers. To wit, your mindset has to shift from:
"What do developers A and B need in order to be most productive?"
"What does our development team need in order to be most productive."
A good comparison is the difference between a local development environment which exists on a single developer's machine, vs. a production environment which may have a load balancer, multiple application servers, database clusters, a caching layer, and so on. There is a significant amount of additional coordination that comes with the complexity of the production environment. The same is true as you add more and more developers. Two developers could get by doing their own thing and only coordinating occasionally. Three, four, five or more developers will need some coordinating routines to make sure that they are working toward common goals.
First Things First
Almost without fail, the first thing that I help a team with is to start separating the planning of features from the execution of features. When I arrive, the Trello or Jira board is full of developer to-do items like "Create DB Model X" or vague feature ideas like "Users can invite other users to teams". This is understandable, as the dev board usually begins as a simple to-do list for a single developer. The problems with this approach are numerous, but we're just going to focus on just one in this post. Namely, it encourages a zero-forethought, design-as-you-go methodology. A single developer can often make this work because they have most of the project in their head, and the item on the board simply acts as a reminder of what needs to get done.
With multiple developers, however, all of the product and institutional knowledge that lives in one developer's head doesn't transfer to the developer who will ultimately take on that work item. What this means in practice is that the developer who takes on the work will be figuring things out as they go, encountering unanticipated complexity, possibly building abstractions that are redundant to those being built by other developers, and so on.
Add to this the fact that the requirements of the work item are vague ("Users can invite other users to teams" - Do the recipients need to accept the invite? Do invitations expire? Can a user rescind an invite before it is accepted?), and this work item could drag on for weeks before it is delivered. The developer is going to be making a lot of decisions as they go, filling in blanks with their own assumptions, and ultimately the delivered feature set may not resemble what the product team envisioned.
The Studio vs. The Factory
The solution has two parts. First is to move ALL of the work that has not yet been started to its own board. You can call this the Product Roadmap or the Release Plan or whatever you want. The purpose is to move ideas to their own place, separate from the committed work that resides on the dev board. I like to think of these two boards as The Studio and The Factory. The Studio is where you can introduce and refine ideas. You can discuss and explore these ideas inexpensively. Refine them, run feasibility studies, trash them altogether. The point is that you have not yet committed to implementing these ideas, and so they are still malleable. As these ideas are refined with input from stakeholders and team members, you define them as user-facing features with specific, unambiguous acceptance criteria. Until these acceptance criteria are defined, a card cannot be moved to the Factory. So over time, our example of "Users can invite other users to teams" actually becomes several work items:
As a user, I can search by name or email address for other users in the system
- The user can freely enter the name or email address of another user into the search bar
- As the user types, he is presented with matching suggestions in a dropdown menu
- If no user is found, the dropdown simply says "No users found."
- User can use arrow keys or mouse pointer to select a name from dropdown
- When selected, the user is navigated to the selected user's profile page
As a user, I can invite another user to any team to which I belong
- From another user's profile page, current user can click "Invite to team"
- Clicking invite button will open a small dropdown listing all teams to which current user belongs
- Selecting a team will send an email invitation to the other user
- The invited user will click a link in the email in order to accept the invitation
- Current user may invite a single user to multiple teams.
As a user, I can revoke pending team invitations
- From a user's team homepage, they can see a list of invitations they have sent but which have not yet been accepted
- Clicking the trash can icon next to any invitation will revoke the invite
- When the invited user clicks the link in a revoked invitation, they will see an informative page telling them that their invitation has been revoked.
In Agile software development, these are known as user stories. (But you probably knew that. See the "Does this sound familiar?" at the bottom of this article for more about Agile.) What differentiates these from developer todo items is that when one of these user stories is complete, we have added value to the product. Adding a database model to the system doesn't add value if the user-facing feature for that model is never finished. Only when an idea has been framed in terms of value to the user and defined with specific acceptance criteria can it be considered for the Factory (aka the Dev Board).
I say "considered", because moving an item to the Factory should be a deliberate act of prioritization and commitment. In the same way that it is costly and inefficient to make changes to something that is already halfway through an assembly line, you don't want to change requirements once your developer has started working on a user story. By moving an item from the Studio to the Factory, you are indicating that this item has been sufficiently defined, its requirements will not change, and is ready to be implemented.
Next time, we'll talk about what happens once the work item arrives at the Factory.
Does this sound familiar? Lots of the things in this article will look familiar to you if you are even somewhat familiar with any of the various Agile Methodologies. That's intentional. I've seen too many teams try to adopt Agile all at once, only to get swamped with the details and rituals and abandon the process. Consider this a sugar-coated, bite-sized delivery of some of what Agile has to offer. I'm not an Agile purist (or a purist of any sort) but I do find a lot of value in much of what the various Agile methods have to offer, so I use them liberally. Agile is all about incremental delivery of value to the product, and I'm all about incremental delivery of value to your development team.