Kurt's Blog

May 20, 2013

Pricing, and a little bit about estimation.

Filed under: agile, kanban, lean, scrum, Uncategorized — Tags: , , , , , , — Kurt Häusler @ 12:54 pm

So I keep getting involved in discussions on twitter related to the different ways of basing prices for software projects, and it is hard to get some of the subtle details across in 140 character snippets so I thought it might be a good idea to put some ideas together in the longer form of a blog post. The whole thing is somewhat related to the #NoEstimates debate.

I also believe the base of my ideas is fairly mainstream. Most of the agile community (dominated by the Scrum community) talks about estimation in terms of estimating PBIs so you can plan how many to take on in each sprint. A few people still do it in ideal person days like Mike Cohn recommended back in the dark ages, which I am opposed to (but not to the point of getting into arguments about it) as I think there are some serious downsides to that approach. That is not a radical opinion, and it is the reason why most people use more abstract, relative units of size like story points, which I personally don’t advocate, but I don’t oppose either. Even most of the defenders of story point estimation for sprint planning recognise that the true advantage is in getting the team to talk about what needs to be done, and the actual estimate is a secondary benefit. A few of the more advanced teams, and even the inventor of story points Ron Jeffries himself, prefer to simply use a count of PBIs. This is the approach I find most sensible, when combined with backlog grooming and story splitting. Also after using Kanban for several years I have realised that estimating is pretty much wasteful. I don’t think that is a radical opinion either as it seems shared by much of the Kanban community, who make use of a metric called throughput which is essentially the same as velocity and is typically presented as a number of items done per unit of time.

But as long as all we are talking about is how many items to plan for each sprint, who cares? The consequences of over or underestimating are minimal. If we plan too few ask the PO for more, and the velocity goes up to plan more for the next sprint. If we over plan then we drop the velocity and plan less for the next sprint. As long as this is all we are using estimates for then who cares how we do it.

For me estimates are only really a problem when they are taken more seriously than intended. For example when calculating prices, or when forming an offer or contract that a customer may rightfully interpret to be a commitment to deliver, and expect to be based on something more solid than a guess. Sadly the agile community talks so much about estimation in conjunction with sprint planning, and very little about contracts and pricing. I have even heard people say that the way that contracts and prices are done is completely orthogonal to how the software “project” is carried out. I disagree completely. From my experience the way the contract is written and the way the work is priced are the fundamental factors that indicate to what degree any software development endeavour will be “agile” or not. Or should I say to what degree it is even appropriate for knowledge work and product development, or anything in the complex domain for that matter.

If some manager comes to the team and says “these requirements have to be done by the end of July, and we have a budget of 20 architect “person-days” and 60 developer person-days and 30 tester person days and 10 manager person days, now use Scrum to make it a reference agile project”, then your options are pretty limited.

I think the disagreements in the NoEstimates debate are based on a misunderstanding. The ProEstimates crowd are saying “What is wrong with estimates? It is just a simple tool to help teams plan how much work to take on each sprint”. The NoEstimates crowd are saying “if you are making promises to customers, and trying to price your work, there are much more professional ways to do it than guessing”. The ProEstimates crowd just don’t see things like offers, contracts and pricing to be relevant. Heck the Scrum Guide doesn’t even mention them. All that businessy stuff happens way upstream anyway so we just have to accept whatever deal management outside the Scrum team has made, and as long as we carry out the work according to Scrum we are all agile right?

I agree with both sides, which is possible because they are talking about completely different things. I just find the ProEstimate argument to be boring, obvious, non-controversial and not addressing any particular problem. The NoEstimate argument on the other hand is advocating one of the critical next steps that the software development community needs to take in order to restore a culture suitable for software development and good faith with our customers.

The other misunderstanding I see in the NoEstimates debate is that the ProEstimates crowd thinks the NoEstimates advocates are somehow refusing to answer questions like “How much does it cost?” and “How long will it take?”. This is quite false. As far as I am aware the NoEstimates crowd are attempting to answer exactly these questions using techniques with a higher level of professionalism and more reliability than guessing.

Anyway the opinions I have on pricing are based on experience, and they are also more relevant to some contexts than others. I believe this blog post is highly relevant to the following types of software development, which is where I have most experience:

  • Companies doing custom software development work for other companies.
  • Product companies where the customers pay for the features they want and even the bugs they want fixed.

I suspect this blog post might be less relevant for the following types of software development:

  • Internal IT. I have little experience in this area, and even less in how it is priced and funded, but I suspect things are a lot simpler than when dealing with an external customer
  • Product companies where the product is funded in another way separate to the development of features. E.g. via a subscription model, or advertising, or purchases of new versions. I do have a bit of experience in this area, and things are a lot simpler.

I think a lot of people on the ProEstimates side of the fence are engaged in the latter areas and simply don’t see the issues that the NoEstimates guys are having to deal with.

There is also a grey area in-between, such as where are large company has outsourced its IT and while the company doing the software development is technically doing custom development for a customer things are also much simpler as there is only one customer. In effect it is basically the same as internal IT.

So what is the problem?

I have worked for a number of companies in the former category that used similar methods for pricing software and suffered similar disadvantages because of it. Generally these companies rely on a horrendous mix of time tracking, rate cards, up front estimation in person-days, time & materials billing, bookable time and “slack” divided up according to percentages, and the need to explain to customers why the actual amount billed differed slightly from its up-front estimate. For me this is the worst. And so many of these customers are using agile approaches like Scrum to develop the software too. You would think they would be aware of the dangers of things like time tracking. The community (with the exception of Scott Ambler) seem to be unanimously against it. But unfortunately those with an understanding of knowledge work and product development are not those making the deals. They are usually a very different type of person unlikely to read books like Don Reinersten’s Flow, or engage in the subtleties of the economics of software development at conferences or online. They are more like the software equivalent of the used car salesman. 

So here is how it works: the customer has an idea of what they want. Sometimes this is just a vision (which is good), sometimes it is a more detailed list of requirements (which is ok, but a little bit wasteful as it is highly likely to change). The salesman will then take some of the team capacity and if the customer only had a vision those team members will then have to come up with some business and technical concept and estimate how many person-hours of each role is required to develop each bit of the solution. If the customer presented a more detailed list of requirements then they can skip the business concept, and just come up with the technical concept and an estimate. The salesman has to choose carefully how many and which team members get to be a part of the conception and estimation activity. You don’t want the whole team as this is all non-bookable time, which is perceived by such cultures as expensive, so usually the salesman picks the architect, the analyst and the best senior developer, or something like that.

