Ways of Working Review – Are We Getting Better?

Team that has just finished a Sprint. Most User Stories are Done. There are no major incidents, and the release is still on track.

Do we really need a Ways of Working Review (Retrospective)? Team decides to skip it.

 In the next Sprint, testing is again pushed to the last few days. Developers wait for requirement clarification. Several stories are carried over to the next Sprint.

Nothing is seriously wrong.

But the same things keep happening.

-> That is where a Retrospective creates value.

 

A Retrospective is not simply about asking: “Was the last Sprint good or bad?”

It is about learning from what happened and deciding what to improve next. 

Look Back	Purpose
What worked well?	Keep doing it
What did not work well?	Understand why
What keeps happening?	Find what needs to change
What will we do differently?	Agree on 1–2 concrete actions

 

For example, instead of simply saying: “Testing was late again.” Team could agree:

“From the next Sprint, a story will only enter development when the acceptance criteria are clear and the tester has reviewed them.”

That is the real value of a Retrospective. It does not need to be a long meeting. And it does not need 20 action items.

 

The goal is simple: Make the team a little better after every Sprint.

If a Retrospective only talks about the past, it is just another meeting.

 

If it changes how the team works in the next Sprint, it becomes continuous improvement.

 

Issue and Problem: Don't Just Fix What's Happening

One day, a user raises a complain: “I submitted the request, but my manager didn't receive approval.”

Support team checks and finds the workflow is stuck. Developers rerun the workflow, and manager receives approval.

Done?

That request was done. This was an issue, and the team resolved it.

 

But the following week, another user encounters the exact same problem. Then, a few weeks later, another case arises.

 

Team investigates further and discovers the cause: when the user's Manager information changes, the data isn't synced in time. The workflow can't find the correct approver and gets stuck.

 

This is the real problem.

What	An incident is occurring.	The cause of the incident
Example	The manager did not receive approval.	The workflow retrieves incorrect/outdated approver information.
Handle	Run the workflow again to continue the request.	Modify the workflow for identifying approvers.
Target	Restoring operations	Prevent the issue from recurring.
Question	How can we handle this immediately?	Why did it happen?

  

The key point is:

• Fixing an issue allows a request to continue running.
• Solving a problem prevents hundreds of subsequent requests from encountering the same error.

The same applies to project or product management. If the same type of issue keeps recurring and the team keeps closing tickets over and over again, we're not truly solving the problem. We're just effectively putting out fires.

Celebrating Bosch CI Centricity Maturity - 2021