I’ve been thinking about how KISS a small team could go and still stay productive and aligned. This is my take:
1) The story unfolds. Repeating meetings where team hash out the next steps to be done before the next meeting
2) The plot. A plain text document in the repo showing what has been done, what needs doing, and any related notes or comments
Here is an example of the plain text story/narrative of the project:
```
# Project: Cloud Cost Dashboard
Enable easy access to cloud cost data for the team.
## Integration
DONE Cloud cost API integrated with billing system @bob
## Dash board
Dashboard must pull data from AWS, Azure, and GCP for comparison.
TODO Set up a cloud cost reporting dashboard @alice TODO Train team on how to use the dashboard @alice
```
The following rules apply:
- A task is either in status TODO or DONE and it fits exactly on one line
- Add @name to assign tasks
- New TODOs are added at the bottom (so look there for tasks to pick)
- Feel free to add any free text/notes etc to the file to provide context and insight
As the project progresses the story unfolds and self documents.
BONUS: Use the task line for the commit message
Some questions:
- Does this approach seem like enough to keep a small team productive and focused?
- What essentials are missing (given a small team context)?
Would love to hear your thoughts!
AnimalMuppet•1h ago
That eventually fell apart, because upper management couldn't understand agile development, and so they killed it. Never mind that it delivered on time.
But on a small team (4-5 people), I have seen even less process. There was a manager who coded half-time. There was an overall direction, and discussions as needed. Each person had their area of specialty within the code. There were code reviews before checkin, but the code reviews were over-the-shoulder in someone's cube. There was a bug database, but there was no JIRA or other "ticket" system. (There eventually was, after the team grew. And there eventually was a quarterly planning meeting.)
There was a weekly standup for the larger team (20 people). But within the smaller team, each person kept their own to-do list. When your code needed to interface with someone else's, the two of you would hammer out what the interface was.
That won't scale too far. And it risks the mismatch with upper management that the XP team ran into. But for a small team, it can work.