HowTo: Dod workshop

The DoD (Definition of Done) is a critical element in aligning an organization to be able to continuously deliver valuable products to the customers.
The importance of the DoD and a deeper analysis is described here
How do you properly create a DoD that reflects the current skills of the teams and at the same time provides guidance for learning and improvement? This blog post will describe how I often facilitate such a workshop.

If you don’t have a proper DoD, I would recommend that you get one ASAP. and even if you already have a DoD, it is definitely a good idea to revisit it from time to time to check whether it requires modification.

When I talk with people about DoD, it is surprising how something that looks trivial to most is us is actually something we need to align and agree on. Since we all have different assumptions.
The way I like to approach it is by conducting a short and effective workshop by gathering all the relevant people in one space to discuss and align.

I would like to share with you a workshop that was done with a customer using zoom (COVID…) but this can be similarly done in a “real-life” session.

The workshop requires about 2 hours, and in order to make it effective and have a good DoD it is also highly important to have representatives of each and every phase in the development process attend.

Workshop structure

  • I start the workshop with an energizer, a short activity to break the ice and get the people in the right mood.

  • The first real step of the workshop is to create a collection of activities that composes the value delivery flow.

  • Once we have a comprehensive list of activities, we can then move on to reach an agreement regarding which of the items can be a part of the DoD, taking into account the business needs and the skills that the teams currently have.

  • We then continue to add more details and clarify what each activity means for us.

  • At this point in the workshop we should already have a first version of the DoD.

  • Depending on the time left and the atmosphere, you could also potentially add a bonus step to look into the future and agree on how to expand the DoD.

  • And just before we finish i use any kind of “checkout” activity to close the workshop.

The following table will describe in detail a specific instance of the workshop facilitation flow which was done remotely using zoom.

Goal

Timebox
(min)

How

Preparation

Check-in

15

Each participant chose an animated gif image and sent it to me privately using zoom chat

I quickly put all the GIFs in a document that I shared with the participants.

I asked the participants to try and guess which GIF belongs to which person.

Decide how you want to share the GIF with the room. I used a shared google doc, but any other method will do.

Collecting activities – Part I

10

Divided to groups of ~5 people (using zoom breakout rooms),  the participants were requested to add as many items as they can to that column, each item representing one activity that needs to be done in order to deliver value to the customer.

* Open a Trello board (or similar) with one column titled  “Delivery activities

Collecting activities – Part II

10

Divided into groups of ~5 people, the participants were requested to extend the level of details so that the items will be clearly understood. for example, The item titled as testing is way too vague for me, and I asked to split it into the different categories of testing that this group needs to perform in order to deliver.

Finalizing activity list

10

Having everyone in the main room – everyone has a chance to ask questions or clarifications regarding the items on the list and make the necessary adjustments

Categorizing activities

2 x 10

Divided to groups of ~5 people, the participants were requested to start moving the activities from the “Delivery activities” column to the right column by discussing when is that activity taking place, I also requested that they remove duplicates and clarify meaning when needed.
This is done twice, with different group compositions.

Add 3 more columns to the Trello board you created: “Before the sprint”, “During the sprint”, “After the sprint”.

Finalizing Categorization

10

Having everyone in the main room – everyone has a chance to ask questions or clarifications regarding the items on the list and make the necessary adjustments

Add more information

2 x 10

Divided into groups of ~5 people, the participants were requested to add the following information to each activity:
– Who has the knowledge and skill to perform this activity,
– What resources are required
– How will we know that it was performed
– What are the impediments that will make it difficult to perform.
This is done twice, with different group compositions.
Additionally, this is another opportunity to clarify items, change their column and remove duplicates.

Finalizing the DoD

10

Yay! First DoD!
Having everyone in the main room – We review the items that are in the “During the sprint” and declare that as our  DoD.
This is also another opportunity to ask if there is anything that doesn’t make sense or is thought of as not doable and modify the DoD accordingly.

Prepare an empty document  titled “Our DoD” and copy/paste the items from the “During the sprint” column

