Tag Archives: agile

Explore Product Owner / Team responsibilities Exercise

Estimated Reading Time: 2 minutes

I wanted to share an exercise I created in a workshop last week

One of the topics we wanted to explore was the responsibilities/activities of Product Owners and the Agile Team and how do they relate.

The objective of the exercise was to understand the various activities and how they map in the continuum between PO and Team and across the product development life cycle.

The steps of the exercise are the following:

  1. Map all the activities related to the life cycle – typically this will be the lifecycle of a Feature. I came with a set of predefined steps but I think it can be useful to let the participants come up with the activities as a digesting activity.
  2. Where does each activity lie in the lifecycle? Use horizontal team estimation game – this means coming up with a continuum of activities where starting point is to the left side, ending point is to the right side (to be compatible with a typical Kanban Story Board)
  3. divide the time continuum to a couple of key phases (this can be used to be a starting point for a Kanban board btw, or you can use the existing kanban board the team uses if applicable )
  4. Which activity is associated with Product, Which with R&D? Use vertical team estimation game to drive a consensus among the team. The meaning of vertical is that you don’t touch the left-right placement, just the top-bottom. Top should be solely Product, Bottom solely R&D. Identify a middle area where work is done in collaboration. Even within that area it makes sense to discuss who is “leading” the activity.
  5. Debrief – Have a discussion about what this means, what are the surprises, does this make sense, what you would like to experiment with.

This exercise can of course be generalized to any interface between groups – Dev-Ops, Dev-Test, and outside of Product Development altogether… I’ll be glad to hear about interesting uses of the exercise.






A possible activity list (provided AS IS, no warranty attached… ;-):

  • Decide how much to pull into sprint
  • Estimate effort for stories
  • Write ATDD Scenarios
  • Estimate effort for MMFs
  • Write confirmation DoD for Stories
  • Break MMF to Stories
  • Decide which Stories should stay in the MMF
  • Approve Test Plan for Story
  • Approve Test Plan for MMF
  • Decide how much to pull into Release
  • Decide which MMFs get priority
  • Commit to delivery date of an MMF
  • Decide delivery date of a Release
  • Prioritize MMFs
  • Break Feature to MMFs
  • Guide UX Design
  • Break PRD to Features
  • Accept/Reject Stories


Exploring interfaces exercise

View more presentations from Yuval Yeret.

How does the performance objectives process change in a Lean/Agile world?

Estimated Reading Time: 2 minutes

Seems like every January I get questions from HR leaders in organizations I’m working with that go something like this – “We are working on the yearly performance objectives process, and we were wondering whether it needs to change in an agile environment?”

The main evolution I see in the Performance management process is leaning towards measuring up and across as well as focusing on capabilities improvement rather than a set of concrete product deliverables specified up front.

Measuring up will motivate individuals to become better team players in their teams, as well as be better connected to their business objectives.

I personally preferred capabilities improvement over concrete deliverables for many years even before I’ve been exposed to agile, but of course it makes more sense. There are many situations where you cannot specify deliverables up front these days. You CAN aim for a certain capability or improvement trend.

Another trend I’m seeing and think is useful is to give teams shared goals on top of individual goals. These are again capability-driven goals as well as business objective goals.

A couple of years ago I compiled a list of examples that some HR leaders found useful. Maybe you will find them useful as well. Below are some references I used to build this list and I think are a good place to start for HR professionals interested in the performance/professional development aspects of agile. They are a bit dated I admit, and those following my writing and twitter presence will find more stuff.

UPDATE: HR people are really excited about the AgileSparks Agile Leadership development program called LAST (Leading Agile Software Teams)

Individual and team goals

View more documents from Yuval Yeret


http://www.poppendieck.com/measureup.htm - about how to measure/compensate in a group accountability environment
From my own blog – try to think about what something like the Toyota Improvement/Coaching Kata would mean for individual goal setting… http://yuvalyeretblog.wpengine.com/2012/01/10/the-toyota-kata-book-review-and-thoughts/
What resources do you find useful for HR in an agile environment?

“We are already Lean/Agile” – Really?

Estimated Reading Time: 3 minutes

