Backlog or not backlog

Backlog or not backlog

Here is the question. What if a developer can make feature or program or task in time, without bugs and meeting all the requirements you asked for? Does he still required to put backlog items into the tracking system? Let’s extend the question. What if a whole team can do that? Make the release and hit the deadline. With minimum issues and well done in terms of business logic. Does this team still need to track anything in tools like Trello/Jira or similar?

It is the hard one. It seems like the obvious. That yeah, they don’t need to; they meet a goal of their work. And you will and should be a little sceptic about that. One might say that it is impossible. That whole industry design all of these frameworks for us and we should follow them to succeed.

I can tell you it is possible I’ve seen people and even teams who able to do staff without classic SCRUM or similar techniques. The magic of this is interesting. If you will interview those people or teams who able to deliver with none of existing frameworks or processes on sight, you will find next features of their work (this is what I found you probably will find even more):

• Before doing anything they think and speak a lot,  they are using all available techniques to understand what need to be done,
• They are making the general strategy on how to achieve the goal. Some store this strategy in mind, some write it down on paper some uses software solutions for that
• When they starting the work, they split it to achievable units and follow the strategy they got in the beginning
• Time to time they are reviewing strategy and adjusting it to the conditions
• When it is a team, they usually meet or use emails or other communication channels to discuss and adjust the strategy and exchange unexpected findings.

You can see that it is close to classic SCRUM or Agile development and at the same moment it is far from them.

Each person and each team has own unique thought process and planning mechanisms. Because we/they are humans and have really complicated behaviours and approaches. Sometime it fits classic SCRUM rules when you split things to backlog items, then plan sprints, etc. But many times it is not. And what persons or teams trying to do, they trying to fit their systems to the introduced from outside. And often it creates overheads and miscommunications. Instead of helping teams, SCRUM/Kanban/Scaled Scrum/Waterfall/You name it, just making visibility of work, while people or teams struggling on background and usually have own plans/strategies outlined somewhere else. Team forced to execute double work while it can be simpler.

I propose next approach. Instead of introducing the System. Let team or people do their work. See how they do in global terms, does they deliver or not in agreed terms or deadlines? And then ask questions on how they do that. If they successful, you will find a new practice that might even help other teams or become a new thing like SCRUM that is applicable in many situations. If they not you can start introducing some parts of other practices that are successful and see how they work for a particular team/person. Some will, some will not. Those are not working you should remove and try to find working one.

In software engineering we are usually skipping this step and jumping right into Kanban of choice or moving blindly with whatever being proposed by Project manager/Coach/Consultant. I recommend for each team to go through a period of exploration. And then revisit it time to time.