Helping you with stuckness

How am I stuck?

A project is “stuck” when there are problems getting in the way of people using the software, or working together to improve it. Here are five main “stucknesses” — ways projects get stuck. For each one, let’s look at the questions that need answering, and how projects get — and how to get them unstuck.



Why should this project exist, and based on that, what should we prioritize?

Assess the project’s goals, health, environment, and competition, and check whether we’re agreed about what’s important.

How it can become stuck: Here’s a scenario: One person prototyped this tool to solve his own problem, and it’s grown into a tool many people depend on. Now, three people with different motivations co-lead it. They don’t realize they disagree about what’s important and what’s urgent. This leads to frustration when they have different standards for what features to work on, how fast to merge contributions, and what to deprecate and when.

Other questions: What work do we need to prioritize, and how urgent is it? What is our goal, and should this project exist (or should we decommission it)? has the team agreed on these things?



Who maintains this project, and what do they need?

Understand who does what, resolve confusion and conflict, and set up ways to prevent future confusion and conflict.

How could this get stuck? Here’s a scenario: One team member is so hard to negotiate with that they block other people from coming onboard or implementing important improvements. Or: conversations about big architectural changes drag on because people aren’t sure what the decision criteria are or who will make the final decision.

Other questions: Do we have enough maintainers to do the essential work, and do we have up-and-coming contributors who can replace us as maintainers in the future? does everyone know who has what powers, or are some people confused about who has the power to do certain things? Do we run into team workflow problems when different groups want to participate at different speeds? Is there a difficult team member who needs handling? do we have the social processes we need to support the project and each other, like meetings, mentorship programs, and Requests for Comment?



Who are our users, partners and potential contributors and what do they need?

Identify the main stakeholders and actors, and make it easier for us to listen to and talk with them about their goals, expectations and needs.

How this issue can become stuck: If we don't consistently listen to and communicate with groups we're working for and with, we are likely to miss important info, make the wrong decisions, and lose usage and trust. For example, if the next major release of the programming language we use is going to make breaking changes to behavior we depend on, and we aren’t keeping up with that news, we won’t plan for that task and prioritize it in our roadmap, and we may have to waste time rewriting new features to adapt to those changes.

Other questions: Do new contributors fall through the cracks? Who are our partners and upstreams -- the people and teams we depend on, and who depend on us? Are we listening to and responding quickly enough to those people’s concerns? Do they have a way of listening to us? Do we talk to each other?



Are our tools set up to support our work?

Assess our developer, contributor, and maintainer experience, and upgrade our tools and platforms to reduce toil for everyone.

How it can become stuck: Contributors started the project on an old platform that doesn’t integrate conversation, patches, and review, and no one’s put in the effort to integrate them or migrate to an integrated platform, so things fall through the cracks. Or: people have started multiple discussion venues, and it’s tiresome to duplicate and interlink engineering discussions among them.

Other questions: Do we run automated tests on every patch? do new issues, patches, and discussions get interlinked so developers and users can easily follow up? Are there bottlenecks or duplications in the platforms we use to respond to issues, review code, and discuss the project in general?



Do we have money? And do we have the necessary plans to use it well, to make project progress?

Assess the current budget and roadmap, research possible funders, and propose and execute funded work.

How it can become stuck: The team’s used to working all-volunteer and hasn’t imagined what chunks of work could be done by hiring new contractors. Or, the existing team doesn’t have connections to open source program officers at corporations, program officers at funding agencies, and benefactors.

Other questions: Do we have enough money to do what we want to do? Have we developed plans or proposals to turn money into progress? Can we persuade funders to give us money?

Any or all of these stucknesses can slow down a project.

Hire us to start fixing them.

Changeset can help you get unstuck

See what we can do for your organization.