These days more and more organizations think they are Agile

A couple of years ago when you talked to people about agile a common response “why should we”, “it won’t work here”, or “so this is the new fad? What will come next?”

Times have changed. And a sign of the fact that agile is becoming more mainstream is that it being diluted and a common response these days is “but we are already agile!”. I want to share a couple of questions to see if you are indeed agile.

What does it mean to be Lean/Agile

At a very high level what does it mean to be agile ? At a first level agile is an approach to development that embraces the complexity and uncertainty in both demand, specification and implementation implications by working in short cycles on small batches of work, constantly seeking fast feedback, and empowering people to work together focused on clear business goals, at a sustainable pace.

A second level of lean/agile is about embracing the complexity of the systems/processes used to take software from idea to realized value and using an inspect and adapt approach to let better approaches emerge. This is a much more pervasive aspect of lean/agile. Organizations fail to realize the real power and improvements are as a result of multiple iterations thru process experiments, always aiming to achieve goals of better delivery capabilities.

Are you delivering in an Agile way?

When you hear someone talking about being agile ask them:

  • Do your users/business stakeholders consider your delivery cycle fast enough?
  • Are you developing the Right things? Do you use your agility to drive small features to production to validate the value of a certain direction and then continue to deliver a pipeline of more small features while constantly evaluating feedback?
  • Are you doing things the right way? How much rework is there in your work? How much of the demand is generated by not doing things right the first time?

Are you improving in a Lean/Agile way?

And then ask some more questions that will dive deeper into the improvement aspects of lean/agile:

  • How often do you stop to reflect on our performance/capabilities?
  • Do you have a capabilities goal/condition you are striving for? How many people are aware of it?
  • How do u know your current state compared to that goal?
  • Do you run process experiments aimed at improvement towards a target condition we are focusing on?
  • How many of these process experiments do you try in a month?
  • What is the cycle time from deciding to work on a process improvement to finishing an iteration of the experiment on it?
  • What are the current main obstacles to improving towards your goal? How long have you known about them?

What it means

You might find that you have an “agile” organization that is not so agile when considering the service provided to the business.
In many of those cases when you dive deeper you will find a weak, unfocused or even nonexistent improvement engine/culture and a static process/system.

Doing scrum sprints, user stories, or kanban boards is just the starting point of the agile journey.

The main event is improving. Practices such us limiting work in process or focusing on a single sprint help with that.
There is a whole set of approaches beyond that – A3, five whys, retrospectives, operation reviews, statistical process control, the Toyota improvement kata, solutions focus, theory of constraints and many more – all used to improve.

Are you ready for the real world of lean/agile?

You might find this recent prezi useful to look at these multiple layers of improvement and the various approaches used.


How to use Kanban to help improve your recruiting process

Estimated Reading Time: 6 minutes


I recently had the opportunity to talk with a couple of HR managers who were interested in how agile can help the HR department become more effective. This was a context where the product development is well into their agile journey, and we are talking about a group of about 20-30 people providing HR services like recruiting, training, social events to an enterprise R&D organization in the 1000 people range.

What does agile mean for HR

Well, I tend to view HR as a service driven operation. There is demand of various types coming in. The HR turns this demand into a service that the organization consumes/uses. A classic example is recruiting. Demand is the hiring manager with the new open position. The recruiting department helps fulfill this demand, and the end result should be position fulfilled.

So the First thing we did in the session was explain how lean/agile aims to maximize effectiveness delivering value leveraging the following understandings:

  • Most HR Activities are knowledge work with high variability and learning. We are not sure about a candidate so we want to maximize early feedback. We want to understand whether a training we got a request for will REALLY be interesting to the people to the level they will sign and allocate their budget to it, to avoid spending precious energy on things that get thrown away / changed later.
  • HR groups have a certain capacity. When overloaded performance actually goes down, same like motorways, computers, or development groups. So we should try to use a system that lets the group limit multi-tasking to healthy levels.
  • Activities that are only half done are very dangerous. We call that inventory / work in progress, and the more of those we have, the harder it is to operate. It is harder to focus, context switches cost more.
  • There is a lot variability in the demand as well as the work required to deliver services. During ramp up times recruiting for example is overburdened. Versatility within the HR department is valuable to assist in dealing with this variability.