Expanding DoD – bonus step.

Collectively decide which item we would like to add to the DoD and what steps we need to take in order to succeed with that.
I will leave out the details of how to facilitate that to leave some room for your imagination and creativity.

Closing

10

I asked each participant to “sign” at the bottom of the DoD document by typing in their name and one sentence describing how they personally are committed to making sure the DoD is respected.

I’m done (I think…)
Anything to ask or add? Use the comments 🙂

Scrum master – This or that?

In my experience, the Scrum Master is one of the most misunderstood concepts in Scrum.
In this short post, I will try to answer based on my point of view five different “this or that” questions regarding the role.

Full-time role or additional responsibility?

Full time. Becoming a good scrum master is not an easy task. It requires a person to focus on learning and on aspects that are often not directly aligned with the value creation process.
Hence for a good Scrum Master being aware of the details may not be the most important aspect of the role. Moreover, examining the details may even get in the way so the Scrum Master cannot see the bigger picture. And that’s a shame because a good Scrum Master actively looks for system patterns and dynamics.
Also, the Scrum master is expected to look for opportunities for improvement in different elements of the organization. Assuming this is a part-time role is like assuming there are limited opportunities for improvement.

A development team member or not?

Not. The Scrum Master is a person that is expected to lead the Scrum adoption, hence they represent the organization. In fact Scrum Masters are a part of the organization’s leadership team.
The challenge with having a team-member\Scrum master is the need to try and balance between the team’s needs and the organizational needs. This is hard.
By definition the Scrum master is not directly responsible for the work outcome. This concept of separation allows them to focus on long term improvement and success instead of focusing on completing a specific task or backlog item.

Male or Female?

Yes.

A Manager or not?

That is probably the million-dollar question. In general, my personal view is that managers in a healthy organizational culture behave in a very similar manner to Scrum Masters: They use coaching instead of authority; They apply  “power with” and not “power over”; And they avoid blame and are committed to the development of the organization and its employees.
However, sometimes the culture isn’t super healthy (yet!) and the required shift is so hard that I would recommend starting with Scrum Masters who were not formerly managers.
If you do choose your managers to be the Scrum Masters make sure both you and they understand the boundaries and expectations from this new role.

Technical or not?
Great question. This means that for this one I don’t have a clear answer.

In my opinion (and I’m biased since I am a s/w dev after all) technical understanding is a great advantage and allows the person to notice and understand the work system on a deeper level. It allows the SM to get more credibility from the team as they can take part in any conversation.
On the other hand, their technical background may pull them too deep into the conversation and work, which will effectively make them a part of the team, which, as mentioned above, is an undesired behavior from a good Scrum Master..

Homework – Ask yourself:

What attributes are important for a Scrum Master in my organization?
What could I do to encourage behaviors that motivate those attributes?
How could I detect their existence in an employee or candidate?

And finally, what do I need to let go of in order to have better Scrum Masters in my organization?

Image: https://freepik.com

5 things you need to have in order to succeed with Scrum

In fact the title should have been, “5 things you need to have in order to succeed with Scrum in a sustainable manner” but the title is already too long so… 

In my career as an agile coach I have seen and worked with many organizations during the last 10 years, and the other day while driving in my car i was thinking to myself: what do the organizations that benefit greatly from Scrum have in common? This post will mention 5 attributes which I find that are very important in order to succeed with Scrum.

