Category Archives: Uncategorized

It IS about individuals and interactions (Even though it seems to be about process and tools!)

Estimated Reading Time: 2 minutes

Once in a while I hear a comment saying something along the lines of:
“Isn’t it kind of ironic that you agile people talk about Individuals and Interactions but what you give us is processes and tools?”. This comment typically comes after people are exposed to SAFe, Scrum, Kanban, whatever. All of these frameworks/methods LOOK like they are about processes and tools. I’ve seen people even mistake “Lean Kanban” for “LeanKit Kanban” associating it with a specific electronic tool and not the framework/method of how you manage flow using that tool. (To look at the bright side – I guess the LeanKit folks should be proud that they’ve become a “google it” in some circles …) Continue reading

How to replace the timebox-based motivation when using Kanban/ScrumBan

Estimated Reading Time: 3 minutes

I recently pointed a customer to a discussion around motivation when using Kanban compared to Scrum and other timebox-driven approaches. This blog post is a slightly edited version of my comments on that discussion, since I find myself getting into similar discussions quite frequently.

The question/context originally posed by Victor on kanbandev was: “We kind of dropped our previous Scrum process (or rather we decided to pay less attention to it because it was becoming less relevant once Kanban was in the picture. But one thing good about Scrum was that developers knew their story was due in 2 weeks so they paced themselves. With our Kanban system their isn’t an end date, so that motivator is gone. Can anyone suggest a replacement or remedy (other than Scrum, I really don’t want to go back)”

Here is my original response more or less verbatim:
When I was starting to advocate Kanban at AgileSparks, we were mostly a group of hard core scrum coaches/trainers, so we saw the sprint deadline and commitment as THE way to ensure high energies and self-organization within constraints and get rid of Parkinson’s law (work fits the container it is given). Over time, we saw that it is A way, and not necessary always the BEST way (due to the reasons quoted below, also see http://yuvalyeretblog.wpengine.com/2011/10/13/scrum-sprint-commitment-rant/)
What we saw through experience with different client environments were that there were some alternative ways:
  • A frequent delivery cadence on its own is typically enough to drive the right level of energies, even without a commitment to finish everything based on a sprint commitment. You can see this described in the FiftyOne.com case study in the Beyond Agile book.
  • A frequent DEMO cadence can be enough as well, believe it or not! not even delivery… It is sometimes enough to create too much pressure and technical debt, even WITHOUT any commitment to finish a certain package of work. People are motivated to show they are done if there is some opportunity to show and boast it. 
  • Continuous Delivery seems to be even a higher motivator. I’m not working with enough people doing this, but those that do report a kind of rush that creates great motivation to complete things just to see how they perform in real life…
  • Working with small units of value (e.g. Stories), Visualizing and managing flow is many times enough. But only if not, you can consider visualizing and managing “lagging/stale” cards more explicitly. I like for example the “Zombie Cycle Time” approach and talk about it and some of the other issues here in my Lean Kanban Benelux 2011 talk 
  • Purpose – clearly understood real external reason to deliver on a certain time. Whether it is a big deliverable built of many small things – where it is important to see whether you are on track towards that delivery using something like a CFD with release forecasting (trend lines/montecarlo/whatever), or a single value item that has a special delivery requirement. If people are aware of the deadline, realize the cost of delay, and ideally believe in the plan to deliver to that deadline, they will be highly energized.
Since you are coming from a Scrum environment, what seems to work for many teams as a starting point is to keep the cadence only relax the commitment to clear the table as well as to plan ahead exactly what will be the contents of the sprint. This is many times enough. You should look at the actual flow of work and determine whether there is a problem or not.
Regarding talking to the team – I would first try to go to the gemba and see what is going on, before bothering the team with it. If there isn’t a problem, even talking to them might create a Hawthorne effect affecting how they work, and not necessarily in a good way. Depends on the team. Only you know…

Upcoming conferences I’m speaking at – Fall 2014

Estimated Reading Time: 2 minutes

I’ve been very busy the last few months working with clients and the next months don’t look any better (Not complaining though…). As a result I need to choose very carefully which conferences to attend. As usual, I only go to conferences I’m speaking at. But this year I went even further and dramatically limited the CFPs (Calls for Presentations) I submitted to.

Lean Kanban Central Europe 2014 specifically is a conference I’m skipping despite it being one of my favorite events. But I decided to prioritize for meeting new audiences and communities, and something’s gotta give…

 

 

In the Lean Kanban world I’m attending and speaking at Lean Kanban France 2014 which takes place on the 5-6th of November. I was invited to speak there and it will also be an opportunity to see what is going on in the French Lean/Kanban community. The fact that Donald Reinertsen is giving his Applied Principles of Flow workshop that week in Paris and I will finally be able to attend it gives Paris a couple of bonus points… I’ll be speaking about good and bad ways to kickstart agile the kanban way based on our experience doing it in the trenches in the last couple of years.

A totally new territory for me is Velocity EU conference which takes place two weeks later in Barcelona. This conference focuses on the web world – both the technologies and the people/cultural aspects involved in creating great companies/operations shaped to succeed in today’s and tomorrow’s world. Since we are doing more and more work in the Web space at AgileSparks – either with medium-sized startups or with full-scale enterprises we are investing a lot of energies and attention into the DevOps/Continuous Delivery world. I’m going to speak about what we learned about using the Kanban Method as a way towards DevOps especially in the context of legacy enterprises. I’m also looking forward to learning from others and exchanging ideas as well as reconnect a bit to the technology aspects which I left behind ages ago (I did develop Clustering/High Availability/Networking solutions some years ago and was on the Networking/Security Ops side some years before that…).
BTW, If you’re registering to Velocity, use FRIENDSPKR to get a 20% discount. And come say hi when you’re there!

Other than these two conferences I’ll have to track other interesting conferences from afar…

Making Agile Teams work in real life – The quest for Stable Feature Teams?

Estimated Reading Time: 5 minutes

Context

This post is inspired by ongoing discussions in the AgileSparks team based on our experience trying to help organizations make agile teams work in real life. It is heavily inspired or can even be called a revision of a post from a couple of years ago on the Lean/Kanban approach to teams.

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

Scrum, the most popular framework for implementing agile 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.”

The scaled agile frameworks popular today (SAFe, LeSS) also put high value on Scrum Feature Teams. All of this is with good reason.  As Al Shalloway writes Cross functional teams eliminate waste and manifest lean. I fully agree. So where’s the problem?

One of the big problems with cross-functional teams is that they require structure changes. Let’s assume though that we overcame this challenge. We get to the another big issue. As teams spend time together they gel and mature and get a chance to achieve higher performance levels (assuming we are doing the right things to nurture this performance and not kill it, but many have written about it before so let’s leave it aside for now). See for example Tuckman’s stages of group development model.

This is why Scrum recommends stable cross-functional teams. So, again, what’s the problem?

Well, if we have very high staff versatility meaning everyone on the team can do everything and all teams can deal with whatever is on the organizational backlog, we don’t have any problem. We can create stable cross-functional teams and they will just deal with whatever we throw their way (or whatever there is to pull from the backlog when they have capacity for it, if you want to look at it that way…). Very high staff versatility is a great idea. Extreme Programming calls it collective ownership. Others call it “Full Stack developers”. For some reason, I rarely see it in the trenches though. Maybe it is just the contexts I’m working with but the variety of technologies and specializations is such that there are very few “full stack developers” around. And as a networking/kernel specialist in my background I’m not sure I would have liked to spend lots of time coding mobile application UIs or SQL statements for that matter. So the reality we encounter is that of at least some variance of skills.

We can deal with this variability, right? We can simply build the teams in a balanced way that is tuned to what’s coming our way. Each team will take features of a certain “work mix”. Essentially this means we will have a product backlog for each “work mix”. The problem with that is that now we are dictating priorities based on the team structure. Let’s say we built a team that is Server-heavy (3 server guys 1 client) and a team that is Client-heavy (3 client guys 1 server). Both are cross-functional able to deliver end to end features but of a different nature. This constraints our capacity allocation to be 50% Server-heavy features and 50% Client-heavy features. Now what happens if we suddenly need to deal with a big need for features who require same amount of work in client and server? Yes we can force-feed teams this work and expect server guys to work on the client side and client guys to work on the server side, on both teams. Yes, this will be a good investment towards Collective Ownership and versatility. Hopefully it is something these guys will find interesting and useful individually. Hopefully they will feel it is a worthy cause. Hopefully the ramp-up time will not be too long. This picture becomes more complex the more skills we need to work on improving. This leads to many people finding it hard to create stable Scrum teams. They find it creates wastes.

Now, let’s pause for a second. In many cases this is just a symptom of fear of change. The difference between Stable Scrum Teams and Dynamic Scrum Teams can be dramatic from the perspective of management (especially those team/line managers managing people directly). In Dynamic Scrum Teams and surely when continuing to work without Scrum/Feature teams altogether people these team/line managers continue to “control” what is going on. They continue to “own” the people and move them around. They can continue to live in the illusion that their old style of management is the right style of management. The move to Stable Scrum Teams, even if it doesn’t change the formal organizational structure, leaves no room for doubt. The team/line managers are not in the loop of day to day work the same way anymore. They have to do things differently. They need to focus more on attending to the bigger picture, to the capabilities of their professional teams/lines (What Spotify call chapters/guilds and others call Community of Practice/Professionals). So one shouldn’t be surprised that they rationalize however they can the downsides of Stable Scrum Teams. (Thank you Chris Matts for sharing some thoughts about this topic of Staff Liquidity during our Feature Injection chat today).

With this in mind, maybe you are saying, the hell with it, let’s do this change. It is all political change resistance. We need to strongly communicate the need for it, manage the change correctly, sell people on being “full stack developers” and have the patience to deal with the lower productivity while we are investing in our liquidity/versatility. And in many cases this will be the right approach.

Maybe you are talking the “Start with what you have” approach of starting with dynamic cross-functional teams that are created and dissolved on demand with the rationale that it is a smaller change but is still a step in the right direction. And in many cases this will be the right approach as well. A word of caution though – Remember your goal in the long haul though – make sure that you are investing in improving versatility along the way and building the capability for improving the stability of teams without reducing the business flexibility. Invest in management skills and style that is more and more oriented around the “Community of Practice” and “Capability Building” so that managers don’t associate that strongly the “daily allocation” responsibility with their identity as a manager.

And one more thing – Regardless of whether you go to Stable or Dynamic teams but especially if you go for Dynamic – let people finish something before they start something else. Don’t put people on too many teams. Ideally a person should work on one team. There are exceptions. But if you find people are working on too many teams they should either work as a “shared services” team and not as members of all these teams or you need to stop some projects/features and wait until people actually have the attention for them. The fact that the Capacity Allocation Excel can find a way to squeeze that project in with fragments of a Full-time-equivalent to be there supporting it just in the weeks they are needed is a surefire recipe for overloading the system and affecting motivation, quality, velocity and cycle times. Jim Benson’s new book “Why Limit WIP” has a great section (Eldred’s story from chapter 7 onwards if I’m not mistaken) about this BTW. I loved the introduction of Learned Helpness as a result of this situation.

 

PS Sorry for not providing a clear-cut best practice. But hopefully I gave you some ideas about how to choose the right approach to start with in your context…

 

 

 

 

Time for feedback – YuvalYeret.com Blog Readers Survey 2014

Estimated Reading Time: 1 minute

Amazingly enough, it has been 9 years since I started blogging, and about 5 years since I started blogging as an agile coach at AgileSparks. I think it is about time to hear what the readers think works well on this blog, what can be improved, and how useful it is to them. Retrospective, Inspect & Adapt and all. I’ve been looking at analytics all along trying to figure out what topics hit a nerve with the audience, especially when I curated the “Holy Land Kanban” book. But I never ran a readers survey before. Well – here it is. If you are a blog reader I would highly appreciate your input. And the benefit you might get from it is renewed energies to blog/write more…

PS I tried to keep it short, so it shouldn’t take you more than 5 minutes.