With this context in mind, I outlined Kanban as a Method to drive for improvement in this context. What does this mean?
Kanban starts with the processes you currently have. You agree to pursue evolutionary improvement, and to respect current state but be open to change it.

What you actually do is take the following steps:

Visualize the Work

Visualize the process/workflow of fulfilling the demand. For example if we continue with the recruitment example – raise need for position -> create position description -> publish > filter candidates > best and final between a few top candidates > prepare offer > send offer > signed offer > prep for onboarding > onboard > 3 month – successful hire. With this workflow we draw a kanban board. I recommend starting with a simple board with a few steps – see below…

Now we populate the board with the current work, in each of the phases. A card represents a piece of work that when Done will mean fulfilled service ( eg one open position)

We can use different indications to show different kinds of work, work states such as blocked, who is currently working on what and more. The idea is to visualize as much of the state of work as possible. Ideally in a big physical board visible in the workspace of everyone or in frequently visited public space. This creates transparency that will in and of itself spark interesting discussions, raise problems to the surface and start creating a list of problems we need to handle ( which is good… )

We want people to use this board in their day to day activities. The board should be the main tool used to track work and synchronize. Lots of teams use daily sync meetings in front of the board.

Limit the work in process

Next step is to recognize that there are limits to capability, and work should be governed by capacity. What we actually do is assign limits to numbers of cards/items in process. The most common way is to say “no more than 3 cards in this board lane” or “no more than 3 positions we are currently writing descriptions for”. This creates a pull system, because it means that once that limit is reached, no new work can be pulled in, until some work has been pulled by the downstream process. This has the effect of “We’re all in this together, concerned about delivering value, rather than just doing our job”. Very quickly some slack will be created by the pull system. The magic is to divert this slack to help the work flow right now, but more importantly find ways to improve the capacity of the bottleneck that caused the flow to stop.

An example is probably in order. If it seems like many positions are in “sign” it might be interesting to use slack time to help create better templates or easier access to salary tables to reduce the effort it takes to prepare offers. If it also seems like a lot of offers are rejected since the candidate is not really serious, it might make sense to find a cheaper way to verify seriousness before spending the effort to prepare an offer. What you actually do will be context specific of course. The Kanban Method WIP Limit will just waive the flow problems in front of your face and beg you to deal with them, more intensively than before.

Manage the Flow

Start caring about the flow, the time it takes from start to finish, from request/demand to finish. Care about the mean time, the promises you can start making, the corner cases and what they mean and how you can improve by learning from them. For example if a typical position is handled start to finish in 4 weeks, and you see a position took 1 week, look at it and try to think what makes it a “Bright Spot”? Was the job description crisp and sexy? Was the hiring manager devoted to making it happen? Was the recruiter using some new sourcing technique? Same for the opposite case – what went wrong with that position that took 8 weeks?

Make your process policies explicit

This is a very interesting step. On the surface, this is very mechanistic. Seems like “Document your process”, what’s new here? And what’s Agile about it?

First, just to make sure we understand, these policies are the rules of the game. Things like the WIP Limit, the conditions for cards being done in a certain phase and ready for the next one, the policies for expediting work if necessary.

Explicit policies enable empowerment. They improve the level of coherency of the system among all people working on it. They can safely make local decisions that are aligned with the rules of the game.

Beyond that, Explicit Policies are not static. They should evolve based on new understanding and learning. You should experiment with them to see what works. The policies will be painful. You will sometimes feel you are hitting a wall. That they are creating constraints for you. That is good. Constraints drive creativity. And if the policies are constraining you in a way that’s driving you towards better and better flow, that’s great. It means the pain is part of the gain. The discussions you will have about what to do to make the policy work for you, will drive the improvement action items. Sometimes you will relax policies that went too far too early. Sometimes you will tighten things up to drive for more improvement. This is one of the key practical ways Kanban drives learning and Continuous Improvement – Oh that holy grail…

Improve Collaboratively using Models

