Team culture
Are we trying hard enough to keep jelled teams together long term? Do we fully appreciate the value of a jelled team and the work it took to get there?
How does our team culture survive people being brought onto the project or taken off, being moved to part time, etc.?
How are we dealing with incompetent people that don’t work for us (example: incompetent client developers we are forced to work with)?
To what extent does it make sense for project teams to have a cult-like team pride, separate from the other project teams at the company?
Should all project teams have their own team name and logo and identity? Is that valuable?
What can we do to make it easier for people to admit mistakes and screwups, suggest bad or crazy ideas? How can we encourage psychological safety?
Are we encouraging professional development? Do people feel able to spend company time learning things that may not be directly related to their current project? Should they?
Are we using the right balance of live chat (Slack) vs. asynchronous communication (tools like Basecamp or JIRA or a wiki) vs. meetings? Are there things we talk about in Slack or meetings which would be better in longer lasting, more asynchronous tools?
How do we balance being authentic when times are rough (example: client issues, tight deadlines, rough inherited code) vs. being overly negative and bringing down the team?
Allocation
Is “I don’t want to work on this project anymore” a good enough reason to switch projects?
How easy and fast is it to get moved to another project if you burn out or become ready for a change? Is the process well known and running smoothly, or does it require lots of discussion and repeated asking?
Would many people immediately choose to be switched to another project if given the opportunity, but perhaps they aren’t speaking up because it’s too difficult or they don’t want to be the squeaky wheel?
Are we doing as much as we can to prevent people from having to split time across multiple projects? In cases where it’s unavoidable, are we attempting to make sure the people who are split are the right people (i.e., people who like to work on multiple things, or people who have domain expertise that needs to be spread out)?
Would you rather be the only part time person on a project team of full time people, or the only full time person on a project team of part time people?
Are people chosen for projects based on previous experience or based on desire to work on that project, or both/neither? What should the balance be, ideally? Why isn’t that the balance in reality?
What percentage of work hours are people spending on their projects(s), as opposed to on internal tasks such as knowledge sharing or management or professional development? Is this the right percentage?
Development
Are we open sourcing too many things, or not enough?
Do we feel like we can choose what we want to work on, either within the project or within the company? Should we be able to?
Is there a real spectrum of developers, with “grinders” (i.e., people who want clear direction/implementation plans so they can just crank out code, and don’t want much fuzziness) on one side and “thinkers” (i.e., people who like solving hard problems and hate being code monkeys) on the other side? If so, does it make sense to allocate work based on where people are on that spectrum?
How do we evaluate new technologies on projects? What goes into the decision to use or not use new tech, and who makes the final call? How do we decide when to innovate vs. play it safe?
What are the problems we find ourselves solving over and over again, and how can we do a better job of reusing solutions or open sourcing them?
Do we have enough focus time for deep work? Or are meetings and interruptions (chat messages, etc.) preventing focus? How long do we feel like we can go fully heads down and unresponsive at a time, and is that long enough?
What if we assigned each developer 1 day a week to go totally heads down for the entire day, and they’re excused from any meetings or responding to chat? Would that be possible, and help with productivity, or too damaging to communication? If the latter, then does this signal a problem with how we are communicating?
Are we writing too few or too many tests? Are we testing the right things?
What technology/tool/language/etc. does everyone want to learn next?
What technology/tool/language/etc. are we not using which perhaps we should?
Are we allowing for refactoring and cleanup and tech debt? What can we do to improve the process for those things? Example: what if we had a 1-week mini sprint after every 3 sprints where we only work on cleanup and refactoring instead of bugfixes or new features?
Process
Are we doing Scrum as prescribed (for teams “doing” Scrum)? For places where we are not, is that intentional and well reasoned?
What is slowing us down right now? What is our biggest distraction?
When is it appropriate to have a discussion “out loud” (in company group chat or in a group meeting) vs. “in private” (in a 1 on 1 call or private chat conversation)?
Is hitting deadlines always the end-all be-all or is it sometimes worth purposely letting deadlines slip if hitting them would be hard on team morale?
Are people multi-tasking during daily standup? If so, how can we make it more valuable for everyone instead of just management?
Which recurring meeting do we get the most value out of, and why? Which one do we get the least value out of, and why? How can we take the lessons learned from the most valuable one to make the least valuable one better, or should it be thrown out?
Does it make sense to have named roles (examples: tech lead, QA engineer, frontend developer, architect) or should we all self organize around the tasks and ignore any specific roles?
What if we stopped having open calendars which anyone at the company can see and schedule, and instead forced people to ask “When can we meet to talk about X?” Would that lead to less meetings and more asynchronous conversations? Would it allow meetings to be better scheduled to allow for more focus time in between them? Or would it just be an added annoyance?
What if we forced everyone to shift projects every 6 months? How would we change things in order to make that less painful, such as with onboarding, offboarding, project consistency, etc.? Why aren’t we already doing those things?
Mike Crittenden 