Disclaimer: This post does not provide a complete list or a cookbook – there is lots more to write about and I might share them in another post one day.

  1. Commitment and buy-in
    That is probably the first thing you want to have within your organization, and I’m not talking only about management support. I’m talking about wide support. Support and buy-in across as many people and teams you can get.
    In order to get this buy-in and commitment, you want to involve as many people as it makes sense in planning the adoption, making the choice of investing time and effort, and this will most likely result in a faster and smoother transformation.

  2. An environment that supports learning (sometimes in the form of failure)
    In case you didn’t notice, Scrum is a learning framework with some elements that support product development. But it is first and foremost a learning framework that helps you gradually move from where you are to where you want to be.
    In practice, this means trying out new ideas and practices, experimenting with different structures, practices and processes and being very deliberate about learning.
    It means understanding that some of the things will not work as expected and potentially even have a negative impact on the bottom line. That is totally ok and welcome where learning is important. try and make sure that your organization is ready for that, that the patience & encouragement for that is there.

  3. High level of technical practices
    I hope you understand that your business agility is constrained by your technical agility. In order to be agile it is crucial that developers can change the code without hesitation and not to be in a state when every little code change causes the system stability drop. When your teams are working in close collaboration and are using practices that support fast feedback such as “test-first” approach, continuous integration, pairing, mobbing and others, you dramatically reduce the risk of not being able to sustainably deliver an increment of your product every iteration, which is super important in order to support learning (see previous section).

  4. The urge to be better – This is one of those things that are really fluffy and soft. If you ask people “do you want to be better at…”  most of us will say “yeah, sure!”. examples are being in better shape, eating healthy etc. and most of us do nothing about it. So it’s really not enough to say that you want to improve, you need the urge, the itch, real motivation to be better. In organizations It is commonly a cultural aspect. Some organizations were built with that in mind, some need to invest in creating this culture.

  5. Understanding how to split backlog items.
    This one seems as if it does not belong to this list, doesn’t it? Well, unlike the previous 4 items, this one is very concrete, probably even easier to learn and implement than the rest and at the same time critical to prevent frustration and support the learning cycle.
    So yeah, super important to learn how to split items so that the team is able to complete a minimum ~3-5 items in one iteration.

What else would you add to this list?

image: https://pixabay.com/photos/kanban-work-work-process-organize-4051777/

Engineers are not good with people

One of the rules of the LeSS framework is “The Product Owner shouldn’t work alone on Product Backlog refinement; he is supported by the multiple Teams working directly with customers/users and other stakeholders”, I think there is overall agreement that teams that know and understand their customers can do a better job in delighting them and also demonstrate higher level of responsibility and motivation towards satisfying the customer.

Still, to some organizations getting the teams to work directly with the customer sound not only counterintuitive but also virtually unachievable.
I hear statements such as “developers are not skilled to communicate directly with customers” or “our customer doesn’t want to be contacted for questions”. While those arguments make sense to some, I find that they are based on a set of assumptions which I disagree with.

Let’s examine those two assumptions

1. “Developers are not skilled to communicate directly with customers”

How come? Who is skilled to do that? What superpowers does this person have that team members do not?
From the teams I have witnessed, most team members are able to speak, hear and even write – which are, as far as I am concerned, the basic skills required to communicate with others.
Often the missing skill of team members is to understand some basic ground rules regarding what can and cannot be said to a customer in a given situation, or what are some of the cultural aspects that we need to be aware of.
But we are talking about highly qualified, smart and talented software developers (yes. Testers are also developers), don’t you think that this kind of knowledge is something they can comprehend? They are dealing with complex algorithms and logic, math, programming languages and more.
So, please do teach them what they need to know, mentor them and help them acquire the necessary skills that will enable them to help the organization delight the customer.

2. “Our customer doesn’t want to be contacted for questions”

I often hear that “Customers don’t like it when being asked for clarifications about their needs” – Let’s use a metaphor to explain why this statement is not a fact but an assumption (that is often wrong).
Imagine you are at a restaurant, you look at the menu and find something that you like. When the waiter comes you order it and I bet the next thing you expect to happen is that the dish will be served to your table, and what really happens surprises you, the chef approaches your table leans over and asks “I noticed you ordered the Tuna steak dish with vegetables, is there any specific vegetable you prefer? How do you want the vegetables cooked? How salty or spicy do you like your food?”.
Now, return to the real world (SNAP!)
Regardless of the answers, in your imagination, is the fact the Chef came to your table annoying? Do you feel anything wrong with this situation?
I don’t know about you, but in my imagination I am delighted! I think: “Wow, this chef is really interested in me having a good experience that matches my needs”. Why does this dynamic doesn’t apply when developing a software product? I think it applies. In my experience many customers would really like to be more involved but don’t realize that the option exists. Have you ever asked your customers if they want to be in the loop of product clarification and refinement?

