Solution engineer: How to avoid rework and waste

#1

Please suggest Any fun exercises or videos to list the importance of building solutions that are well thought through to avoid any discrepancies and wastages. Thank you .

#2

Hi Sadhana,

I quite like this video by Cindy Alvarez. It covers how you can start trying to get to the real story behind what you plan to build. It is pretty brilliant. What were you looking for specifically? Did you have a particular target in mind?

https://www.mindtheproduct.com/2018/08/cognitive-biases-the-questions-you-shouldnt-be-asking-by-cindy-alvarez/

#3

Thanks for the blog reference. Specifically what am looking for is fun video or excercises for my feature/solution engineers to emphasize the importance of

-well thought through solutions , to minimize risk and wastages and avoid rework.

#4

I think of rework being a bad thing only if it is due to bad quality.
If rework happens because you learned something, that is actually a good thing.

Industrial Logic has a practice in which they talk about risks before attempting a new idea. By identify some risks up front, they are able to navigate solutions with a bit more clarity of the pitfalls.

But I would warn that thinking about it too much can actually be problematic when you are working to deliver something.

The best thing they can do is get feedback as much as possible. Do small steps, get feedback, and pivot (or rework) as you learn.

#5

I think what you are trying to do is the old Lean adage of:

maximising the work not done

Sorry for the slight delay, I’ve been having a good think about this. I started a series of exercises with one of my teams some time ago, unfortunately I didn’t document all the experiments, but we were exploring concepts of the 7 wastes of software engineering.

The exercises that I started with are probably a good point to begin.

Thinking more deeply about this, if you are seeing an issue with rework there may be underlying issues other than thinking that need to be explored:

  • Are conversations and desk checks happening during development? If so, why aren’t they being effective?
  • Do the devs work with a tester who is used to thinking about how things fail rather than how things work? If not, does the team need to explore a more cross-functional mindset? How can you get those conversations happening?
  • Are the tickets/stories well formed and used to facilitate conversations? As I think Mike Cohn said, “User stories are the promise of a conversation”. How can they be improved?
  • Is the team feeling rushed and so diving into work too quickly, without a chat of expectations? Why?

These are just a few that spring to my mind. Another approach might be to take an upcoming item and do a futurespective (http://www.funretrospectives.com/category/futurespective/) on it. Imagine the worst happened with the story and EVERYTHING went wrong building it. Figure out what the everything was, figure out actions that could have happened that would have mitigated the failure and then try using a couple (2) of them in the next sprint. Don’t overload, just pick 2 and try them the see if it better on the way through. Rinse and repeat as often as necessary.

#6

Hello,

Some amount of rework and waste is required to solve complex problems. “Well thought through” solutions require time…and at some point, the time spent to plan a solution to a complex problem is a waste of time. At that point, it’s best to move into ‘doing’ and ‘experimenting’. Not all experiments are going to result in usable output; so the ‘work done’ might be waste but the ‘things learned’ will certainly be valuable as the team/engineers proceed to their next experiments.

I suggest, then, a fun exercise to try would be one which shows the value of fast iterations, fast experiments, and quick learning.