Share, Challenge, Learn, Repeat!

Why?

“In the absence of learning, companies — and individuals — simply repeat old practices. Change remains cosmetic, and improvements are either fortuitous or short-lived.” — David A. Green

Learning is a tool that provides companies and individuals the ability to lay out a variety of options when approaching a problem. Acquiring these options is essential for improvement and success!

What you want is to make sure that the makers in your company have a toolbox of solutions for the challenges they face.

There are many methods that can be applied to raise the bar. The truth is — you may already have the necessary learning platforms integrated into your process, yet they might not be fulfilling their full learning potential.

I would like to share two methods to consider in order to maximise your process learning potential:

1. Collaborative learning through sharing and challenging.
2. Recognising repetition and adding analysis step.

What ?

Having a workplace that can challenge itself is the first step towards creating a learning environment.

You want to avoid a state in which the information is possessed by individuals and decisions are taken without alternatives. What you need is to build an environment where your colleagues can challenge each other, the experienced professionals to challenge the juniors, the freshman to bring fresh points of view, etc…

It may feel counterintuitive to invest your top players time in sharing decisions and providing feedback for others. But as long as they don’t challenge and get challenged neither are evolving and the bar is not raised.

How?

Every software development process could be broken into two stages: requirement and implementation. Each organisation decides how to break each of those stages into smaller pieces of decision making stops and execution routes. For those stops to become practical for learning, make sure that:

• You stop in order to make decisions.
• You stop at the right places.
• The stops (both challenges & solutions) are transparent & open for feedback.

To validate the first two just try to visualize the product delivery life cycle in your company, once you have it, try to break it into decision making stops & execution paths.

To provide an example, I will try to generalize the process at companies I had the pleasure to work for.

Once we have the process decision making stops, what is left to do is to make sure that each stop in the process of the flow is:

1. Transparent: we want to lower the information accessibility barrier to a level where any person who is interested and has the basic needed skills to challenge the decision can understand it. In practice this means that in addition to sharing a description of your challenge (can be product spec/tech design/graphical design/vision…) you need to make sure that it’s both abstract enough to set the threshold of entry level as low as possible and detailed enough to create a discussion.
2. Discussion & feedback friendly: we want to make sure that feedback can be given with minimum friction possible resulting in discussion where the sides can challenge each other.
3. Having a clear owner to address the feedback: we need to have a clear owner to share the challenge, address the feedback and implement the needed changes as a result of it.

In practice:

Once we have the stops and the set of ‘rules’ to follow to improve collaborative challenging, I suggest asking the following 5 questions for each of the steps to validate it:

1. Do you have an owner for the step?
2. Is the challenge shared?
3. Is the language and the detail level of the shared challenge is set to the right level?
4. Is there a discussion/feedback?
5. Do you encourage feedback and does it reflect on the end result?

Those questions are straight forward to answer when asked about such process events as feature product specs & tech designs. All you need to do (if you are not already...) is start writing the specifications and the tech designs in a language and detail level matching the target feedback audience. Make sure it is shared (can be a meeting/email/slack whatever…), make sure there is a discussion & feedback that is taken into account in the final result.

Now when we have formalized the method and its validation, you can apply it to any step in your process, even on the less intuitive ones such as effort estimations, tasks prioritization and product vision.

To challenge effort estimation you can introduce the poker planning method into your dev planning. To challenge tasks prioritization a periodic meeting with tasks priorities discussion can be set with all team stake holders. To challenge the product vision / its interpretation into a feature set, just do the same: share it , discuss it, update based on the inputs a great example of such practice can be Amazon’s internal press release culture.

Practice makes perfect

Or Einstein was right? Well it depends… Recognition of repetitive cycles in your process is another method that can help you learn and improve. When such cycle found you can add a step of analysis and learning before the next iteration starts. Agile sprint retrospectives are a great example of such method implementation.

Bottom line

In this post I have tried to emphasise the learning opportunities you may have in your delivery process by using two technics:

• Learn from your colleagues by sharing the challenges & cultivating feedback.
• Learn through recognising repetition in your process and adding analysis steps.

Both methods can be applied granularly, only on areas you want to improve in.

I’d be happy to hear how you are currently practicing learning & improvement in your organisation!