All I am suggesting is to consider this option deeply and when it seems hard, try to identify what are the reasons for it being hard and find a way to make it easier.

May the force be with you,

Elad.

image: https://www.freepik.com/free-vector/cartoon-geek_795448.htm#page=1&query=geek&position=7

Another way to learn about retrospectives

Unlike most of my blog posts, this one is not an opinion or some deeper insight or analysis.
It is a description of the result of an evolution of a workshop Ilan Kirschenbaum and i developed that is called a “Retrospective retreat”
The Retrospective retreat is a workshop that is very similar to code\coach retreat in which it is targeted at creating deliberate learning through repetitive practicing  of the Retrospective.

The structure:

The structure of the retreat is as follows:

  1. Explain the structure of the day + some logistics.
  2. Group people in teams.
  3. Quickly covering the theory behind retrospective.
  4. Explain the basics of the <activity> to be used.
  5. The iteration:
    1. Share a specific retrospective design.
    2. Perform the activity.
    3. Perform the retrospective.
    4. Reflect on the retrospective.
  6. Until time runs out, go to step <n>.
  7. Reflect on the day and share A-HA moments.
  8. collect feedback

I believe this is quite straight forward and simple to understand.
There are two things that i find more interesting to dig deeper into:

  1. The retrospective designs of choice.
  2. The activity of choice.

The retrospective design

For a full day workshop we usually have enough time to run 5 cycles, each cycle is about 1 hour with the following structure:

  • 15 minutes explaining the design.
  • 5-8 minutes of running the activity (the iteration)
  • 20 minutes of performing a retrospective.
  • 10 minutes of reflection
  • 10 minutes for questions.

What we do is to start with a simple retrospective design and increase level of complexity from one iteration to the other, for example: A day could start with a retrospective composed of
If we were a vehicle, starfish, value\cost chart, Low hanging fruit, ROTI.
The structure can be seen in details here : https://plans-for-retrospectives.com/en/?id=3-78-115-63-14

And as the day continue we increase difficulty by introducing less farmiliar and more complex design such as:
Round of admiration, Speed boat, Five Whys, Retro darts
The structure can be seen in details here : https://plans-for-retrospectives.com/en/?id=76-19-8-20-83

The activity

The activity is very important, since it provides the base of practicing the retrospective.
It needs to be interesting enough to be able to repeat 5 times and still be able to learn and improve, it needs to have similar dynamic to what you would expect to see in developing products.
When we started we invented a game called “Lego-Goola” which is a challange to have a marble travel across the largest distance, it was nice but not enough similarity to product development.
We then used a game called “snowflake factory” which worked quite well as it was engaging and fun and had enough dynamics that are similar to product development.
And recently i was requested by a customer to facilitate a Retrospective retreat, and they requested not to use the snowflakes game, the game i used is described below:

Retrospective retreat game – Lego Farm

The Lego farm is inspired by a game from Liz Keogh – https://www.slideshare.net/lunivore/the-lego-kanban-game-85817610
The goal of the game is to create the highest value farm by following the guidelines (See link at the end)
Through the game, the teams need to purchase supplies, design, make decisions, sell, and perform other actions in order to build their farm.
Here is a short slideset to explain the game.

I find the retrospective retreat fun and inspiring and do not hesitate to contact us to contact us to learn more .

Would love to hear your comments.
May the force be with you,
Elad Sofer (@eladsof on twitter)

*Images in this post are from a workshop done in CyberArk and were approved for publication.

10 Tips on how to keep your meeting more fun and effective