This approach is already non-agile, or worse than that, it is fundamentally against the realities of knowledge work and product development, regardless of “agile”:

  • The idea of having a complete set of requirements at the beginning is long known to be unrealistic, the the downsides to this way of thinking are well known. Many of the requirements will, according to the Pareto Principle, be superfluous in the sense that their effort in being developed will be out of proportion to their use in the finished product. It is also a myth that anyone can know in advance what is required, This always changes. The customer never gets exactly what they want, and even before they see the first version they change their mind about what they think they require.
  • It is actually preferred, and more realistic to start with a mere vision. This allows the true scope to be discovered, adjust and grow as the development endeavour proceeds, and starts off with the knowledge that scope is and should be negotiable. The idea of having a complete set of requirements works against this. For the actual software company to start with something good (a vision) and discard all the advantages by turning that into a detailed list of requirements up front is bizarre and ridiculous. The chances of it being what is actually best for the customer are even less than if the customer themselves came up with a list.
  • It is also pretty disadvantageous to select a sub-set of the team to create the conceptions and estimates. This requires crossing the problem-solution line, and breaks one of the rules of estimation that it has to be done by the whole team. In software development, the team should be problem solvers. They should get an idea of something small that the customer desires, and work with the customer in solving the problem, implementing the solution as software and realising it as true customer value. With the used-car-salesman approach, the small sub-team of elites are trusted with the task of solving the problem, and determining the solution up-front, and the actual development team are reduced to mere source code typists, which is highly demotivating.
  • Additionally the estimates are usually much more optimistic than if they had been given by the team, and those in the sub-team are not available to the development team for assisting with the actual development of actual software.
  • It is also a waste of time, all these discussion that take place during conception and estimation still need to be held again so the actual whole team can understand them. (At least this second discussion might be bookable to the customer).
  • If you are using something like Scrum, combined with estimation in story points which is fairly typical, you have to go through and estimate everything again anyway.
  • Also these estimates are usually “ideal”. They only reflect the actual minimal time an expert might spend on typing in the solution once and that is all. Anything like research, or learning, or pair programming, or communicating with each other, or improving the system, or tests, or refactoring is extra. That is why project managers add a buffer to to the estimates or the price that the customer sees, so they have some wiggle room later, but the actual team still sees the tighter estimates. After all if you let them see the actual buffered values they will simply chew the buffer up with non-value-adding activities like refactoring or writing tests, and there won’t be any buffer left at the end to make up for the shortfall which for some reason always occurs at the end.

So what happens next? The developers start counting hours present in the workplace and recording them in some electronic system. This is called time-tracking, and suffers the following problems:

  • Some people say the main or only problem is the time that time-tracking takes. This might be the most obvious issue but it is the least of it. Sure it can chew up around 15 minutes per day, but time tracking is much more evil than that.
  • The developers have a budget per feature, and there is a general hectic vibe with everyone primarily concerned with which booking position every minute of the day belongs to. No one want’s to be the guy that has less bookable hours than anyone else. In fact everyone tries to keep their bookable hours as close to 100 percent as possible, as the general perception is that any hour not booked is wasted. Typically project managers and even product owners insist that anything like knowledge transfer, or writing tests, or refactoring or even one person in a programming pair shouldn’t be at the customer’s cost, and has to be booked to an internal booking position. As a result, these activities simply do not get done, or at least no one wants to spend much time on them.
  • The teams more expensive roles end up siting there idle. Since the project manager was involved in the technical conception and estimation, and was concerned with presenting as low a cost as possible to the customer, he preferred to see more (cheaper) junior developer hours being offered as more expensive architect or senior developer hours. As a result, even when the team is struggling to meet its sprint goals, the architects sit there doing nothing because if he did the work the customer would get a more expensive bill than if the junior developer did it. The customer would then come back and demand to know why he was charged architect costs for something that could have been done by a junior developer. As a result project managers insist on architects NOT helping the team to meet their sprint goals, which damages the feeling of trust in the team.
  • A related issue is when cheaper developers get assigned the tasks where there is a high risk of requiring more time than that estimated. I have seen a team suffer a huge drop in motivation when a student, with a cheap per hour rate, was given all the most interesting tasks (that were sold to the customer as junior or senior developer hours), because he essentially had more than twice as much time as estimated to do it, and you automatically have some extra buffer for the risky, more innovative and interesting parts of the “project”.

I hear a lot of managers claim that time & materials works well for them, and that estimates correspond very well with actual development hours. That is because developers are painfully aware of their budget, and compromise on quality in order not to “overspend” their time budget. Without fail these managers also wonder why they run into technical debt issues a year later. Actually they don’t wonder. They know it is down to poor commitment and discipline on the part of the developers. On the other side of that coin is that it discourages innovation, and encourages maximising expended effort. Assume a task was estimated at 5 days. If someone can find a clever way to do it in 2 days he probably should right? Well with T&M there is no incentive. If he does it in 2, then he might not have anything else to do for the week and his bookable hours will drop. Also the company will  get 3 days worth of money less. Usually project managers solve this by shuffling hours around and lying to the customer about what took how long. They will simply say it took 5 days, and use the extra 3 days to reduce something that took longer than expected.

Particularly sad are the companies that think they are cool and generous like google for allocating a 20% “slack” time that doesn’t have to be bookable. This implies that everyone is under extreme pressure to book the other 80% of their time. Guess what ends up being done in the 20%? Meetings, bug fixes that the product owner thinks should not be billed to the customer, writing tests, learning from other developers, pair programming and refactoring. It is much better NOT to have such a percentage goal of bookable hours. The team needs the freedom to decide for themselves how to best to allocate their time in order to deliver, and besides, the customer pays for everything anyway. It is not like the government pays for the 20% time. This trick might look good at first glance, but it is total bullshit that has no pros, and only cons.

There is one general issue that lies at the root cause of all the parts of this nasty approach to pricing software development efforts: The idea that it is appropriate to measure software in terms of person-hours. Once we get beyond that dangerous myth, we instantly solve a number of problems and we open things up to the next level of professionalism in managing software development.

So what is the alternative?