Finally, with the system in place, after you start using it, there will be opportunities to use models that apply for Flow systems. I will not go into this. Suffice it to say that although the Kanban system might seem simple, there are a lot of ways to look at a system and improve it. If you’re interested in this area, I can refer you to more material on the subject.

This is it

Yes, might seem simple at first, if you’re looking for the revolution it is not here. On purpose. Kanban is an evolutionary method. It aims to provide an alternative to classic shock and awe change programs that many organizations had bad experience with. With Kanban you change at the pace that works for you. You can accelerate pace of change as you become more proficient in identifying the problems and experimenting with solutions.

What did the friendly HR managers think? Well, they liked this method, found it very applicable to various processes in the HR department, and can’t wait to start. We are meeting in a couple of days again to play some Kanban games and setup their boards. I will report when there is more to tell…

Note that nothing here is very specific to HR of course. This simple approach can be used to introduce change in many knowledge-oriented services. Many Kanban practitioners are reporting Kanban boards popping up in other departments when the IT group starts using it. It’s quite viral…

To be continued…

Lean/Kanban approach to Teams

Estimated Reading Time: 6 minutes

To Team or not to Team?

If you look at the definition of Kanban or Lean, you wouldn’t find teams anywhere there.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs
emerge from self-organizing teams”

Scrum is quite clear about the topic (Quoting the Scrum Guide 2011)

"Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to 
accomplish their work, rather than being directed by others outside the team. Cross-functional 
teams have all competencies needed to accomplish the work without depending on others not 
part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and 

So, if you are a manager of an organization on the Kanban train of evolutionary improvement, what does it mean for team structure? Should you keep the current structure? Adopt the Scrum Feature Teams concept? Do something else altogether? How should you organize your people to be as effective as possible in delivering value for the stakeholders?

Teams as an emerging property?

I personally believe that even if kanban the tool doesn’t talk about teams (obviously since it’s just a visualization and process-driving tool), despite the fact that the Kanban Method for evolutionary change doesn’t talk about teams (obviously since it starts from where you are, respecting your current structure, letting changes be pulled from actual need), more effective patterns for team formation will emerge when Kanban is really used.

At their core, Teams affect communication bandwidth. They partition the organization to enable increased communication bandwidth among people in a team, while counting on the fact that communication bandwidth to people outside the teams is not that important. Since we are talking about people, not network nodes, teams also allow the communication bandwidth to increase, the longer the team is working together, due to the team formation model. I recently read “The Talent Code” where the behaviour of our brain around learning new skills using myelin to wrap neurons to increase bandwidth reminded me of how teams behave.

So it seems like teams can really increase our effectiveness, and everyone in a reasonably sized organization cannot even bear to think about getting rid of the partitioning, right?

Well some of the Kanban thinking says that since Kanban massively reduces coordination costs via hyper-visualization and the pull system, the size of teams can increase significantly. Since we advocate using classes of service to allocate capacity to demand, thereby maintaining flexibility, we shouldn’t allocate people to demand.

The main reason not to go to teams is that teams might be local optimization. If our workload/demand was certain, and the uncertainty as to what effort/speciality is needed to deliver it was low, we could build the teams that optimize our performance. If that workload/demand didn’t vary over time, we could maintain the same teams and still have optimal effectiveness. But since in most environments we are facing a complex system with uncertainty/variability in the workload/demand, as well as the implementation effort/speciality required, it seems like sustaining stable teams will cost us in some optimization.

Team Modes