We all love them. Those hours of pure fun, creativity and innovation. Meetings.
How come that we love them so much? Is it the coffee? Is it the the comfortable chairs and large tables? Is it the fact that we have time to break another world record in candy crush?
Now seriously, why is it so common for people to hate meetings? Why do many of us continuously complain about the fact that there are too many of them?
Probably because in many cases our meetings suck (This is a technical term BTW).

Fun Effective Meetings

Often meetings are just a waste of our time. They are ineffective, lead to no action,unfocused and we feel that we could have had better use of our time instead of sitting in this large room filled with people.

The good news are that It doesn’t have to be that way.
Some meetings are not a waste of time, some meetings are considered valuable by the participants. How you ask?
Below are 10 tips to amplify the effectiveness of your meetings, I hope that after reading this you will schedule a meeting to share it with your team 😉

Tip 1: 5 minutes to empty your mind (brain dump)

Meetings can sidetrack, in fact they often do. The reasons are ranging from a discussion about a movie or a concert we went to, to office gossip and the latest new open source project discovered.

One Scrum master i have worked with experimented with a way to reduce this behavior by allowing 5 minutes of brain dump at the beginning of every meeting. It helped them improve meeting focus, it may help you as well.

Tip 2: facilitate

Meeting don’t just become effective out of the blue, it is a result of deliberate action and specifically facilitation. Do you have a facilitator to your meetings? Does she have the skill and knowledge to effectively facilitate a meeting? Was there enough time to prepare the format?

Tip 3: Start on time

Meeting are often scheduled in advance, which means participants had enough time to make sure they can arrive on time (there are exceptions).  And still what if people are late, to me it often means that they do not care enough about the meeting (what if the meeting was to ruffle 10,000 Euro – would they be late then?), if people are late you need to examine the reasons and in the absence of good reasons, define working agreements that will allow this to work. Examples are:

  • If you are late you are a silent observer.
  • If you are late three times, we stop inviting you to the meeting.
  • If you are late you should bring refreshments.

Tip 4: Finish on time

People are busy, some of the hop from one meeting to the other, back to back meetings are not rare. If you do not finish on time your own meeting, how can you expect others to do so, also this will probably be a factor in having people being late to other meetings. If the time is about the finish and you think more time is needed, consult with the participants what would be an effective way to continue, avoid extending the meeting for “just 3 more minutes”.

Tip 5: talking stick

This is a very popular tool originated in Indian tribes for meeting with the problem of having people talking over others.
The concept is to have an object and only the person holding that object gets to talk, then when the person is done she can either place the object back at the center or hand it over to another person she wants to hear.

Tip 6: talking tokens

Have you ever been to meeting where one or two people take over the meeting and just never shut up? I have. One solution i have found it to give tokens based on the time of the meeting.
Example: for a 60 hour meeting i would assume the facilitator would take roughly 10 minutes, which leaves 50 minutes for the participants, so if there are 10 participants each one gets 5 tokens that can they can use. Whenever they want to speak they need to pay a token and a timer starts, after the minute passes if the person wants to continue they need to pay with another token. Simple & effective,

Tip 7: Digital equipment – out!

Please please please!!! Leave all your electronics outside unless they are super essential. Place a box at the door for phones, don’t allow laptops in, they are the most distracting things ever!

Tip 8: Avoid projectors

One of the things that causes people to fall asleep are long and boring presentation, especially when lights are dimmed or off. This is normal but can be avoided many times, How?

If you have only a few slides, can you copy them to a whiteboard or flipchart?
Provide handouts to participants with the diagram you want to explain?

I bet you can come up with more ideas..

Tip 9: Be prepared

If you are about the host a meeting or attend a meeting, be prepared, preparation may mean to check that you have all of the knowledge expected, that you have enough time and mental capacity to attend effectively, that you understand your role in the meeting, are you an observer?  A contributor? A facilitator? Once you know, one suggestion is to act based on your role. Are you unclear what your role is? In that case you should probably read tip number 10.

Tip 10: Don’t attend meetings