So let’s look at better models for pricing software in order from best to worst, according to my opinion:

  1. Value based pricing: The best way to price software is according to the value it brings the customer. We can negotiate with the customer and help him discover what sort of value the delivered software might bring, and come up with a price that correlates with the expected level of investment required to bring such a return. However I find this suffers from a couple of problems that might make this approach difficult:
    • Business value is hard to determine. Software development, when worthwhile, is a high risk endeavour, featuring an asymmetric payoff function similar to the development of medications. We can expect to start a large number of experiments with the hope that they will be highly successful, and expect that most of them will be canceled as soon as we discover that they are not going to be a big winner. The occasional big winner results in so much profit that it more than covers the losses associated with the “failed” experiments. (Actually, the information we learn from these experiments usually makes the investment worthwhile, so failure is probably mot the right word). The fact is, we often have to at least start the development process and test a feature or two on the market before we even know what its value might be. This is hard enough at the project level, and even harder at the “story” level that agile development prefers, so I suspect for this reason value based pricing to be very difficult in practice. One model that could work would be to measure actual value afterwards, but this requires a high level of trust, and exposes extra risks for all participants. It essentially makes the software development company a full stakeholder in the product, which may or may not make business sense.
    • The other issue is that customers may not be willing to share their expected value, even if they know it.  They want to get the lowest price possible, and not give the software vendor a hint as to the maximum they might pay. There are also a lot of things that can be done cheaply and easily, but result in huge wins for the customer. The vendor might think it is fair to take the usual percentage cut of the wins, but the customer most likely does not.
    • Even if we know the customer value, before we decide if we should do it or not we might like to know to what degree, if at all, it covers our costs. This means that even when using value based pricing, we might still have to use one of the following more cost-based methods to determine if we should do it or not.
  2. Price per feature (determined at time of commitment): My current favourite model is very simple and based on measuring the teams price per (average) groomed feature. It works especially well with a system where Kanban plays a role. You should have a rough idea of your costs. Ideally they are mostly a function of team salaries and fairly fixed, otherwise in more dynamic environments you can determine separate components, perhaps basing it partially on an average of previous months, and known costs for the next month. You simply divide these costs by the throughput and add an appropriate margin. Before the customer and team commit together to developing a feature, some backlog grooming should occur and the team should perform the usual steps of story splitting. Queue replenishment consists of presenting the split stories to the customer, together with the current price per feature. They can select as many stories as there are free places in the input queue. When working with multiple customers it is good to authorise the product owners to do this on behalf of the customer, or to establish some idea of how much team capacity is to be allocated to each customer (ideally in terms of total system WIP). This shouldn’t be too big a deal, the PO can communicate with the customer up until queue replenishment about what the price could be and how many free slots the customer will have. The price is fixed at the time of moving the item from the backlog to the input queue, and payment is due a number of days after the item is done. If you have a two stage commitment system, or end up cancelling more than a handful of items in the middle of the process and have multiple customers then it could get a little more complicated, but I might blog separately about that. I don’t currently see any disadvantages, but I know someone will have some questions about it so please challenge me in the comments, and allow me the opportunity to make this concept even more solid. I know a lot of people seem to think it will only work with items that are “roughly the same size”. This is not true, and in fact the concept of size is a bit bogus when considering the whole value stream. We groom and split in order to preserve some liquidity and flow in the process, to prevent large items from blocking the system, and to inhibit the lead time distribution from blowing out too far to the right. I fully expect significant differences in the measured lead times of different items, that is the reality of knowledge work and product development, but there is no real need why they all need different prices. If the customer has 3 features in the backlog, but only feels 2 are offer enough value to justify the price per feature, then he should only choose those 2.
  3. Renting team capacity for a period of time (in terms of system WIP, not in available person-hours): This might be an ok option for those doing a longer term software development effort, and wan’t to save the communication overheads of accepting a small offer every week or so. It is also based on a Kanban approach. Assuming costs (plus margin) of 100,000 per month, and a total system WIP limit of 100, then we could have one customer paying 30,000 per month for exclusive rights to 30 of that WIP, and so on. If the throughput is 100 items per month, we might expect he gets to see 30 items per month. Or he might not. We could provide both options and allow him to choose which is best for him.
  4. Fixed price per team-day or team-sprint (aka. T&M light): This is probably good for Scrum teams, or teams when you only have a single customer and don’t have too many issues with balancing capacity between different customers or classes of service. It is also based on costs plus margin. One discussion I got into recently on twitter was with a defender of T&M. It turns out they don’t do up-front estimates of entire projects, they don’t have rate cards, they don’t have a target number of billable hours and most importantly they don’t do time tracking. Basically for every day a team works, they get a bill for a team day with a discount for team members on holiday. To me this is a lot closer to a fixed price per team-day than the true T&M monster as typically practiced. However they reported it requires a large amount of trust, and only works when the team has a single customer (which some consider ideal, but I personally consider it a risk of the “all eggs in one basket” variety.) The team just developers iteration after iteration until either the product is good enough, or the customer decides they have spent enough money.
  5. Fixed price variable scope: This is the classic agile fixed price scenario where there is some budget set up in advance, and the team simply develops iteration after iteration until the money runs out. It is essentially equivalent to the fixed-price per sprint, except presumably the option to quit before the fixed budget runs out is excluded. I don’t know what is supposed to happen if the product is good enough before the budget runs out. I guess the team is supposed to keep developing unwanted features until the budget runs out. There is also the question of how is this budget determined. I guess the customer has some idea of what he wants to spend. I could also imagine it being based on a rough release plan, which is in turn based on an initial but negotiable backlog and a known velocity. I am not sure what advantages this model brings over the previously mentioned ones.
  6. Fixed price, fixed scope, but the price is obviously sufficient to cover costs and the scope is easily achievable by the due date: Sometimes we get lucky even with dysfunctional traditional methods. As long as we ask for more than enough money to cover things even if things go wrong, and we leave ourselves plenty of time to get things done, even with the inevitable changes in scope, then why not? It is still better than the full-on T&M model with all its disadvantages. But not much better.
  7. Fixed price, fixed scope, fixed due date, and the team thinks it will be tight: This might even be worse than full-on T&M. I don’t know which one is worse. They are both extremely damaging. Sadly they are the 2 most common approaches. In fact the typical Scrum-using but otherwise not very agile company thinks they are the only two options. They are convinced that one of them is not “agile” so the other one must be. Usually a company has a bad experience with number 7 so declares it un-agile, and then feels super smug and ultra-agile for using full-on T&M together with Scrum.

So there you have it. My current views on the various approaches to the pricing of software development. I have to mention again that my favourite is 2. I don’t really have a problem with any of 1-4. I don’t see much point in 5. 6, 7, and the full-on T&M I described at the beginning are the used-car salesman approaches. They are lazy, damaging, unprofessional and betray a poor understanding of how knowledge work and product development works. Instead of violating our customers and teams with such approaches we need to think about things a bit deeper, and consider the damage we are doing, and start behaving more like professionals. The relationship between the software development and the customer is too important to be left to sales-people. It requires product developers to be involved. It needs to be more like the way a doctor and their patient communicate, than the way we currently operate, as if it were possible to fix scope and sell person-hours like the kids at McDonalds sell fries.

I recently read a blog post from someone, it isn’t that great, it exhibits one of the misunderstandings about NoEstimates (he somehow thinks NoEstimates is all about refusing to answer the “how much” or the “how long” questions), but one quote was interesting:

If you don’t know where you are going, if you don’t have some notion of what done looks like, if you can’t tell me approximately how much and how long, please don’t start.

At first I thought, woah wait a minute, this pretty much excludes anything in the complex domain, aka anything worth while. Even beginner agilists know that software development is an experimental process, and it is quite typical to begin something before we know how much it will end up costing, or how long it will take. But on second thought I agree with him. There is no way to know what done looks like when we are talking about a large project, no way of knowing how much it should cost, and no way to know how long it will take. They can only ever be discovered once we have invested some effort in the information generation aka software development process. So I agree. We should not do large projects. However we do know what done looks like at the story level. We can say how much it will cost, and we can provide a certain degree of confidence about how long a story will take based on concrete measurements and backed up by statistics. So I agree. We should only ever do story sized things. Actually why not take his quote even more seriously and use it to base our definition of what we should attempt to develop? If we don’t know what done looks like, we can’t put a price on it, and we can’t say how long it will take then we shouldn’t start it. It is obvious what he means. We shouldn’t do anything larger than stories, we have to get away from projects being the main batch size of relevance to pricing, offers and customer communication in general.

So here are the main points again:

  • Don’t sell person-hours, it is not appropriate for things like software
  • Don’t pretend scope can be fixed in advanced
  • Don’t use time tracking
  • Don’t use T&M billing
  • Only estimate where and how it is appropriate, the whole team may use story points to plan how much work to take on per sprint, and that is pretty much the only place for estimation in software development.
  • Never estimate in hours, only relative units like points
  • Never base prices on estimates, use measurements instead
  • If you have customer contact, write offers, work out prices or negotiate contracts, please go to a couple of conferences, read a book or two, and engage with the community
  • Don’t think you are cool by gifting your employees 20% slack time (by insisting 80% of hours must be bookable), all you end up doing is pressuring the employees not to spend time doing what they should. And it really messes with the idea that a team should self-organise
  • If the offer and pricing is fundamentally not “agile” or at least makes no sense from a knowledge work and product development perspective, then planning the development using Scrum won’t help you much
  • Forget about “projects”. When it comes to prices and offers, we don’t want to deal with anything larger than a story

I have a feeling this might be a blog post I keep coming back to and refining. I already suspect I have left some interesting details out.

Any questions or comments? 

