In a software development project, it’s important to find a suitable process for the project. A good process helps developers, managers, customers and users. A great process should improve the…
— Read on medium.com/@niant/why-deadlines-and-sprints-are-bad-for-you-7ee87be5d0f0
I see that most people perceive the scrum framework as a planning tool. I think that it is wrong and I think it is a learning tool. You create a plan in order to learn new stuff when something did not happen according to the plan.
This is also supported be the agile manifesto that states you should “Responding to change over following a plan”
I see a lot of product backlogs with both business related issues and technical depth issues. The technical issues often has lower or no priority.
It is hard to explain the business value of solving technical depth issues. From the product owners point of view I can understand why these technial items get lower priority, when they see no real business value in solving these issues.
What is causing technical depth to build up?
The usual development process is somekind of micromanaged and product owners or managers want to know whats going on in a development team. So issues to work on is written with e.g implement something in the backend and write some automated test in the backend.
Usually a part of definition of done states that there should be an automated test when business issues are put into production.
The implementation may take longer than expected and the development team don’t have enough time to test. Management decides, by e.g putting pressure on the development team, that the development team should only do a manual test and automate the test later on. Now technical depth has occurred and each time the development team has to complete another issue it has to decide to do a manual test of the old feature.
So I think that technical depth occurs because af pressure on the development team and management are making priorities on the technical stuff instead of business isusses.
What is the business value of solving technical depth?
Technical depth slows the development team down by giving unpreditable side effects when implementing issues like bugs or rollbacks in production. If this proces goes on for sometime there will be lots of bugs and technical issues in the backlog and the product will eventually die.
So the business value of solving technical depth is actually the value of the product it self.
Should technical depth issues be a part of the product backlog?
It depends on if technical depth gets the proper priority and does not build up over time. I think that a product backlog should contain issues that concentrates on what should be done to evolve the product and not how it should be done.
So technical depth should be on the impediment backlog and priority should be decided by the development team and is therefore not up to the product owner to decide if a technical depth issue should be solved.
During my work as a scrummaster I had a talk with my product owner about a continuous delivery epic with the following goals: 5 releases a sprint, 0 bugs found in production and 0 roll backs during a sprint.
The product owner asked how long it would take to reach these goals and I replied I don’t know and then product owner concluded that the epic was not well defined.
Is this true?
I don’t think so, because when a deadline is reached you measure up againts the goals. If the goal is not reached we define further action to reach the goals and maybe define a new deadline. The point is that I do not think time is important when you define a task.