I beg you, PLEASE… Stop attending meeting that you don’t need to, don’t go just because you are invited and you feel obliged, this is probably one of the major reasons why meetings become ineffective! If you are not absolutely sure you need to be there, you probably don’t. If you do not have a good understanding why this is an important investment of your time, just stay in your chair and do stuff, or go and have a cup of water. I know some organization consider that behavior to be rude, if that is the case for you, you probably need to call a meeting to change that 🙂

I hope you find these ideas useful, if you do and if you don’t please let me know by commenting.
Got other tips? Please comment.
For more, follow me on twitter @eladsof

May the force be with you,
Elad.

Why we choose not to do SAFe adoptions?

Yes. As the name of the post suggests, we at Practical Agile have chosen not to be involved in SAFe adoptions.

Some may ask: But you are practical Agile and your subtitle is “Agile in your context” isn’t this kind of statement in conflict with your own brand? We think not, and this post will try to explain why.

We are practical Agile

Which means we are not about reading a book or taking a training and then implementing the ideas exactly as they are explained, We are all about helping our customers make the relevant adaptation to fit their own unique organizational system, and we strongly believe that this needs to be done properly, through experimenting, learning and using empirical process control, and not by using someone else’s ideas of how things should be done.
This does not mean not to learn from others, but it also does not mean to adopt something blindly because someone (or many for that matter) thinks it works for them.

We are Agile

And by that we mean we embrace the Agile values and see them as very important foundations to a successful agile adoption, let’s examine the 4 agile values.

“Individuals and interaction Over processes and tool”

For us means that we try to minimize the amount of process prescription as much as possible and encourage people to interact and organizations to learn and gradually create their own unique process. SAFe (while we really assume was not the primary intention) reduces the chance of this learning and discovery process by prescribing too many things, by defining too many roles, which from our experience, in many organization, will end up not really doing a cultural change but a shallow, sometime “fake” change.

“Working software over comprehensive documentation”

We really believe in having real working software, meaning a complete integrated product that is available to be delivered every increment (or even more frequent), because of that we do not support designing the organization around components but having it focused on customer value.
Amongst other things, the guidance of SAFe is to create a complete shippable product every PI, which is in our opinion wrong and increases the time to get feedback regarding the system.

Additionally SAFe defines a “non-value adding” iteration called the IP iteration that is dedicated to innovation and planning, which to us sound like more about documentation than software.

“Customer collaboration over contract negotiation”

When examining SAFe essentials we could not find any guidance regarding customer collaboration, specifically not about teams collaborating with customers, fo  that SAFe defines various roles such as “Product Management, System Arch/Eng, and Release Train Engineer” that are the customer’s main point of contact and we could not find a clear directive or even a recommendation for teams to communicate with the customer, we could find a statement that the team PO (another potentially dangerous concept) is “representing the customer to the agile team”.

“Responding to change over following a plan”

Once again, we can find several elements in SAFe that emphasize investing a lot in planning – which from my experience will result in more difficulty to divert from the plan, plus it increases the cost of change. When trying to achieve perfection (even when very hard) we do not think it is a good idea to compromise, we aspire to be able to have real continuous planning, meaning you plan ahead as little as possible (and responsible). Providing guidance to plan for 3 month is not only a compromise but will often result in a motivation to follow the plan, even when it is obsolete.

All of the above does not mean that SAFe is good or bad, it is an explanation of our company’s value and vision and why there is a mismatch between the way we see things and SAFe, and the reason we chose not to be involved in SAFe adoption and prefer a different approach (you know what it is…)

How to manage the Product Backlog for 50 teams in 3 important steps?

manage_product_backlog

Disclaimer: If you haven’t read my “Managing the product backlog for 8 teams“ post – I highly recommend you read it before continuing to read this blog