Addendum 1: Two additional models that I have been made aware of but forgot to include to this list are the “price per story point” model. I don’t prefer it, as it suffers from many of the same disadvantages that other approaches based on up-front estimation suffer, but if you are estimating in story points anyway, it might work for you. I would probably put it somewhere between 4 and 5 maybe. The other model is the incremental funding method. This is a really great one if you can get it to work. In this method we minimise initial investment and risk, and focus on developing a product that makes sufficient money to fund further development. This concept isn’t really an alternative pricing model as such, and can thus be combined with any of the above listed pricing models as an additional technique. You could even use it to filter out projects that should not be invested in past their initial MVP. Any projects that don’t self fund after a calculable investment in money or time should be cancelled, so that that investment can be channeled in more worthwhile activities. I believe Don Reinertsen’s book Flow even presents some useful numbers that can be used to help support such decisions in the section on asymmetric payoff functions.

May 11, 2013

The Limited WIP Society Rhein-Main

Filed under: agile, kanban, lean — Tags: , , — Kurt Häusler @ 4:33 pm

I just wanted to write a short note to inform any interested readers that I am in the process of setting up a Limited WIP Society in the Rhein-Main region (the region around Frankfurt). A Limited WIP Society is a user group mostly for those interested in David Anderson’s Kanban method for supporting evolutionary change in your knowledge work and product development processes and systems.

Go Lean Limit WIP

Some of the other topics relevant for a Limited WIP Society include:

  • Flow-based product development
  • The Theory of Constraints
  • Lean Systems
  • Systems and Complexity Thinking
  • Modern management methods in general

I have set up a Xing group that as of writing already has 21 members, and I have planned the first meetup which will be an informal gathering at a restaurant later this month. If you are interested in any of the topics mentioned above then please come along. I hope to see enough interest in organizing a regular meetup. Ideally in a location more suited to other formats like the lean coffee format or talks.

Yes We Kanban

The first meetup will be somewhat casual, focussing on getting to know each other, sharing our experiences and tips, and making plans for future events.

You join the Limited WIP Society Rhein-Main here: Limited WIP Society Rhein-Main Xing group

You can register for the first meetup here: First meetup of the Limited Society Rhein-Main

Vote Ltd WIP

Here are some other interesting links:

Advocate Ltd WIP

Thanks for reading, and I hope to see you at the next meetup!

December 6, 2012

Lean Kanban Netherlands 2012

Filed under: conferences, kanban, lean — Tags: , , — Kurt Häusler @ 5:59 am

Over a month later, I am finally getting around to blogging about this great conference I not only attended, but spoke at. Apart from open spaces, and leading semi-prepared informal discussions at user groups and stampedes, it was my first time presenting at a conference.

David Anderson‘s keynote was of course very interesting. I found his idea of a second, or multiple, committal points interesting, and the idea that the lead time should stop at the first non-WIP-limited queue or buffer (and presumably start again from the next WIP-limited queue or buffer). I am not convinced on that last point. I think even if a buffer should be non-WIP-limited because it is under the control of an external stakeholder, it could still make sense to include time spent there in the lead time, if you are using it to predict how long things might take. Why not just take both lead times I guess. 

He also mentioned that the cost of delay was perhaps more useful at the portfolio level than the user story level, expressed some interesting opinions about calculating business value, and combining that with strange cost estimates, which is how a lot of product owners etc currently spend a lot of time. An alternative could be to focus on risk. Capacity-constrained people should never work on optional things like estimation as it brings the whole team capacity down, only those with slack capacity should do such things. The bulk of his talk was about liquidity which is something I need to spend a lot more time looking into. He presented some interesting metrics such as “pull transactions” per person, or per unit of money.

Another interesting session on the first day was Ralf Kruse‘s Kanban Pizza Game. It was good to do something a little bit physical after sitting in a chair watching others talk.

Laurens Bonnema gave an interesting talk that appealed to me, because talked a lot about the more subversive aspects of culture hacking. There were a lot of good tips for being an effective change agent, and not the usual types of tips one reads either.

The evening meal was pretty classy. Lots of little courses, very delicious. It was a great location too by the way: De Fabrique

The next morning I realised I drank too much at dinner the night before and was worried I wouldn’t survive my talk. I found Don Reinertsen‘s keynote a little heavy going. Lots of graphs and maths and I had trouble relating it back to the concrete experience of helping a team develop software. Someone else mentioned he should try story-telling. Then I gave my talk. I think it went well, but there was a minor technical hitch. The screen-saver kept kicking in,and the main presentation display kept working but my secondary display with the timer went dark. So I lost track of time and had to really rush through the last bit. I still went a few minutes over time. My hangover wasn’t an issue. Once I was standing up and moving around and talking it kind of went away.

You can see the slides here:

Deep Kanban – a biased and opinionated participant in the path towards synergy from Kurt Häusler

After that Jasper Sonnevelt and Sarah Reeder made us dance. I saw Arne Roock‘s nice looking presentation about creating a Kaizen culture. The last session I attended was probably my favorite. My “classmate” from my MSc program, Steve Tendon, presented a very informative presentation about the Theory of Constraints, with really great looking slides. Steve should really present at conferences more often!

On the last evening a few of us joined up with the local Theory of Constraints community and went out to dinner. We went to the Oudaen where we had the surprise menu, but it was also a very classy dinner with lots of little courses.

Over all I really enjoyed this conference. I am starting to get to know a few people now, and actually look forward to catching up with them as much as the actual content. 2012 was a fairly quiet year for conferences, but I will definitely have to look at not only attending but talking at more conferences in 2013. I already have one unconference on my plan. Play4Agile in February.

January 11, 2012

Book Review: Freedom from Command & Control

Filed under: Book Review, lean — Kurt Häusler @ 7:54 pm

I read this book by John Seddon several months ago so I hope I remember everything I wanted to say about it. The subtitle is “A better way to make the work work … the Toyota system for service organisations”.

Freedom from Command and Control Cover

It is important to know what he meant by Command & Control, as the term gets thrown around a bit, and there seems to be three main usages of the term.

  • The way I have always interpreted it and used it as a negative term for basically traditional management cultures that exhibit the best known aspect of Taylorism: Intelligent managers, remote from the work, do all the thinking, and decide not only what is to be done, but exactly how and dumb, replaceable workers that repeat the physical steps determined by the manager without question. In this case the managers are both issuing commands to the workers, and controlling how they do it. This seems to be how the term is used colloquially by most of the people that I hear use it, as a kind of umbrella term for all the dysfunction-exhibiting types of culture that are at the opposite end of the spectrum from what we are trying to achieve with more modern management ideas.
  • If you look the term up in Wikipedia, it refers to the usage of the term in the military. Here command and control are divested in separate roles. Staff of senior rank issue commands in the form of strategic objectives, while those of junior rank exhibit tactical control in order to achieve those objectives. This is more of a neutral usage of the term.
  • It is also apparently part of a theoretical model devised by Henri Fayol, which I recently read about on the kanbandev mailing list, but have not yet had a chance to learn much about.

Seddon writes in the prologue a paragraph ending in “these are the principles and practices that constitute command-and-control management”. He specifically mentions the following:

  • Top-down hierarchies
  • Separation of decision making and work
  • Managers making decisions with measures like budgets, standards, and targets.
  • Managers learn that their jobs are to manage people and budgets

He also mentions that “our organisational norms are based on command-and-control thinking” and “The separation of decision-making from work, the cornerstone of command-and-control thinking, has its roots in Taylorism…”. So we can assume that Seddon is using the commonly accepted, popular definition of command-and-control.

He compares it directly to systems-thinking, in a table similar to the one on this blog post (where he compares it to “Vanguard’s System Thinking”).

Seddon targets his wisdom mostly towards service organisations, such as local authorities maintaining public flats, that have to react to customer requests in a timely efficient manner. He is inspired by Deming, and the work of Taiichi Ohno who invented the Toyota production system, the root of lean thinking, so I am not surprised to find a close correlation between the ideas in this book and the ideas expressed by the lean software development and Kanban communities. (Although lately it seems many in the Kanban community wish to place it as being a viable option for control cultures, probably for marketing reasons.)