In my recent conference talks (GOTOCPH, LKBE11, LKCE11) I provided my view on this question of team formation and Kanban. I described the following progression:

  1. Functional/Component Teams based on specialization
  2. Teams On-Demand – whenever pulling a new Feature for work, associate the relevant people with it. They will deliver that feature, and after a few weeks return to their home teams. This approach provides lots of flexibility, but typically has relatively high coordination costs. It also doesn’t really benefit from the improved communication bandwidth among the team members that you get from persistent teams. This is very similar to the Feature Driven Development team mode by the way.
  3. Project/Initiative Teams – whenever pulling a new Project/Initiative for work, associate the relevant people with it. They will work together as a virtual team for the duration of that project/initiative, and after a few months, return to their home teams. The benefits of this approach is lower coordination costs as the teams don’t change that often. In addition the people working towards the same business goal are working together. The communication bandwidth increases as well over time, as well as the feeling of purpose and alignment. On the other hand, flexibility goes down. It is harder to shift people into projects/initiatives. It is harder to shift people out. If there is significant variability in the specialization required along the life-cycle of the project, selecting the right team becomes hard. If you work on versatility of your people, or already have a great group of generalizing specialists, this will be less of a problem. It can also be addressed by keeping a slack of several people working outside of project/initiative teams, that can be easily shifted in and out of activities on demand. It makes even more sense if those people are your experts/heroes. I’m seeing this mode in action in several organizations.
  4. Teams pull work – The next mode is where you create stable work cells that are able to handle almost everything you throw at them. These work cells stay together as the main organizational unit, and pull work based on the next business option the organization wants to exercise, regardless whether it is to accelerate an existing initiative or start something new. Here the communication bandwidth grows stronger and stronger. The flexibility and agility to shift business priorities and help swarm to work in process remains quite high, but the internal team flexibility remains an issue. The same slack of people not associated to teams can help here as well. I’ve seen this specific mode in action in several organization, and it works great, assuming you are ready for the change.
  5. On demand teams – Wait, didn’t I mention this one? Yes, I did. The difference here is that assuming you somehow have a tightly knit group which already managed to create lots of communication bandwidths among the WHOLE group, you can have a win-win. Total flexibility and global optimization. This should be the holy grail of any manager of about 20-40 people I would imagine. A force to reckon with…

Mixing it up

You don’t have to decide on one model. Not all work is created equal, so not all teams should follow the same structure. Some interesting examples:

  1. 80% on-demand, 20% focused on an initiative
  2. 80% on-demand, 20% cross-functional work cell (A-Team)
  3. 80% project teams, 20% on-demand able to swarm to a team in distress and help, or join a team to teach them some new skill as appropriate.

Evolutionary Change

Some organizations will jump in, create work cell teams, and start working. I’ve seen it in action, and when you REALLY have enough energy in the organization to make this maneuver, by all means go for it.

Other cases you will not have enough energy. Or you will THINK you have enough energy, but reality will hit you in the face when all the middle managers / team leads that led you to believe they are on-board are not that supportive once it is time for action and for supporting the actual new structure.

So think hard about what is your case. And if you want to go for a more evolutionary change mode, consider the following:

  • Start with on-demand teams
  • Pilot one initiative/project team – especially useful when you have a risky initiative with a lot of uncertainty and dependencies, that is mission critical. Assign the success of this team structure to one of your best and most trusted people, if not yourself. Whether he is the Coach, the actual Lead, or something else is secondary. The important thing is that he will be in charge of making the team structure work, and together with the team make the learning from that available to the rest of the organization
  • Move to more and more initiative teams as necessary
  • When a project/initiative finishes consider turning the team to a work cell to pull more features in that area, or more features in general
  • Ideally, teams will have the capabilities to take almost all work on. If not, use a talent matrix showing what teams can do what and gaps to invest in. As well as talent matrix inside a team that will help teams grow some internal versatility (note not everyone on a team needs to know everything at the same level)

Cautionary Notes:

When creating teams be careful not to spread yourself too thin. If you have too many small teams it might be an indication you are not managing flow effectively at the Initiatives/activities level. I love teams of 4-5 people by the way.

If you find many people need to be on many teams, you have a real problem. It is ok for a minority of the people, especially specialists, to be needed by many teams. Maybe they should stay as auxiliary on-demand, while spending some of their capacity offloading knowledge to the teams. But if it’s not a minority, then you really need to work on versatility, or the on-demand might be a better fit. The whole point of the teams is to create the communication bandwidth. Without that, they’re just overhead.


I presented a couple of team modes here, as well as one way you can use them. This is really context-specific stuff, so I cannot tell what will work for your case. But I hope the modes help you relate the Lean/Kanban effectiveness principles to the options of team formation. In upcoming posts I will try to relate this to a couple of thinking frameworks I grew fond of lately (RightShifting? Cynefin?)