First thing is first: What the hell were you thinking when you decided that you need 50 teams for your product?! I hope you had a really good reason for it. 9 out of 10 times you have made a bad decision…
But here we are, having a product that has 50 teams, which means dealing with ~600 fine grained Product Backlog items at any given moment, I think we can all agree that this is definitely too much for one person to handle (Disagree with that? Please do not stay silent and comment). So how would we go about and deal with such a big Product Backlog?

  1. Before splitting and clarifying the big PBIs, categorize the PBIs in a customer centric manner, for example: administration, reporting, user management, billing etc.
  2. Based on business considerations, prioritize the big items, and then group the categories so that they create work for groups of 4-8 teams – In LeSS (Large Scale Scrum)  we call these groups requirement areas.
  3. For each Requirement area you should have an APO (Area Product Owner) The APO will act as the Product Owner within the requirement area that she operates in, the Area Product Owner  will deal with ~50-100 items simultaneously, which as i explained in the previous post, makes sense.

There is still a risk to be aware of.
What is the most important thing about prioritization of a backlog?
That’s right folks, It should be very much aligned with business value and ROI.

When having 2 teams and one Product Owner that works in parallel on 2 fine-grained PBIs we have a small risk of working not according to business priority, How about having 50 teams, 7 APO and a Product Owner…
I am not going to explore this further on this post (hopefully in a future post if you ask nicely) but you should be very much aware that when working in a big group, you are most likely, to some extent, not working according to priority, and i recommend that you try and minimize this as much as possible.

For more, follow me on twitter @eladsof

May the force be with you
Elad Sofer

How To Manage the product backlog for 8 teams in 5 important steps?

Five Important points to mange product backlog for 8 teams

The product backlog (PBL) is probably the second most important artifact in any LeSS (Large Scale Scrum) \ Scrum implementation, the only artifact I find more important is the product itself.
In a on-team scrum the Product Backlog is pretty much simple (though not easy) to manage, if you follow the recommendation of having each team take 3-4 PBIs (product backlog items) per sprint, this means that the product owner needs to deal with about 12 fine-grained product backlog items at any given time, not all require full attention.

Why 12 you ask?

It is recommended that we have product backlog items refined & ready (AKA groomed) for the next two sprints or so.. Given that we have 4 items in progress, 4 for the next sprint and 4 being refined for the next-next sprint. Total is 12.

Got it? Good 🙂 If not, please feel free to contact in the comments or contact me personally

So far so good, now let’s scale it to 8 teams. (8 teams) x (12 items) = ~100 items, which is what the LeSS Framework suggests to be the limit of items that one Product Owner can deal with simultaneously. I know it sounds like a lot of items to deal with, but it is totally doable when performing the Product Owner  role as described in the LeSS framework.

The Large Scale Scrum framework is designed (just like Scrum, mind you) in a way that the Product Owner deals mostly with prioritization and less with clarification, with this description most people agree that 100 Product Backlog Items sounds like a reasonable number.

Assuming that you work properly, at any given moment there are ~33 items in work which require low to no attention, 33 items ready for the next sprint that requires low attention as well, so most of the work is spent on the remaining 33 items, now what should the PO do with these items?
Mainly: Prioritize. Given that you have a 40 hour work week and a two week sprint, that gives more than enough time to prioritize 33 items and even get some more stuff done. Capish?

For more, follow me on twitter @eladsof

May the force be with you,
Elad Sofer.

Why should you attend the next LeSS Training in your area

We are all under pressure, we are all expected to be productive and deliver value to our customers, so it makes sense to have enough confidence that the time investment will turn out beneficial.
I believe that after reading this post you will have enough good reasons to attend a “Certified LeSS Practitioner training” (CLP).

I have structured the post as a Q&A session with yours truly 🙂

Q1 : What will i learn in the CLP training?

If you are reading this post you are a learner, you understand that there is value in other people’s perspective and opinion, the CLP is very much about learning, even more than that, the way I structure the training makes it more about learning than anything else.
While some trainings are about providing you with answers and prescription, the CLP is about providing the thinking tools and model that will amplify your ability to solve complex organizational problems, specifically about becoming an Agile organization.

Q2: My organization is already doing SAFe, is there a point in attending?