In fact as I was reading the book, I was helping my employer, a typical command and control type company, work with Kanban. As I was reading this book I was thinking, man, if only our managers read this before attempting Kanban, we wouldn’t be struggling so much. As it happens Kanban requires a culture of high collaboration between workers and managers (managers who might not see themselves as part of a software development process but rather a larger business process of which software development is only a small part, so they felt that Kanban was only of limited relevance to them), a sense of ownership of the process amongst workers (completely different to the fear that most non-managers exhibited when Kanban expected them to go idle, or engage in process improvement) and a flow-based rather than batch-based process.

Note I said Kanban requires those things in order to work. Some people believe Kanban can actually cause those things to magically appear, as if a command-and-control manager would suddenly change his mindset after looking at a CFD. It is my experience that a collaborative culture, and a worker owned process is not a result of Kanban, but a prerequisite. But I digress, as usual.

The book provides a gentle introduction to lean and systems thinking in short easy to read chapters full of concrete, real-world examples rather than appeals to academic models and theory. Although many of the examples refer to things like call centers, and plumbing service providers, it is not hard to see how the principles apply to other domains, such as software development. Particularly anyone who has worked with service-orientation or Kanban in the software sector will easily be able to relate to the material. I did notice a lot of overlap with Reinertsen’s Managing the Design Factory, which is not about providing services nor developing and maintaining software, but rather product development, which just goes to show that the basic principles are fairly universal.

I really love the emphasis on learning, learning to think, learning to learn, learning to lead, developing people.

I love that Seddon is not afraid to attack typical sacred cows like targets, certifications and tools. I feel like a lot of people out there involved in process improvement lack some of Seddon’s guts. They fear criticizing obvious dysfunction, claiming it might be disrespecting whoever introduced the dysfunction in the first place, or continues to work in a way that perpetuates the dysfunction. Some people claim that because people gain a sense of self-worth from being really good at working in a dysfunctional way, it is wrong to correct that way because someone loses their self worth. It is a fallacy of course, it assumes the dysfunctions are the “fault” of individuals rather than the system, and also assumes that people would rather not learn new things and perpetuate dysfunction than help improve the system. I can’t imagine Seddon tacitly endorsing dysfunction to spare someone’s ego, and I can’t imagine ever deciding to adopt that approach either.

Heck it seems disrespectful to me to allow someone to keep working in a dysfunctional way rather than help them improve the system.

Anyway it is dinner time so I better wrap this review up.

I loved it, it was one the best books I have ever read, because it felt like it was directly speaking to many of the issues I was facing while reading it, and it helped give me both the courage and practical tips to help fight the causes of the problems we were facing. I consider this book, or perhaps a book similar to it as essential reading for any manager thinking about attempting Kanban. If you aren’t prepared to help fight against command-and-control by following the advice in this book then you will find Kanban rather uncomfortable, and could save yourself and your employees a lot of stress by reconsidering.

I would also recommend it to anyone working outside of software, who hopes to reach the same levels of effectiveness that those in the software development world have been moving towards with the ideas from the lean and agile communities.

November 22, 2011

Three Conferences

Filed under: agile, conferences, kanban, lean, Software Craftsmanship — Tags: , , — Kurt Häusler @ 4:21 pm

Earlier this year I went to three conferences and I never got around to blogging about them as I was pretty busy with a lot of things like finding a new job, finding a new flat, preparing to move, preparing for a new baby, finishing my masters and organizing the code retreat.

SoCraTesWappen

The first of the three was SoCraTes 2011 from the 1st to the 3rd of September. The name comes from Software Craftsmanship and Testing, which is an interesting combination. I suspect a few people who would have otherwise been interested in the Software Craftsmanship aspects were turned off by the Testing part. SoCraTes was definitely about the union of those two topics rather than the intersection. It was English speaking too, and great to have some visitors from outside Germany. I even did a lightening talk, where I mentioned that I would be giving all my books away. That’s right, I brought a box full of books and let people help themselves to them.

SoCraTes had an interesting way of scheduling the sessions. Each session was either a big one split into a 30 minute introduction and a hour long in-depth section, while other sessions were just hour long sessions. I tended to move between them a lot. For example on the first day I attended the first 30 minute intro to the Craftsmen Coding Contest, then moved to the in-depth part of the Specification by Example session. Unfortunately I didn’t feel like the second part of specification by example, where they wanted to discuss examples, worked very well without being there for the first 30 minute introduction. I remember going outside to enjoy the great weather and joining another spontaneous, unplanned session happening out there.

After that I saw the first part of Soft Skill Essentials, then went to the Scala Test in-depth session. After lunch I went to the Crafting Object-Oriented Code session. This was one of my favorites. In partners we had to develop a small program according to provided requirements, but we also had to follow a rather extreme set of object oriented, clean code type rules. You might not want to be so strict all the time, but it is a great and fun exercise to help show how these clean code guidelines actually work, by doing them on in an extreme way, on a fairly small simple, easy to understand code base, you can really see what effects these rules lead to.

Later in the afternoon I went to another practical, hands-on session, SOLID for Dynamic and Functional Languages. We split into teams that chose a language associated with a non object-oriented paradigm. I ended up in the Clojure team, and I can’t remember what the other languages were. We were asked to look at code sections that broke a solid principle, and we had to refactor it so it obeyed the solid principle. The main idea was to discuss how aspects of dynamic and functional languages might make the solid principles either unimportant, different, or irrelevant.

The following day was Open Space. I think I attended sessions on “Laws of Software Development”, actually looking at a picture of the board, that is the only one I recognize. I do remember sessions on mentoring, developing SC communities in Germany and the others were mostly just general chats out in the sun.

The discussions on further steps to take regarding software craftsmanship in Germany were interesting. I didn’t think anyone needed to start a SC group up in the Cologne/Bonn area as we already have the Bonn Agile Meetup, and other user groups, that discuss the same topics. I was however inspired to bring the Global Day of Coderetreat to the Cologne/Bonn area though.

The date for the SoCraTes 2012 has already been set and it will take place from August the 2nd to the 4th, with an optional code retreat on the 5th!

ALE2011

The second of the three conferences was the Agile Lean Europe 2011 in Berlin from the 7th to the 9th of September. The whole family came to this one because there was a special spouses and children track with activities and trips organized. Now at this conference all the talks (except keynotes) were 30 minutes long, and they felt for the most part like dragged out lightening talks, or chopped down hour long talks. For me the open spaces were the highlight. I remember some great discussions on things like estimation, and whether we need managers or not. The keynotes were great too. Rachel Davies’ one on the first day was memorable for her comments on enterprise agile, which I seem to agree with. All the keynotes were fantastic. Beyond Budgeting for example is something I am really interested in getting to know more about.

The second day I had to give up a couple of sessions as I was informed I needed to do some last minute improvements to my masters. In the evening a small number of us went on a trip to catch up with the Berlin Lean Startup Group, for one of their meetings and some dinner.

I remember having a lot of thoughts about agile becoming too fluffy, and did a lightening talk about that, and there was some discussion on twitter about my views on coaching that I said I would flesh out in a blog post, but I can’t really remember what it was all about now. The last day was probably the best. I enjoyed all the talks on the Science of Kanban, Relearning Smalltalk, and the Agile Meme. On one of the days we also had a cool open space session “for programmers” with Brian Marick. You could consider it a warning sign if a session at an agile conference was notable for being “for programmers”.

