The minimalistic development framework

Hi, have you ever thought of the minimum that we need to work as a team? During my two decades of software development experience, I’d been working by many different methodologies. All of them have something in common that one day shaped for me into a clear set of simple elements playing seamlessly together. Even more, we see these elements not only in software engineering but in any other industry as well. Those names are a daily briefing, a task board, and a blah-blah-bucket.

We need minimalistic daily briefings to synchronize things that slipped through the day because of some reasons. Sometimes can happen that we misaligned or some information missed, or something unexpected happened that didn’t get enough attention. Well, we catch it during the next daily briefing. Bring only topics that need all attendees. Don’t wait for the next meeting, act just in time. Don’t stack problems, solve them directly. Don’t hold information, use messengers like Slack.

We need a minimalistic task board to see where we are. Keep the task board as simple as three columns (new, doing, done). Group tasks together to organize more complex requirements like use cases, user stories, features, experiments whatever. It is a bare minimum which is like lego pieces can form any weird shape your current situation can pose. Then later you can disassemble it back and have a minimalistic tracking system. Count tasks completed in a week to have an impression on your minimalistic velocity.

We need a minimalistic blah-blah-bucket to put there any topic to discuss, such as requirement refinements, impediments, hardware requests, ideas, anything that need a conversation. During the next daily minimalistic briefing, somebody could decide to bring attention to the vast amount of items in the bucket so that somebody could send them to the trash bin. Worth to mention, don’t put beer party requests to the blah-blah-bucket, so they are not going to the trash bin as well.

Seriously, everything else goes beyond and can change, but this minimum has to be there for sure. We could decide to have a planning session just after the daily briefing on Mondays so that we have some meaningful goal for this week. We could choose to run a release train on Tuesdays, so everybody knows when to jump in. We may have retrospectives every other week on Wednesdays. A product owner could provide the product backlog or the team or a business analyst, and this doesn’t affect the minimalistic development framework. Or we could decide to use data-driven development and to run experiments instead of using user stories. You see, the core would stay the same.

When the minimum asset is in place and respected as a core, and treated as an engine, then all other ceremonies are organized around it with the understanding that they are supporting the base. Then all the focus of the team is on the engine, and by the team here I mean the whole organization. I can imagine that one company could have multiple cores, like IT, sales, support. Then every team member knows how the engines work and understand the impact of different activities. Then we could reach the skies together.

I like simple things, they may be hard to find, but they are easy to understand. Sometimes when you look at something long enough you start to see things that look like new but they were there from the beginning, we didn’t see them first.

Click the clap button if you like my way of thoughts. If you want to know how to deal with items from the blah-blah-bucket check my story about the open contribution.

The open contribution, or how to make decisions together_I know, sometimes it’s a good idea to make arrangements with a small group and distribute it to the rest of a team. I…_medium.com