Great! In that case you have the opportunity to learn and evaluate what other options you have.
I assume that when you choose a technological solution for example, you evaluate more than one option, you compare and eventually do what is beneficial for you.
The same goes for choosing a framework and deciding how to design your organization.

Q3 : Ok, which tools and model will I learn

In addition to gaining a deep understanding about the LeSS framework, you will also learn the why, some of the tools we will use are  “System modeling”, “Systems thinking”,”Lean thinking”, “Feature team adoption maps” and more.
Some of the models that will be discussed and applied are “Evidence based management”, “Queuing theory”, “Theory X and Theory Y”, “Agile s/w development” and many more.

Q4 : Are these modes and tools practical?

Yes! All of the things we shall use are also applicable in your own domain and every organization can benefit from having these tools in its toolbox, these tools will help you and your organization to develop a better way of thinking about the challenges you are facing.
And, in addition to the model and tools, there will also be plenty of examples and a review of a case study of a LeSS adoption.

Q5: Are there reasons not to attend?

If you are looking for a laid back type of training in which you can stay in your seat and just listen this training is probably not for you. There will be plenty of activities in the duration of the 3 days, some of it will remain a surprise, some of it will be pure fun, some of it will be challenging and difficult, some will take place after the formal training hours…

Q6: Why should i attend a training with you (Elad Sofer)?

I will let others answer this question:

  • “Dear Elad, training was very valuable, it was done in a clear and graceful manner. I learned a lot. Thank you for the dedication, professionalism and the knowledge you gave us”, Orna Shapira – Agile coach.
  • “The training was filled with useful content, When we focused on LeSS and LeSS hugh i could imagine my organization in most of examples and explanations which very much fit my needs. I have written down at least 10 things i would like to try with my team and my organization and you have given me plenty of food for thought, Thanks.” – Irena Label – Cisco
  • “Amazing course. Learnt a lot of new and interesting stuff which I’m going to share and implement in my organization.” – Alon Cohen  – RSA

If you want to know more or have any further questions, do contact me

How many Product Owners do you need?

What is the ratio of Product Owners / teams in your organization?
Please, let’s play a little game: Before reading this post, write your answer in the comment, just a number, you don’t need to explain… do you mind taking the challenge?
Why am i asking? Well… when Scaling Scrum (using the LeSS = “Large Scale Scrum” framework) there is a rule that there should be only one product owner

“There is one Product Owner and one Product Backlog for the complete shippable product”

Here are 4 reasons that explain why:

  1. ROI over ego
    It is common that managers in big organizations to try pull the product in different directions as a result of technical and/or political constraints, this causes the system to be sub-optimized and reduce its effectiveness.
    Having a single product owner ensures that priorities are driven by business value and not by ego, prestige or other irrelevant aspects, this one person is accountable for the ROI of the product from a whole product customer centric view.
  2. Simplicity over Complexity
    When having multiple product owners, it is still required to have another person often from marketing or a similar business unit that is focused on managing and synchronizing the work of the other product owners, in addition to the extra people we need (multiple Product Owners) coordination roles are wasteful and creates additional and unnecessary complexity which should be avoided.
  3. Direct communication over Proxies.
    Many will agree that when the developers understand customer needs they deliver better products. Given that Product Owner are mostly busy with prioritizing the requirements, having multiple product owners create a situation in which it is very tempting for the product owner to use her free time and “help” with things such as low level clarification of requirements which is the role of the development team.
    This harms the team-customer communication, that can eventually lead developers to develop the wrong requirements, or worst, not care about the customer.
  4. Empowerment over Micro-management
    When having one Product Owner per team, it is common that the Product Owner (as a result of free time and the will to contribute) starts interfering with the team’s work, specifically with execution related decisions such as design choices, team members work distribution and micro-status monitoring.
    This dynamic is bad for your organization and results in teams taking less responsibility and a drop in motivation.

These are the main reasons i see.

Got other reasons? Disagree? Please comment.
For more, follow me on twitter @eladsof

May the force be with you,

Elad Sofer.