Afterwards my family and I stayed in Berlin for a bit to have a look around.

The next one will be in Barcelona I believe.

Lean & Kanban 2011 Benelux

I enjoyed this one so much in 2010 I decided to go again this year. The whole family came again and we had a look around Antwerp. I won’t go through and comment on every session I attended. The highlights were probably David Anderson’s “When is Kanban not appropriate” talk, Don Reinertsen’s keynote, and the Real Options talk by Chris Matts and Olav Maassen. Would I go again next year? Sure, but there are 3 lean/Kanban conferences all happening around the same time, so maybe next year I could check out the LKCE or the LSSC ones instead.

Not many images on this post, so here is one of my daughter and I in Antwerp.:

IMG_7755

October 12, 2010

Lean & Kanban 2010 Europe – Day Two

Filed under: conferences, kanban, lean — Tags: — Kurt Häusler @ 7:56 am

 

Well I am now a whole conference behind in my blogging, so I will try and make this a lot shorter than the previous one.

Day Two started off with a keynote from David Anderson called “Creating a Limited WIP Society in your Organization”. Much of it was fairly familiar to anyone following the mailing list, and I assume to anyone who has read his latest book, which I unfortunately haven’t yet. For me there were quite a few nuggets of wisdom, and things I wasn’t aware of. Interesting was his observation that approaching lean from an angle of waste reduction is difficult as it tends to point the finger at traditional project management activities as being waste, which naturally leads to resistance from project managers. His preferred motivation for lean is encouraging an evolutionary approach to change and the emergence of lean software development behaviours, and to enable this by utilising a pull system that limits WIP, which will catalyze the other pillars of lean. He listed his seed conditions, of which most were already known to me. The interesting one for me was the use of models (such as variability, Deming’s system of profound knowledge, real options etc) to evaluate improvement opportunities. Having a toolkit of models is something I really have to look into, and something I intend to discuss on the mailing list, once I have read the book at least. It really underscores that Kanban, like Scrum, is not a software development or project management process, but a system, I guess is an acceptable word, for managing change, that relies on other ideas not pat of it. I really do see Kanban and Scrum as occupying the same place in the spectrum of ideas, with the fundamental difference being that Scrum (when done properly at least, even though the scrum guide considers the use of scrum as a fairly static tool for planning tasks within the development phase of a waterfall project as perfectly valid, I don’t even consider it scrum-but) requires radical revolutionary change, and Kanban allowing a slower more gradual change. I hope Kanban manages to avoid some of the same mistakes that the Scrum community have made, falling into the static task planning tool hole, and recent messages on the kanbandev mailing list have shown that this danger has been perceived to exist, and attempts are being made to reinforce the nature of what Kanban is, and avoid such misunderstandings. Another idea that was new to me, that I found interesting is the use of Process Control Charts. It seems like a great tool for discovering the natural, or common-cause, variability in a system, and being able distinguish it from special-cause variability. Probably the most important thing he said was that leadership is the magic ingredient. Seems obvious, but I am sure most of the time when these modern ideas like Scrum and Kanban are implemented, a consultant comes in and sets it up, at least to the extent at which people accept, and then developers focus on developing software, analysts concentrate on talking to the customers about requirements, managers revert to operating the system in a mechanical way but no-one takes a leadership role in the kaizen effort, and only a small fraction of the true potential for improvement is realized. Without a passionate change agent, who reads the books, and the mailing lists, and goes to the conferences, and actively builds up a collection of models for improvement who has some level of acceptance in the organization and some sort of authority, preferably of a “tribal” nature, but in most cases at least a minimum of official authority, then why bother? It is just going to seem like another buzzword, sold to the organization by a consultant, as a way to assist managers in commanding and controlling the workers. Anyway, I should make an effort to digress less. A good first step, according to Anderson is demand analysis, which is like what John Seddon said the previous day. Look at the types of work, their arrival rate, the expectations for delivery, the nature of the variability. After that you can begin to map and visualize the workflow. And of course, limit that WIP!

The second session I attended on day two was “A Kanban Multiverse” by Karl Scotland. It was all about better visualization, and more visual forms of communication, but he also covered some other interesting things. He started off by asking us to imagine how the battle of Britain would have gone if it were managed using a sharepoint site with a wiki and by mailing around change requests. He said visualizations can be used as augmented memory. To be honest though, and this is perhaps because I am not such a visual thinker, I felt a lot of what he showed us reminded me of Gantt charts. I just thought how wasteful is that, why not just all sit together, and talk, and use as little tooling as possible, perhaps a task board, a CFD and a process control chart. I see visualization as being a bit like documentation. Sure, do as much as required, but no more, after that you are being wasteful. But my mind could be changed on that. He talked about boundary objects, and how they represent something that is interpreted by different roles in different ways, that visualizations are one example of boundary objects, but so are acceptance tests, according to Brian Marick. Then he started talking a bit about Dan Pink’s ideas on motivation. He linked the Purpose aspect of motivation to visualization by saying that that is how teams can see where they fit into the value stream. He talked about chart junk, and mentioned a few other things that I made a note of to read more about such as Story Mapping, “Yes with Consequences” and the work of Tom Wujec.

The third session was “Seeing What Matters – Using the right vision to manage transition” by Alan Shalloway. It was a fairly densely packed talk, so I won’t give a point by point rundown here, particularly as it was a few days ago now. He talked about Pareto curves, and finding the right balance between new projects and improving old ones. He went into some nice detail on value stream mapping, and working out the process cycle efficiency etc, most of which wasn’t that new to me. He talked about not just getting better at what we do, but eliminating delays between the things we do. He said the Kanban board should replace the initial VSM as there is no point in maintaining two versions of the same thing. This was interesting, as I always see VSMs with things like “prioritise initial objectives”, “get funding” and “submit quote to client”, yet the Kanban boards I always see are more like “Selected”, “In Development” and “Testing”. I think Kanban (and Scrum for that matter, why not?) boards in general should visualize a much wider scope than they typically do now, particularly they should address the upstream business and customer related activities as being part of the process as the same level as the technical activities. He talked about the relationship between queues and delays, visualizing the feedback cycles, and he discussed some anti-patterns, like component, or layer, teams. He suggested looking at whether the team understands why they do what they do. Can they link the tasks they do back to the business objectives? Can the manager link the business goals to the tasks that the developers do? And lastly he talked about using silver cards to expedite, and making it a business decision, with consequences.

After that we had an “open space” track, it didn’t seem that well organized as an open space thing, or at least the participants didn’t seem to embrace the concept. Most people wanted to play the Get Kanban game, and the Dot Game. The Get Kanban game was fun. My job was to maintain the CFD and process control charts, unfortunately this meant I didn’t perceive what was going on in the actual Kanban bit itself as well as if I had another role like manager, tester or developer. But it was still a great experience to take part in. I didn’t play the Dot Game but I observed. The main point is in observing how a system based on single piece flow, pull, tight feedback, optimizing the whole and swarming is superior to one based on batching, pushing, and local optimization. They do this by building up a card with coloured stickers on it according to a pattern specified by a template. Particularly interesting is how, without being told, people naturally communicated when using the lean approach, but were too busy to communicate when using the traditional approach. And of course, the throughput and error rate were much better when using the lean approach.

The closing keynote, from David Joyce, was an excellent finish to the conference. He really brought it all together and related it to his practical experience at the BBC. He drew heavily on Systems Thinking, and the ideas of Ohno and Deming to present a view of lean different to what I was familiar with, as well as a summary of the ideas presented in other sessions. One new idea that I found interesting was that of Double Loop Learning. It is actually something that I had approached in my own thoughts myself when thinking of how principles and values can be used as a decision making rather than far off goals, so I will definitely be interested in looking further at that.

