Posts Tagged ‘Learning’

Basics

As a product scales there would often be an increase in capacity / scrum teams working on that product, enabling multiple features to be worked on concurrently, which would be a sensible time to review whether it’s time to adopt the LeSS (Large Scaled Scrum) framework.

As there are some additional elements involved in LeSS vs. Scrum including:

  • All of the Scrum teams work as one team, from one product backlog and with one Product Owner to deliver common goals
  • Having a joint sprint planning with members of each scrum team to decide on what product backlog items (PBIs) to commit to delivering in the next sprint
  • Overall Backlog Grooming (OBG) where members of each scrum team decide on what PBIs to assign to what teams, so they know what features to groom and get in a ready state for an upcoming sprint
  • Overall Retrospective where members of each team discuss highlights from their individual team retrospectives with the aim to learn and improve on how the whole team operates

It’s important to ensure that the Scrum teams have mastered the key elements of Scrum before considering using the LeSS framework, so before moving over to LeSS, see how you’re doing against the below questions:

  1. Are the teams using velocity to measure whether process changes they make are improving their productivity or hurting it?
  2. Are fast estimation sessions happening frequently so that the product backlog has rough estimates?
  3. Is it easy to predict when software will be delivered for the current and future projects based on the backlog being sized?
  4. Are sprint burndown charts monitored every day?
  5. Is analytics part of the definition of done?
  6. Is there a strong DevOps culture in all of the teams?

If the answer is ‘no’ to any of these then perhaps it’s a bit too early to adopt LeSS.

Learning

There are three major types of learning:

  1. Learning through association – Classical Conditioning
  2. Learning through consequences – Operant Conditioning
  3. Learning through observation – Modeling/Observational Learning

This article is focusing around No2 (learning through consequences) and the reason for focusing on this is because it’s so popular for fellow work colleagues across any business to recognise a problem / something not getting done and the consequences of not solving / doing it, that they just get stuck in and solve it themselves because they’re passionate about the business they work for instead of leaving it for the person whose responsibility it is to solve the problem / complete the task with risk that it’ll likely not get done.

Now, many people would say that’s brilliant team work and a fantastic ‘One Team’ attitude, but actually the action of solving someone else’s problem / completing a task for them is stopping the actual person whose responsibility it is to do it from learning. Also there’s the point about the person should be doing what they’re paid to do, but most importantly unless people experience the consequences of not doing elements of their job, then they’re simply not going to learn the importance of doing that element of the job and that they need to perhaps adjust their processes or admin to ensure they take control of their responsibilities in future.

Like I said at the start, if you’re passionate about delivering value for the business then it’s certainly not easy to avoid getting stuck in and it’s hard to avoid reminding people to do their job, but if you want to achieve the goal of the person who should be solving the problem or doing the task actually does it as expected in future, then the only way this will happen in the long run is by that person recognising the consequences of it not being done, so then they can avoid leaving it in future.

There will naturally be times when someone is clearly over worked and can do with a hand and that’s where you could come in to help, but if it’s someone close by spending most of their time surfing the net or playing ping pong in the games room, then you need to take a step back, try and ignore the problem not getting solved allowing them to deal with it however they feel is effective, but what is for certain is that problems / processes don’t normally get done on their own.