Category Archives: Agile

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

References

http://www.poppendieck.com/measureup.htm - about how to measure/compensate in a group accountability environment
http://agilediary.wordpress.com/2009/01/07/individual-performance-in-agile-team-assessment-and-individual-burndown-charts/
http://runningagile.com/2008/01/22/review-process-for-agile-team-members/
http://theleanmanager.wordpress.com/2009/08/20/what-are-the-traits-of-a-lean-manager/
http://www.infoq.com/news/2008/10/performance_review
http://www.infoq.com/news/2009/08/agile-managers-role
http://www.infoq.com/presentations/poppendieck-agile-leadership
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.

 

Exception Daily/Board

Estimated Reading Time: 2 minutes

Background

Energizing a kanban system has been an area I’ve been thinking of lately ( see my lkbe11 talk). One of the key areas of focus is how to expedite handling of exceptions to flow. What are those exceptions? Blocked items as well as “struggling” items that are not making the progress you expected. Identifying what is struggling is a non-trivial task especially in the face of variability, some of it inherent to knowledge discovery processes and unavoidable. I blogged some of my thoughts about this some time ago, and a collection of possible techniques is also available in the  lkbe11 talk mentioned above. Assuming we have some sort of way to classify work as “is currently a flow exception” we want to leverage this.

Exception Handling – Maybe what the doctor ordered?

Last week I was having a discussion with a team lead about the fact she thinks the team is not focused enough on dealing with exceptions, causing the exceptions to be the norm, the velocity/throughout to go down creating an overall feeling of sluggishness.   It is also hard to convince this team to use a physical board. They claim they have the data in an issue tracker. So an idea that came up is to maintain an exception-focused physical board, showing just the items that are blocked or struggling. This will the team to start looking at cycle times, and do some kind of TOC buffer management where after the mean cycle time passed, an item goes on the board. We think that visualizing these exceptions as well as having the daily meeting focused JUST on them will help the team, and even more important focus them on process and artifacts that can help them. This might create a chain effect of them continuing to fine tune their process and interactions to help them. I will report about the results of this experiment… BTW This reminds me of something I heard at LKCE11, I think it was Jim benson talking about TLC (The Library Company) – where they visualized the longest living items as a big visible chart, and within minutes the longest living items disappeared from the list. It is just a matter of what you look at…

Conclusion

As teams venture deeper and deeper into flow land, exception handling in realtime might turn out to be an effective way to improve cycle times, flow, and drive improvement at the team level. Teams should consider explicit policies for how they will handle exceptions to flow – will they swarm? slice more thinly? increase frequency of standup meetings? pull a specialist in and pair program with him? Even the discussion of flow exceptions and the need to do something about them would probably be an improvement in and of its own. I’m looking forward to the ability of more and more electronic issue tracking / kanban tools to provide ability to focus on flow exceptions like the ones mentioned above. Several tool vendors already have some capabilities. Leankit Kanban visualizes due dates in danger and has a filtered view that can probably be modified to see exceptions. Silver Stripe provides custom alerts. Another vendor has already shown me an alpha which is in the right direction. PS If you are a vendor with such a capability, feel free to comment and point to what you have… In general, I’m hoping tools will focus more and more on flow/time rather than velocity/throughput. It is a much more interesting and actionable perspective of the work…

Linking Team Modes to RightShifting

Estimated Reading Time: 2 minutes

What is Rightshifting?

When I looked at the program for Lean Kanban Benelux 2011 I found a couple of sessions talking about something I wasn’t familiar with – RightShifting. Since I had to speak at the same time, I didn’t have a chance to go check it out. Come Lean Kanban Central Europe 2011 I saw another session on RightShifting, again a conflict – this time with my Pecha Kucha talk. But I was curious enough to try and check it out, have a chat with Bob Marshall and think about it for a bit.

Yesterday, at home already,  a couple of thoughts clicked.

One of them was that my post about Lean/Kanban Team Modes might fit into the RightShifting model. I won’t go into what it is, if you’re interested go see the movie from Lean Kanban Benelux 2011:

Bob Marshall – Grant Rule – Understanding Effectiveness: Rightshifting and the Marshall Model from AGILEMinds on Vimeo.

Now, assuming you have some idea about RightShifting, here’s my thinking…

Team modes and RightShifting

Well, thinking about the ad-hoc phase I have in mind a start-up / small group where everyone is one big happy family, without any rules, hacking it out. No teams there for now.

At the dawn of the analytical phase, the group is too large, seems like we must introduce some discipline. Part of it is creating functional teams, and discussing the interfaces between the functions, roles and responsibilities, RACI, etc. This is the starting point for my previous post, and what I see in most organizations I start working with.

The synergistic phase seems to align pretty well with initiative/project teams and maybe work cell teams at it’s border with the Chaordic phase. These teams are more synergistic based on their cross-functionality and focus on business value purpose. Work-cell teams are more flexible, which is why I think they are a bit right-shifted from initiative/project/product teams. One interesting point is that some organizations wishing to go to “Agile”/”Scrum”/”Kanban” don’t always understand that this will pull them right dragging along the cultural mindset… They want this agile thing as a plug-in to their analytic mindset… That is always lots of fun to deal with 🙂

Where do we go from work-cell synergistic teams? Well, I think the return to on-demand teams, this time within a bigger group that already has wide any to any communication bandwidth so strong dynamic teams can be setup and tear down with minimal coordination cost, might be a good fit for a chaordic mindset. I have a few organizations on the verge of this transition, maybe exploring the framework with them will help formulating a vision / rationale for what is going on.

Disclaimer

I’m no RightShifting expert. Far from it. Just some thoughts I’m putting out there, with the hope they will enrich the conversation, and maybe interest a couple of my readers in RightShifting.

 

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 
productivity."

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.

Conclusion

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?)