Anyway, that will do for now. In the meantime I have been to another conference, so I will try to blog about that in the next few days.

September 26, 2010

Lean & Kanban 2010 Europe – Day One

Filed under: kanban, lean — Tags: — Kurt Häusler @ 4:17 pm

 

On Thursday and Friday of this week, I had the pleasure of attending the Lean & Kanban 2010 Europe in Antwerp, Belgium.  A few days before it I found out my dissertation had to be related to, and ideally useful for my current place of work, so as I was attending the presentations and making notes, I was thinking about everything in that context, relating it back to my work, and planning how I could apply all that knowledge and wisdom to my presentation, especially the initial high level plan that I should be presenting the boss with over the next few days. I think I have come up with something ideal, but more on that later. As I mentioned I was taking notes while attending the presentations, but I decided rather than just copy down the slides, I would be better off writing down some of the many directions my mind was racing in. So often I heard something and then combined it with some other idea, and went off on some tangent and wrote that down, so apologies if this blog post ends up representing what I made of the content more than the content itself.

logo_small[1]

The first event was the opening keynote by Alan Shalloway titled “What is next in the Agile world: Why Lean / Kanban matters”. Someone who I have been following on twitter for a while now, and retweeting a lot, as well as being familiar with his ideas through various mailing lists that we are both on. In fact one of the most retweeted tweets inspired by his keynote was something like “Why you need management commitment in agile? Most impediments are located outside of your dev team”. He also mentioned that Agile hadn’t managed to solve the problem of team rule vs management micromanagement. I feel like the subtitle for my dissertation could be drawn directly from that idea, as at my work, agility and scrum really are just development specific local optimizations within a larger more traditionally managed process at the project and organizational level, and one of the first things you learn about lean is to “optimize the whole”, as local optimizations tend to reduce throughput, and compromise the system, yet still manage to appear good in metrics etc. He also mentioned that many problems tend to get blamed on development, as that is where they become apparent but are in fact caused by management.  He talked about the difference between productive work versus waste, and removing delays can be an effective way to remove a lot of waste. He mentioned that the nature of people means that teams working together is a hard problem to solve, as teams tend to take care of themselves before other teams. A fool’s errand he called it, and avoiding the problem should be more effective than trying to work around it via a scrum-of-scrums or similar. He talked about recognizing pipelines in the system, such as the business value pipeline, and looking at the distance between those who choose what to work on and those who actually do the work. He presented lean, or one aspect of lean at least, as a kind of science with rules, like gravity, that should be accepted and worked with, rather than denied. One of the most interesting points for me, as I am particularly interested in workplace culture, is that you can’t change culture directly, it is a consequence of the management system. It is no wonder that in our company we haven’t yet seen a strong agile culture emerge despite using scrum in the development department, as the management system is still decidedly un-agile! Shalloway mentioned the importance of making the management system explicit, and the role of management in teaching teams about lean science, and how doing so builds trust. The topic of lean learning and continuous process improvement was presented, emphasising improving all processes all the time, the necessity of visual controls and team involvement. It was also mentioned that learning is the result of dynamic interplay between theory and application, which I guess is the constructivist theory of learning, and something I feel I need to keep in mind, as it is easy for me to read the theory about something, but I know I don’t truly learn something until I get a chance to try it out in a real world situation. I really have to push at work for chances to allow my practical experience to catch up with what I have been exposed to through book learning. Lean science was described as one of the parts of Shalloway’s Lean Enterprise Model along with Lean Management and Lean Knowledge Stewardship. He reiterated that lean science consists of the rules of software development, business and management, and understanding that part of the model is a good place for smaller organizations to start. He then talked about the differences between Kanban and Scrum. (This is something that everyone seems to view differently depending on their bias though. See for example how Dave Anderson compares the two. Personally I think they are comparable. You can misuse either one as a simple planning and scheduling tool, and set it up to prevent organizational change and self-organization, as a local optimization in the development department, and adjust it to hide problems and make it a better fit for existing anti-patterns. Or you can use either as a change management tool to empower teams to make problems and anti-patterns more visible and help solve them wherever they are in the value stream. I guess it just turns out that Scrum is more visible to less engaged people so tends to get misapplied more often in a cargo-cult fashion than truly leveraged as it was intended, whereas Kanban has less of a presence amongst the cargo-cult method-buyers, and tends to get used by people who actually understand it.) Toyota Kata was recommended as a book, which I just discovered was already on my Amazon wishlist. He talked about the differences between Scaling Agility, and Agility at Scale. Whereas Scaling Agility is basically trying to get teams to work together, which doesn’t work, and Agility at Scale consists of focusing on the entire value stream, shortening the cycle time, and avoiding excess WIP at the product level. He then discussed another favourite topic of mine, the nature of software development as a profession. His opinion is that it is not yet a profession but he would like it to be.

There will definitely be a chapter in my dissertation titled “Lean Science”, so I shall be seeking more knowledge on that topic over the coming months.

The next session I attended was “The Road to Continuous Improvement” by Sandrine Olivencia. She presented a view of lean, strongly based on the Deming Cycle, featuring many ideas and concepts that I was unfamiliar with, which served as a good reminder that there are a lot of lean ideas out there other than the software specific takes on lean that I am aware of through the work of the Poppendiecks and systems such as Kanban. It appears there are many more paths to applying lean concepts from manufacturing to the software development world than I was aware of. She presented a client-focused approach to problem solving, emphasizing observation, low cost solutions, learning (the hardest and most important bit) and evaluation. She said, “don’t just mention change, write it down, train people, break the old mental model and build a new one”. She went through a case study of a team she worked with to improve production, customer satisfaction and quality. Her toolbox includes a 3-day kaizen workshop with a “voice of the client” exercise, where the teams perception of the client’s needs is compared with the client’s true needs, the waste hunt where examples of each of the seven type of waste according to the TPS are identified. She discussed the four types, or causes of variability: Men, Machine, Method and Material. She presented her Lean Method consisting of visualizing production to reveal problems, reacting immediately so problems don’t get out of control, resolving problems one by one and improving work and management practices. She described the “Obeya Room”, something I had not heard of before, and emphasized that her approach to lean focuses on developing people rather than merely implementing tools.  To conclude she mentioned that the hard part is finding the right problem quickly and resolving it with the true solution, and that senseis such as those that she learned from can do this quickly and set a high bar for her to live up to. Her final point, which underscores the one made by Shalloway in his keynote, was the importance of management involvement. My initial thoughts when attending this presentation were that it just seemed to be a do-it-yourself agile method, and seemed rather tool focused. I wondered where is the lean? But by the end I realised that there are many paths or approaches one can take towards lean software development, other than what I had been exposed to, and although she really did try and emphasize the importance of team learning rather than just the tools used to enable that learning, I guess the tools are easier to convey in a presentation because for me the main takeaway for me was a set of interesting tools that I would be interested in trying at work.

