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

Risk-aware Product Development (a.k.a. Agile)

Estimated Reading Time: 6 minutes

“There’s no predictability/commitment in Agile”

Over the years I’ve heard my share of these kinds of statements from various levels of executives:

“When my guys run a product development release I really want to know what I will get at the end so I can make business plans accordingly”

“In the old days when we ran projects we knew the timeline, we knew the scope, there were no surprises. These days it seems like the inmates are running the asylum. Product Management keeps telling me in this Agile way of doing things there is no committed scope, no plan, only ‘Responding to change’. I can’t help but think they are using it as an excuse for thinking short-term”

“When an important new/existing customer asks for a feature I really want to know whether I can commit to him that it will be delivered in the next release so I can get him to commit to a purchase”

“When you talk to people here, I want you to be very clear on the fact that agile will not take away the predictability they have so that they will not oppose the agile initiative we are trying to kick off”

This post is dedicated to you guys out there trying to make sense of the confusion surrounding predictability and Agile (Or as I often refer to it these days Risk-aware Product Development), whether you consider yourself one of the people quoted above or one of the people working for them trying to bridge the desire to work in an agile nirvana-like flow and dealing with those pesky executives stakeholders and customers bent on interrupting that flow.

Back to the roots

Let’s make it clear up front. I totally empathize with these executives. They are either already victims of “Bad Agile” or are basing their concerns off of a lot of “Bad Agile” going on out there. It is such a shame though because in reality agile product development actually maximizes the predictability you can have in your environment. Wait, That was a complex sentence. Why didn’t I just say “Agile provides great predictability” and get it over with? Because that won’t actually be true…

Let’s start from the beginning. Let’s talk about the contexts where agile approaches are required. One of the first things I discuss with executives is the concept of uncertainty and specifically Stacey’s Uncertainty Matrix.

stacey1

Types of Uncertainty in Product Development

I explain the concept of Requirement/Business uncertainty as the chance that you are aiming at the wrong target and Technology uncertainty as the chance that you’ll have execution problems getting there. I then ask the people in the room to classify the projects they are currently working on and typically get a picture somewhat like the one above with different projects having different uncertainty profiles. At this point it is typically easy to get to the understanding that when you have low uncertainty predictability and success is a matter of careful and disciplined execution of greatly crafted plans.

Dealing with Technology Uncertainty – The Waterfall Passive/Buffered Risk Management Style

When uncertainty starts to mount, it is a different ballgame. Teams facing technology uncertainty with big batch waterfallish approaches only get REAL predictability (meaning the one that stays valid all the way through release of high quality product with the committed scope) through huge buffers.These buffers serve to hide those horrible big bang integration hells that are the source of statements like “We are totally on track all the way through development but when we reach the code freeze period all hell breaks loose and we don’t trust a word we’re told about when the product will be released”.

Dealing with Technology Uncertainty – The Agile Active Risk Management Style

Agile teams in this context should be able to provide predictability by weighing the amount of effort required to achieve the business expected outcome, taking into account the amount of uncertainty, and make some buffered plans at the high level before going into low-level iterative product development aimed towards achieving those high-level commitments. You not only get predictability of “If we said we will deliver this feature in this release then that is what we will do” you also get visibility of progress towards meeting that commitment by seeing working product frequently and getting reports based on real integrated progress.

fieldofdreams

Dealing with Requirements/Business Uncertainty

Here, definition of success is actually a bit different than what executives are used to. Success doesn’t necessarily mean delivering according to commitments. It means hitting the target if it is indeed a real target and alternatively learning as quickly and cheaply as possible if we are aiming at the wrong target. This is not some theory we’re talking about. Data from more than 50,000 projects suggests 50% of features developed are actually not used. (See Chaos Report 2013).

Is Predictability what we want?

So aiming at the right target is not a trivial task in Product Development, especially if you are in a more innovative space where it is not even clear that there is a market need for your product, but also when you are working on internal IT projects where this kind of uncertainty seems irrelevant… In the Lean Startup movement we typically talk about the “Build it and they will come” fallacy. Actually we are NOT sure they will come, so we want to be very careful with what we build without knowing. Predictability might be a dangerous thing to wish for in this environment.

The Risk Burndown Exercise

risk

An exercise I often use to get this point across is to ask people in the room to draw a chart of the amount of risk/uncertainty in their projects from initiation all the way to the moment all risk/uncertainty has been exposed. the X axis reflects time or stages in their “Stage-gate process”. The Y axis is “remaining risk/uncertainty” in either the Business/Requirements/Technology domains. One answer I typically get is a line curving up at some point only to go down later on. That is impossible. Risk is there. If the line curves up what you mean is that you actually just become aware of the risk at that point. I guess this is the best indication of the fallacy of “predictability” people have. Others start with the maximum risk and then go down quite quickly – telling me that they learn everything they need to learn at the point of “Requirements/PRD/Design” and from then on it is a matter of execution. I then typically ask whether they find surprises/defects later on in the cycle and whether they actually know all of their features are in use. This typically gets them closer to the epiphany… Others get it by this point and draw a chart where a lot of the risk is there active until you finally get to have your software/product in the hands of real users. At this point the discussion very quickly gets to the main way to reduce the time of active risk – cutting projects/products into smaller pieces so they can get to be “Working product in the hands of users” faster. (Which is by the way one of the key differentiating factors of successful projects regardless of methodology according to the Chaos Report)

A reverse correlation between Business uncertainty and the need for Predictability?

Luckily enough it seems like Predictability is typically required when there is a strong business need on the other end of the line (if there is a partner/customer adamant on having that feature it kind of reduces the business uncertainty of whether it is a real need…). So effective classification of projects into the right uncertainty/predictability profiles will typically help satisfy the business executives without creating unrealistic expectations from the product development group. There’s still the need to understand you are sometimes running small “startups” or “venture capital” inside your product development portfolio, which might be tough for an execution-oriented IT/product development executive to fathom. Geoffrey Moore talks a lot about these kinds of struggles in “Escape Velocity”. Which is highly recommended reading by the way.

Takeaways

So, with all this in mind, what can you do?

My advice to executives is to make sure they and their teams understand the uncertainty profile of each of their projects and act accordingly:

  • When uncertainty is low, use whatever kind of process to deliver the desired outcomes with high predictability.
  • When dealing with technology uncertainty and medium/low requirements uncertainty (Sustaining Innovation) and it is desirable to be predictable, use effective agile release planning approaches to setup a reasonable plan with maneuvering space to account for some requirements/execution uncertainty using either a time or scope buffer (a set of features that are considered stretch / weight to be jettisoned in case of problems).
  • When dealing with serious business uncertainty (Disruptive Product Innovation space?) make sure that a fast iterative approach is used to minimize “building it before knowing whether they will come”. Learning needs to be  emphasized over predictability in these environments.

 

 

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…