The third session for me was “The IT Portfolio as a Form of Waste” from Dave Nicolette, whose blog I have been reading for a while now. He mentioned right at the beginning that the talk related to companies that offer non-software products, and use IT in a supporting role, rather than software companies like the ones I tend to work for. I almost left and went to another presentation, but I thought it might be an interesting thought experiment to look at our software development department as if it were an IT department in a non-software company and see if it offered any insight. It wasn’t a perfect model, but definitely helped me get more out of the presentation and I was glad to attend it. A central theme was the separate planning between “the business” and “IT” that creates waste. This was perfectly familiar, as even in our software company there is a wasteful mismatch between the scrum-like approach to planning that we use in the software development department and the more phased approach to projects used in the rest of the organization. I can only imagine that this separation must be even more nonsensical in an actual software vendor than in the non-software organizations that Nicolette was talking about. He discussed how this structure creates examples of the muda, mura and muri. He mentioned the book Beyond Budgeting, which I also have in my wishlist, as a source of interesting ideas, and told us how estimation is a waste as it is not what the customer buys. He talked about incremental budgeting, which is an idea that has always intrigued me since we discussed it earlier in my uni course, and how it is based on value rather than costs. He said that what IT needs should come directly out of the business strategic plan, and he expressed his preferences for the term “business needs” rather than “requirements”, as well as his interest in real options, which is another concept that I have been curious about for a while, and will hopefully learn more when I attend a presentation about it at JAOO next month.

I really think some of the beyond budgeting / incremental funding / value-rather-than cost-based accounting ideas should also find a prominent role in my dissertation.

The fourth session I attended was “The Rise of the Lean Machine: Architecting the Lean Enterprise Transformation” by Claudio Perrone. Incidentally, the slides are currently one of the day’s top presentations on slideshare, he did all the pictures himself, that combined with his obvious natural talent for doing talks and storytelling, made it a particularly enjoyable session. He started off by talking about dream organizations, or at least how rare it is to find oneself in one, and mentioned rightshifting, a term I have been hearing about on twitter recently but have not yet really investigated in much depth. He told a story based on his experience where he presented the Toyota system, consisting of two main pillars. JIT, or Just In Time, and Jidoka, with a culture of continuous improvement in-between. These pillars, support three of the four “true north” metrics: Quality Improvement, Delivery/Lead Time/Flow Improvement, Cost/Productivity Improvement and Human Development. Actually go check out the presentation on slideshare, save me repeating it all here. One thing I paid particular attention to was his picture of a Kanban board shared by two teams. Up until now I had the idea that implementing Kanban at work would involve either combining all the (currently “scrum”) teams together, or giving each team a separate Kanban board, both of which have disadvantages. His Kanban board with swimlanes for each team would suit us well I think. Each team could have their own columns for selected, development, but all teams could share columns for things like analysis, validate and quality gate, which currently happen either outside the teams (in the case of analysis and validation), or across teams (in the case of quality gates). Another thing I found interesting was his use of the ArchiMate visual modelling language for doing value stream maps. I made a note that I must try it out, as I see a definite need for creating value stream maps in the near future. One slide that is worth reiterating here is his vision of a possible future:

  • Embrace lean concepts at the management level (the level that reports to the CEO)
  • Appoint value stream managers
  • Pull value at all levels
  • Align business and IT around value streams
  • Expect people to continuously improve their own process

The fifth session I attended was Ryan Shriver’s “Value Over Velocity – From Feature Building to Value Delivery”. This was material that I was already familiar with through my course, as we studied both the original Tom Gilb Evo approach as written about in Competitive Engineering, and we had an assignment based on Shriver’s paper, “Measurable Value with Agile”. His agenda consisted of three points. Identifying the Right Goals, Quantify for Clarity, and especially interesting for me, Integration with Scrum and Kanban. He presented his approach as being the next thing to attempt after learning effective agile delivery. Teams that haven’t yet made that work should concentrate on the basics first. His approach involves three transitions. Rather than focussing on the means, the focus shifts to the ends. Rather than planning by feature, planning occurs according to value, and instead of attempting to maximise velocity, we attempt to maximise value. (As an aside, I think this represents a misunderstanding of velocity, it is not something to be maximised, it is merely a planning tool that if anything reflects the ability of a team to estimate by its stability, rather than reflecting the ability of a team to deliver according to its magnitude, but there are people out there who view velocity as a kind of score to be maximised, so it is not that cut and dried). He reinforces the idea that the main idea of quantification is to ask the right kind of questions that lead to discovering exactly what we want, which is similar to the way Scrum planning meetings are more about learning about what needs to be done than the actual planning. For me there wasn’t much new in the first two points in the agenda, so I spent the time pondering the third point, how it could be integrated in Kanban as an explicit policy as one of the leftmost columns on a Kanban board, recognising it as a first class activity in the value stream, and a way of involving the people that do the work in helping choose what work is to be done. He didn’t really mention this though, so I asked at the end for clarification, and he said he sees it as something that occurs outside of the Kanban system itself. I am not so sure about that. I see a lot of value stream maps that include things like preparing quotes for the customer etc, but most of the Kanban boards I see seem to be restricted to the core development activities of analysis, design, implementation and test etc. I would hate to see the same mistake being made with Kanban that has been made with Scrum, reducing it to a local optimization in the development department, rather than using it to unify the entire value stream. For me Shriver’s approach of quantifying objectives, and using impact estimation to evaluate ideas absolutely belongs on the Kanban board, but I am open to being convinced otherwise. Apart from all that, the idea of rather than implementing the features our customers request, to ask them for their quantifiable objectives, and allow us to come up with the features would be pretty radical in our company I think, but not unrealistic, and something I would eventually like to look at. We aren’t there yet though.

The final session on the first day, the closing keynote by Professor John Seddon, titled “Re-thinking lean, re-thinking IT, re-thinking management” was my favourite session of the whole conference. No slides. He just stood there and talked, and talked extremely well, conveying considerable intelligence and wit, which made being there both a pleasure and a privilege. The main problem he addressed was that neither management nor IT people understand how work works. For me the main topic of interest was systems thinking in general, and specifically demand analysis. He presented a healthy mix of theory, practical tips, and real case studies. He said change doesn’t start with a plan, it starts with gathering knowledge. He talked about the differing natures of value demand and failure demand. He mentioned we shouldn’t set targets to reduce failure demand, because targets created it in the first place. As well as discovering more about the natures of both kinds of demand as they pertain to our organization, we should also attempt to understand the predictability of demand. He reinforced the comment that Shalloway made about management causing problems that are discovered in development by saying that problems are usually at the “front end”. (By now I am absolutely motivated to provoke the same sorts of changes at work at the management level, that we in the development department have attempted to undergo). One goal of this demand analysis is to match resources (I suppose he is not just talking about humans here) to demand, which means that there are always resources available, and that they may sometimes be idle, which ok, but non-intuitive for traditional Taylorist managers. He then talked about improving the design of the system, and pulling IT into the new design. He said that our tendency to attempt industrial solutions, and our obsession with costs are not appropriate for service organizations, and neither are sweating resources, splitting work into front and back offices (and no middle offices are not the solution), or standard times.

In systems design, the tradesmen make the decisions.

Some of the tidbits I picked up include: You cannot just take tools from e.g. Toyota, you have to focus on learning and improving rather than using tools. Cost is not an activity, it is in the flow, it is end to end in the service design. “People not doing it right” is not a cause of failure demand, the system usually is, and not just the process either, but the whole system. Expecting management to come up with solutions disenfranchises those who do the work. Standard work is only relevant if chosen and controlled by the worker.

Anyway, this blog post is far too long, over 3000 words already, so I will leave it there as a Day One coverage only, and post my thoughts on Day Two later in the week. The ideas for my dissertation are already starting to take shape. It will start off with demand analysis, and then go into some value stream mapping, and I will probably take it from there. It just wouldn’t be lean to build up an inventory of ideas now, and spend too much effort on a non-value activity like planning.

I noticed Dave Nicolette also blogged about the conference. You can check his post out here: Lean and Kanban Europe 2010 – Trip Report

The Shocking Blue Green Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 1,477 other followers

%d bloggers like this: