The Practicing Agilist

The agile community sometimes feels like what the medical community would be like if 95% of doctors were lecturers in medical school, and only 5% were actually practicing medicine, and that those who were actually practicing it were embarrassed by it, as if they were just briefly filling the role until the hospital reached enough maturity to get by without them, and then they could also “move up” to teaching at medical school.

Imagine that, if you had an industry where the career path was focused on being coached and trained in order to become a coach or trainer. Imagine if every expert in an industry were only interested in coaching or training others. Who would actually do the work? It would almost feel like a parallel to some multi-level marketing schemes / scams where building up a business of more salespeople was more important than actually selling the product itself.

People in the field are craving some real agile leadership, someone who can come in and do more than just convey some theory, roll out some standard workshops and trainings and then leave. They need someone who can really take the time to get involved and understand the business, to actually drive things forward, to actually deliver, to get their hands dirty, to make decisions and to take responsibility.

Coaches and trainers shy away from all this, “that’s not coaching”, they say. “You don’t help the coachee by doing his job”. They are right of course, so its obviously not for them, but someone still has to do it.

I am always bemused when a manager asks a question about some agile topic and gets berated by a Coach. “That’s not coaching” the coach says. “A coach would never do that, you need to get yourself some ICF certified Coaches Training!”, without even considering that the person asking the question has no aspirations at all to become a coach. Without even considering that there are any roles out there beyond Scrum Master that could be related to agile leadership.

When companies bought into scrum, they quite rightly expected the scrum masters to do these things, to replace their old-school managers by filling their shoes in an agile way. But they didn’t. “The coaches told us that Scrum Masters are like coaches” they said. “We can’t do all that stuff, that is either evil management, or the developers should do it. If we do it, the developers will never self-organize!”. The developers didn’t do it, because they were busy developing. So the organizations kept their “evil managers” to do all the work that the Scrum Masters didn’t want to do. All the finances, all the risk management, all the planning, all the strategy, all the process improvement, all the interventions, all the impediment resolution. And they wondered why agility hit a wall and never spread beyond the Scrum teams. Some of the Scrum Masters actually wanted to take things further, and grow and develop and help their organization become more agile, but the community told them the next step up was to become a coach or trainer, and coaches aren’t allowed to do anything hands-on, aren’t allowed to do anything except coach. So they put their expertise in processes and methods, technical practices, culture and mindset, continuous improvement, product and innovation or organizational design on the shelf, and became experts in coaching and training instead.

That didn’t help the organizations, who lost all their agile experts to the coaching and training business and also lost development capacity as developers, who after starting families, needed to move up to a scrum master’s salary. But they keep hiring coaches and trainers, because they are the most visible, they were all that was available, and they had been hearing a message like “managing=bad, coaching=good”. They are two different things. Coaches have an expertise in coaching, trainers have an expertise in training, neither are necessarily experts in agile management, in processes and methods, technical practices, culture and mindset, continuous improvement, product and innovation, systems thinking or organizational design.

Why do we see so much disdain expressed by Agile and Scrum coaches and trainers towards the topic of management or the role of agile managers, whether they be agile delivery, project or program managers. You hear them say things like “there are no managers in Scrum”, or “the existence of managers prevents the team from self-organizing”. I have really noticed this only comes from coaches and trainers, not people actually hands on involved in actually delivering things.

Actually it isn’t all bad. There are a lot of practicing agilists out there. As much as there is to criticize about SAFe, it is great to see they have defined a role such as Release Train Engineer. (The name of the role is pretty stupid though, they aren’t much involved in releases or engineering). You might find them called Agile Delivery Managers, or Agile Program Managers, or Agile Project Managers (Coaches and trainers, especially Scrum coaches and trainers hate that last one. “There are no Project Managers in Scrum” they say). Or they might even drop the Agile bit at the beginning and just call themselves Delivery or Program Managers etc. Or perhaps they call themselves Chapter or Guild Leaders. Or Senior Scrum Masters. Essentially they fill the role that most pre-agile managers do, except they manage the work and the system rather than manage people. What they don’t seem to do much of, compared to Coaches and Trainers, is post a lot on Twitter and LinkedIn. You see Coaches and Trainers work temporarily on projects or at different clients for a short amount of time, they need to be continually looking for the next customer so they need to invest a lot in promotion. Practicing Agilists have a more permanent home in the organization and are usually quite busy and have less need to promote themselves. This is perhaps one reason why organizations forget they exist, and strangely tend to hire Agile Coaches to fill permanent management roles.

None of this post is meant to disparage coaches or trainers, they are required, but sometimes I think people forget that for every coach or trainer, the industry should probably require about 10 or even 100 practicing agilists, and I don’t think this ratio matches what we might perceive by browsing LinkedIn or twitter.

What have I been doing

You will notice the blog has been quiet recently.

Since around 2014 I slowed down due to being too busy with the family. I was also doing work for large companies that was secret (sounds exciting but its just normal business these days) so I thought I couldn’t blog about it. The worked I was doing also seemed too basic and entry-level to be worth blogging about. But it only seemed that way because I was trapped in the Agile bubble. When you are an expert at something you tend not to realize how even the simplest things seem like black magic to most “outsiders”. Over time I spent a lot more time doing things that are definitely not the basics any more, so I have stuff to blog about again.

I did find time to write a series of blog articles while I was working at GFT:

• Empowered Scrum Roles
• You cannot separate Transformation from Delivery
• The various dimensions and levels of scaling agile and their implications

And I also experimented with writing an article on Medium. But I don’t like Medium as a reader, mostly because the mobile app doesn’t have ligatures and because the content is mostly poor quality, lots of self help fluff, virtue signalling / preaching, or self promotion.

• The Jars of Sand analogy for explaining Agile Estimation

Just recently I have started a vlog:

• Kurt Häusler’s Lean Agile News Vlog

I think I will focus on blogging here for now, at least every 2 weeks.

Transformations

The main thing people get wrong about transformations is that they try to make them too big, too ambitious, and too long. The most interesting transformation I worked on involved, or intended to involve:

• Transforming the mindsets of 2000 people divided into 20 tribes
• 100 coaches of about 4 different types
• A 3 year time plan
• A new delivery model based on SAFe
• Lean continuous improvement
• A new organizational structure based on the Spotify Model
• Objectives including increasing profitability, increased Net Promoter Score and automation and reducing dependence on the external workforce
• A complete migration from a mainframe based architecture towards containerized micro-services in the cloud
• A business transformation involving switching the company from a consumer facing brand to a supplier of B2B banking services to consumer facing startup brands

For a coach it was a lot of fun. It doesn’t make sense to talk about success or failure of transformations. Any transformation is likely to make some kind of positive impact, but might not achieve the expected RoI, and probably won’t reach all goals in the expected time span. It might even endanger the company if it is too ambitious. The company could get to the bottom of a J-curve it might never be able to climb out of.

You should probably only ever need 1 transformation

I am always bemused by companies that jumped on the Scrum bandwagon back in the good old days around 2008-2012. With a transformation of course. That should have been it. If every team had a Scrum Master providing services to the organization, and regular retrospectives, there should never be any need for any other transformation. That mechanism should have been enough to evolve whatever else might be needed over the next decades. If you needed e.g. Scaling, then the Scrum Masters would have organized themselves into Scrums of Scrums within the department, and identified representatives to coordinate with each other across departments all the way up to the board level. Whatever else is needed would be discussed and implemented as teams, and departments identified impediments, or experiments to improve the system, documented and shared them, and implemented them across the organization. It didn’t turn out that way because Scrum Masters (typically with a software developer background) shied away from providing such services to the organization, shied away from anything financial or involving talking or working with senior management, especially outside the programming or IT departments. They tended to retreat into their comfort zone of being a kind of junior team assistant, planning and moderating the Scrum events. It wasn’t always their fault. Many of them never saw a chance against the alpha personalities of the PMs-turned-POs and other tough-nosed management types in the organization who were happy to keep the SMs in their team-level boxes.

Keep it simple stupid

You should probably just pick one organizational level, one objective, and a relatively short time-box, say 3 to 6 months. Just like anything in agile or lean, we want to keep our batch sizes small, and our timeboxes short so things don’t get out of hand and any potential waste is limited. In order to prevent the need for any other potentially disruptive transformations you should focus on something that includes some kind of continuous improvement mechanism. The purest form would probably be some kind of “lean continuous improvement” transformation, avoiding introducing any new organizational structures, delivery models, or radical new mindsets. However some approaches such as introducing Scrum in the product development teams, or Kanban at the departmental level can help you kill two birds with one stone by improving delivery and introducing continuous improvement at the same time. Another nice approach is establishing departmental leadership teams that focus on improving the system at a strategic level (i.e. letting the teams deal with the small day-to-day operational issues) by conducting experiments or resolving departmental level impediments with something like A3 problem solving workshops or PopcornFlow.

Once you have introduced a continuous improvement mechanism (I use the word mechanism on purpose. Culture comes later), that mechanism should take care of anything else a transformation might be used for, whether it be to modify the organizational design, introduce a new delivery model, migrate to a new architecture, improve specific KPIs or evolve a new business focus.

Use the pull principle

To get the best bang for the buck, and find the best alignment of organizational objectives, employee needs, and overall approach it might be best not to be too pushy and decide up front what everyone needs. Set up a Lean Agile Competence Center of experienced managers and coaches, let them unpack their toolboxes in front of the organization and see who bites. There are bound to be departments who already have pressing needs and are hungry for assistance. This way you can keep a very tight alignment between what is actually being delivered and what is needed.

Don’t start by shoving some new, abstract culture down people’s throats

One common phrase I have come to despise is “it is not enough to do agile, you have to be agile”. Nonsense. What right do any of us have to decide who other people should be? Most people don’t give 2 shits about agile. Why should it become an important part of who they are? It should be perfectly sufficient for most people to merely operate the system as designed, to fulfill their role as described. Sure, managers like scrum masters or agile delivery managers should “become agile” to some degree, but most people should be able to work happily with the support of “agile” in the background and rather focus on “being” better technicians, bankers, product specialists, business analysts or even fathers, mothers, musicians, swimmers, or poets than orienting their lives around a 20 year old manifesto related to how software development teams should structure their work.

I am not saying we should pretend that culture & mindset is not part of the new agile organization, but we should not start there. The new culture and mindset can only emerge once people have a new system to operate. If this system is not in place, pointing the finger and demanding things like self-organization or servant leadership will only lead to frustration.

4 Stages of a transformation

Pre-Transformation

As hinted at above, before any kind of transformation you have to have the support you need. Experienced coaches and managers bringing their tools with.

The minimal transformation

The transformation itself should be limited to 3 to 6 months, and should focus on continuous improvement. This is not the time to introduce a whole new organizational design or enterprise level delivery model like SAFe. Start small. Introducing Kanban or PopcornFlow is a good choice here. Or regular Problem Solving Workshops using lean techniques like A3. Scrum is fine too provided the Scrum Masters are more senior than junior and don’t hide away in the teams and the pages of the Scrum Guide, and embrace their role of providing services to the organization, and connecting together to take over the operational and organizational needs of the enterprise.

After the transformation part 1 – improving the system

Once we have introduced the mechanism of continuous improvement, even if it is mostly just in the hands of the Scrum Masters or external experienced agile managers or coaches, we should stop talking about the transformation. From here we can rely on these mechanisms to give us whatever else we need. Whether it be new organizational structures, or other systemic improvements to increase alignment of delivery across multiple teams or departments. This should be seen as a normal, day-to-day part of life in the organization rather than an exceptional, disruptive aberration from the normal delivery of products and services. This is where we would see things like SAFe or the so-called spotify model appear.

After the transformation part 2 – the emergence of a new culture

If people are focused on learning a new continuous improvement mechanism, or using that mechanism to improve the way they do their work then that is quite enough. Eventually, as they get experience with operating this new system that they have helped developed they will realize that there are new ways to think about the culture of the organization, the new role of management, the new power they have has workers and increased effectiveness of shortening the distance to the customer and allowing a radical new mindset to develop. This can only happen as fast as, and follows, the introduction of the more mechanical systems first. It probably will only happen once the focus on improving the system slows down and people can allocate some mental capacity to thinking about things like culture and mindset.

This would also apply to a more typical overly-ambitious big-bang (or even Kotter) style transformation. In fact I would say the new culture & mindset can only begin to emerge once the transformation is over.

Miscellaneous tips

• Whatever style of transformation you choose (big and ambitious or small and focused on continuous improvement mechanisms) make sure someone at the board of directors (or at least the main leader at whatever organizational entity is transforming) sees it as his pet project.
• Train people in bulk. Use training as a chance for people across the organization to meet each other and share experience and thoughts. Let experienced coaches focus on coaching Scrum Masters and other managers and allow those managers to coach and train the teams. It is also quicker and cheaper this way.
• Communicate everything transparently and continuously, inviting feedback every step of the way. Remember we aren’t transforming people here, we are allowing people to transform their system.
• Make sure any introduced models are fit for purpose. SAFe has a purpose (increasing alignment between teams in departments developing products together) but it is not an organizational design framework nor is it suitable for service delivery and it is not that strong in continuous improvement either. Make sure you understand what you want to achieve and pick the right thing for the job.
• Don’t pick a cool department and focus on transforming it as a kind of pilot project. That send the message that everyone else is unimportant. Instead set up a pool of coaches and agile managers and allow those to pull from it who have the most need.

Motivation

So everyone knows that for knowledge work, money and other extrinsic motivators don’t work right? And people are instead motivated by intrinsic motivators like autonomy, mastery and purpose.

Well that is what a lot of you think but it is actually missing much of the story. When people like Dan Pink talk about it, they actually mention something intuitive at the beginning that listeners forget because the focus is on the interesting non-intuitive bit. Before the intrinsic factors actually have a motivational effect people have to be paid enough to “keep the issue of money off the table”. No one tries to hide this, but I don’t know if people focus on it enough. I guess most motivational theorists and speakers must come from countries like the USA where a significant number of knowledge workers are earning over this thresh-hold. I am not sure if it is so relevant elsewhere. I decided to look at average salaries for different types of knowledge worker to see if I could notice any patterns.

Lets have a look at some numbers from glassdoor.com. I was always redirected to the German version based on my location and couldn’t switch to the English version without signing up and filling in all details. I also converted to Euro based on current rates. These are the average salaries for each job in each country:

Job	Germany	USA	Switzerland
Software Developer	€49,845	€80,245	€101,386
Scrum Master	€30-70k	€55-90k	€112-136k
Project Manager	€60,540	€86,308	€111,945

A couple of other things to keep in mind:

• Taxes in Germany are higher than they are in the USA and Switzerland.
• I guess for Scrum Master in each country they did not have enough entries to provide a straight up average, but they did provide a sample of entries. Here I tried to represent the range without the outliers.
• Costs may not be comparable between countries. I know Switzerland has higher living costs, but I don’t think overall they are twice as much. I think Germany and the USA might be more comparable.

Looking at these numbers I would make the bold claim that in Germany we don’t need to worry about intrinsic motivation too much. Only the very top end are going to be earning over the thresh-hold where intrinsic motivation plays much of a role at all. I would say in Germany, we need to concentrate on paying people more. In Switzerland it would seem to be the other way around. Here we can really see the power of intrinsic motivation. In the USA it could go either way, I would say most are indeed earning over the thresh-hold, but many not.

Now, I know the software development managers in Germany are saying “Impossible. We cannot pay our guys any more. The customer would not accept our offers. We would have to let people go”. Sure, I am very familiar with the software development market in Germany and where the money goes. I would say in most cases we have to live with developers who are demotivated and are constantly looking for a better paying job. There are a couple of things we should also be looking at in most cases:

• Doing the wrong projects and optimizing for employee utilization. Knowledge work based projects should offer significant rather than scant returns. German managers will go to great lengths to make a sale and keep their employees busy for the tiniest of margins. They have a real phobia about saying no to low value endeavors especially when employees are sitting there without a project. What happens is they make that sale, because doing something is better than doing nothing, and when a high value opportunity comes along, everyone is too busy to take it up.
• We also have a phobia about killing low value projects early. For some reason we don’t like quitting. We want to slog on through and get it done regardless. Most things are fine to start but they aren’t meant to succeed. The focus should be on proving early that something is a loser, and killing it. Freeing up people for better things.
• We spend too much on non-value-adding management and organisational effort. Typically when introducing lean or agile methods we add new roles in addition to existing power structures. This is a big cause of waste in organizations. By replacing rather than supplementing management roles with agile roles we can free up a lot of money to reallocate to value-adding knowledge workers resulting in increased motivation and better financial results.

Anyway, to summarise, the almost blind belief in intrinsic motivation might be appropriate for some countries, but in many countries we have to listen a bit more closely to the bit the theorists and speakers don’t spend so much time on: You have to pay enough to keep the issue of money off the table. In Germany, we do not do that, so intrinsic motivation is of limited utility.

Learning the Mainframe

In my job as IT consultant for the banking industry I sometimes have to do some work on an IBM Mainframe, which means the z/OS operating system, formerly known as OS/360, MVS, and OS/390. Yes there are other companies selling mainframes but most of them are “IBM compatible” and there are other mainframe operating systems including Linux but z/OS is the main one.

But how are you supposed to learn how it works? Most people don’t have access to one at work, and even if you do you probably shouldn’t use a client’s expensive mainframe time to play around.

The way I learned was to first pick up some theory from this excellent book, freely available in a variety of formats: Introduction to the New Mainframe: z/OS Basics

Just from skimming through the interesting chapters you can turn up to work and not be completely lost when performing your mainframe tasks.

So with a book, and limited access to a real machine you can get started. But what if you don’t have access to a mainframe? Can you download and install z/OS on a VM? Sort of. There is an emulator available called Hercules. But it isn’t that easy to get going. You still have to hunt down the operating system on your own in most cases, and install it yourself which is a bit much for a beginner. The latest freely available operating system version is I believe a version of MVS from the 70s. Don’t worry it is not actually that different to the latest version. The best way to run it at home as a beginner with minimum hassle is to find The MVS Turnkey System. I did this and was able to play around a bit with the help of the previously mentioned book but it is not the best way.

IBM has a contest for students called Master the Mainframe. They give you access to an internal z13 and provide you a tutorial. Students get their work marked and can maybe win a prize or something. If you are not a student however you can still take part, but your work will not get marked and there will not be any prizes.

If you register here anyone can get an account on the mainframe and complete the tutorial style challenges. It takes a couple of days though. When registered you can find the tutorial challenges here: http://mtm2016.mybluemix.net/index.html

Click on Connectivity Guide to get started on the first steps.

I was able to get about halfway through Part Two in one weekend, to give you an idea of how much work is involved. It does get more challenging though so I expect Part Three to take a bit longer.

Once you do it, you can rightfully claim z/OS experience on your C.V. which might increase your worth if you are already involved in IT, consulting or banking. There is a shortage of talent as the older guys retire so there should be good opportunities for people with basic skills to move in and replace them. Even if you don’t want to specialize in the mainframe you will be surprised how often basic skills are required on banking projects even in management roles.

Here are some additional points related to the mainframe:

• Some people say you can’t do Agile on the mainframe. This is completely false. There are no technical issues to doing Agile on the mainframe. You can unit test COBOL. You can refactor it. You can run automated tests. You can do DevOps and deploy several times per day. The barriers to Agile are usually cultural and bureaucratic rather than technical.
• Mainframe teams don’t need Agile for the same reasons. Getting new products on the market quickly is less of a priority. However Agile is critical to manage other risks: Old legacy code with technical debt and knowledge gaps as people leave without training replacements properly.
• The mainframe guys were using NoSQL not just before NoSQL was invented but before SQL was invented. In fact trendy modern ideas like event sourcing look a lot like how mainframes have been storing transactions in systems of record in “NoSQL” DBs like IMS since the 70s.
• The mainframe is and always will be great for batch operations and transaction processing and anything requiring very high levels of reliability. IBM seem to be moving away from z/OS and towards Linux for the new economy, supporting mobile applications and hosting web services etc. They also have a vision of replacing the scaled-out data center approach of lots of cheap x86 servers running VMs, with single mainframes running thousands of Linux VMs. I don’t know about this. I think you end up paying for levels of reliability that are not required. For me the future of the mainframe will always be a niche oriented around z/OS and not an ideal way to host e.g. Java web services on Linux VMs.
• After you finish reading the previously mentioned book. There are whole series of books covering mainframe topics in depth: ABCs of IBM z/OS System Programming. Here is a link to Volume 1.

Sensitive Data Privacy Protection in the German Medical Industry

 

A few years ago I was involved in developing an image database for the medical industry. It was mostly used by skin doctors. I remember having to test and analyze errors in the software by debugging and clicking through real databases sent in by our customers. I was exposed to both images, and highly sensitive medical information as well as identifying information such as names and addresses of patients. Some of these images included naked full body images (used for tracking new moles over time) of both adults and children as well as close-ups including genitalia, usually with medical ailments such as sexually transmitted diseases. Once again, not just of adults. I remember discussing whether there was some way to improve the software so that we could protect people’s privacy (I did not know much about the privacy laws at the time, but was certain that doctors should have insisted on NOT sending us such databases) but this was not prioritized at the time. Some of these databases came from the town I lived in, and the summary list contained surnames I recognized so I decided not to analyze this database. The experience made me concerned about my own privacy in connection with the medical industry. Thankfully I don’t have any interesting items in my medical history, but it is disturbing to know that if I did, the industry would not take my rights or the law as seriously as they should. This was one of, but not the major, reason why I decided to leave this company.

The last time I went to my current doctor for a regular checkup I sat in and waited for him.The screen on his desktop was only slightly angled towards his side, so I was once again confronted with sensitive information that I knew was legally protected.

Today I came back from getting a vaccination. I was asked to sit in the lab for about 5 minutes and wait. Once again was the same screen I saw at my previous visit. The top panel contained the name, address and medical insurance information of a patient, and the bottom panel contained the current relevant medical details about the patient including existing conditions, medications, reasons for visits, and personal observations. Once again, I felt bad for the patient, but also bad that someone else might get to see my (fortunately boring) medical history.

The EUs Data Protection Directive allows businesses to collect this information, but obliges them to prevent such data from being exposed to unauthorized third parties without consent.

I mentioned this to both employees, and got disturbingly dismissive answers such as “yeah unfortunately we just do not have the room”, to my comment “you know this is illegal right”. I mentioned to the other employee that it would probably be ok to lock the screen or switch it off every time you leave the room, but she didn’t know if that was possible and blamed it on patients that make an appointment but never turn up.

I am not a lawyer but as far as I know medical data is especially protected. I don’t know if this means jail time for the doctors, nurses and receptionists involved, or just a financial slap on the hand, but I would be interested in knowing.

This is not a name and shame post, as the problem is certainly widespread, but I think the medical industry should definitely consider this a shame post. From what I know in the financial services industry, they take such matters much more seriously. This is probably because banks etc have a very long relationship with the IT industry, who seem to be taking the lead in helping customers implement privacy control, but the medical industry seems to have always felt less comfortable with IT in general and possibly hasn’t been exposed to such ideas as much.

Part of me however thinks I probably should report this. I don’t know. If this is a jailable offence it is probably just as bad to ignore it as any murder or rape. If it is merely a fineable offence, then I would rather stay out of any direct involvement.

The lesson for me is probably just be very careful about how willing I should be to let my doctor be involved any sensitive medical issues, without specific provable assurances that my privacy will be protected. If that makes it sound like I don’t trust them, then that is because I unfortunately cannot. I don’t think you should either, not at the moment at least.

Frankfurter Entwicklertag 2014

On the 19th of February I attended the Frankfurter Entwicklertag (Frankfurt Developer Day). It is not the sort of event I have been recently attending as my interests are slowly moving away from software development, and more towards management of the wider value stream. I entered a draw at the christmas meeting of the Agile Rhein-Main user group and was lucky enough to win a free ticket thanks to Andrena Objects.

It was a very well organised and promoted event. I liked the strategy of engaging with the community and giving away free tickets. They managed to sell all the tickets I believe. 

I deliberately tried to stay away from “agile” related topics, as I think I have been well exposed to those sorts of things and I wanted to leave my (current) comfort zone and take the opportunity to hear some technical topics that I have been focussing on less lately (which is my old comfort zone). My favourite talk was the one about Event Sourcing, as actually practiced by Vaamo Finanz. This was great as event sourcing together with CQRS was all the hype in the DDD community around 2009/2010. I could see the potential in the idea, and played around with it myself, but unfortunately didn’t get to experience it for real in my work. I remember talking about it, and even leading open space sessions on the topic at various conferences, where we focussed a lot on the theory but people were hungering for actual practical experience reports. Then it seems like either the topic died down a bit, or perhaps my interest drifted away a bit. Then all of a sudden 4 years later I see an actual experience report, and all the potential issues we were discussing in theory back then were reported as actual findings, and it was great to hear about how Vaamo actually dealt with the issues. It felt weird that something should at the same time be leading edge, yet still feel like a nostalgic trip down memory lane. The talk was superb. Full of interesting technical content, and very well presented. It was engaging, relatable, and entertaining.

Overall, I don’t think I would have paid the asking price for the ticket. I would have preferred to see it as a community event with more costs covered by sponsorship with perhaps a maximum ticket price around the €30 mark. Specifically because it was so wide and general. I think it is a good conference to send developers to to get up to speed on a fairly random selection of interesting topics, and they can deep dive into anything potentially interesting at a more specialist conference after. If I was a developer, i would have probably already had an idea about what specific technologies would be relevant to solving my specific problems and I would have attended a more specialised conference where I can go into more detail on one thing, rather than get a fairly superficial overview of a bunch of random topics, many of which are not likely to be relevant for me at any given time.

I didn’t see a huge connection with the stated list of focus areas: Agility, Quality and Innovation, but that doesn’t matter too much I guess.

Another concern was the level of female participation. There were female attendees, but worryingly few. Only one female was involved as a presenter, and there were no women in the program committee. This may not yet be as much of a concern in the German speaking countries as much as it is in the English speaking ones (where conferences have had to be canceled after a backlash against all-male program committees for example!), but I think it is something even in Germany we need to be much more concerned about.

A big thanks to Andrena for organising, and of course for my free ticket!

#NoEstimates Interview with Fabian Schiller

#NoEstimates – an Interview

I met up with Fabian Schiller (Twitter, Blog) recently at the Agile Rhein-Main User Group in Wiesbaden, we started having a brief chat about #NoEstimates, and decided to continue our discussion via email so it could be blogged later. All numbers are fake yet realistic. Fabian also blogged the interview on his blog.

Fabian:  “Hi Kurt, you tell me that it is a good thing to stop estimating? I’m sorry, but I cannot imagine how that could work out. How will I be able to calculate the costs for an upcoming project? As a business person, I must – at least – have a rough estimate, how expensive my project will be to know if it will pay off. How can you do this without estimation?”

Kurt: “Yes I think in general it is a good thing to stop estimating, there will always be situations where it makes sense, and of course it also depends on what we mean by estimating. For calculating costs estimation is especially bad. In fact the agile community had never even discussed estimation for this purpose. Estimation was generally safe as a tool for teams to use in planning how much work to take on each iteration and for providing rough forecasts about which features might be available in which release. For calculating costs there are a variety of approaches. Asking a team to sit down and guess how many developer hours each feature will require to type in and adding this up and multiplying these hours by various hourly rates is the poorest approach I have seen whether we are preparing an estimate for a T&M project or determining an actual price for a fixed price project.

My first comment would be that pricing an entire project at once is un-agile. It is at best hybrid, but that might be ok. Exactly how I would price the project depends on a lot of factors. How well does the customer understand about what he wants? Has the team done something similar before? Does the customer have a budget? How flexible is the customer and is he open to working in new ways or does he have certain constraints?

One simple approach (that might work in some cases but not others) would be to identify the most important feature than can be developed in one sprint. We know our team costs for a sprint so we can base the price for this “Version 0.1” or “Minimal Viable Product” on our costs. Then the customers question might be “how do I know in advance how many sprints I will need?” Then it gets interesting. I would perhaps then ask him something like “what are the minimal features we need to go live and start earning money?”. Perhaps something like the Incremental Funding Method could be an option.”

Fabian: “OK. That explains a lot. I see many valuable approaches in what you say. The idea of delivering MVPs and approaching a project in small steps is nice. But as a customer I do not want to risk building one increment after another to determine that my money will not suffice to get the minimal marketable product ready when the money is already spent. So, I essentially want to know if there is a realistic chance to get my product built within my budget. How might that work with an MVP approach? Or am I and my project just not eligible for working agile? Is that what you are saying?”

Kurt: “The assumption I made, was that there was at least enough money available for a minimal viable product (One thing we like to offer customer’s is a special price for an MVP that can be completed in 1 sprint), and some extra available for further work in case it is not ready to go live (if the software development is only part of the product for example, we probably can’t go live until the rest of the product is ready anyway). It sounds like you already have a fairly detailed understanding about exactly what it is you want as well as a budget. In other words, fixed scope, with a fixed upper bound on budget. This is probably the easiest case. Without needing to get too detailed, we can compare our delivery rate of features with our pricing and see whether the budget easily covers it or not. We can probably do this with an MVP approach but it sounds like the difficult part is already done. You already know exactly what you want. (MVPs are usually used when the customer doesn’t know exactly what he wants, and wants to first test the market with an MVP and use the feedback to drive the vision of the product) In this case we can simply build it, one feature after another, and provide regular feedback about how much of the budget we will be using. This is a fairly typical approach, and definitely qualifies as agile software development. Radical people like me would consider it a hybrid situation, as the financial decisions and requirements gathering has already taken place for the whole project, and only the development itself will be carried out iteratively. So the whole “project” doesn’t sound agile, but the software development phase can certainly be carried out according to agile software development.”

Fabian: “OK, I think I got that. You would just take all my stories, divide them by your average

sprint capacity and then – since you have a fixed size team – know how the costs would be. Correct?

But how do you know, that the stories, I will deliver are about the same size as the stories, you worked on in the past? If you simply take the number of stories, size should matter. Doesn’t it?”

Kurt: “That is roughly right, yes. However I won’t pretend to be able to “know the costs”. The first step is to see if we are anywhere in the same ballpark. I would take your stories, and split them, which is a fairly mechanical process looking for certain keywords, steps in a workflow, or variations etc, and count those. The numbers I base my costs on are actually based on a larger group of 20 people that is usually split into 2-4 teams and works on 2-4 different things at once. So not quite sprint capacity, but close. I know over the last 12 months this group has cost roughly 130,000 Euro per month on average, and has delivered over the last 12 months roughly 180 items per month. So that means my costs are roughly 730 per item. We only need a small margin say 5% as everything else, like rent, hardware, training, maternity leave etc is already included in the 130,000 costs. That brings it up to about 760, which I would round up to 800 to provide a nice round number and cover the risk on my size if I have to commit to a price up front, say if you will only accept a fixed price offer. Oh and you don’t really need a fixed size team, you just need to know how much the typical team changes over a year affect costs. It is definitly better to have a fairly stable team though.

So we can take that 800 and multiply it by the number of stories, you have and compare it to your budget. I would recommend proceeding only if the price is significantly lower than the budget. If it is more, or comes close then the project might not be such a business success. Even if the expected price is slightly lower than the budget, I would still suggest looking for a better project, knowledge work should result in significant rather than scant returns.”

I fully expect that in any backlog the stories will vary in size. This size is not as important as many people think, once you consider the whole value stream, rather just just the development itself. I expect that the distribution of the true lead times of items I attempt in the next 12 months, and my throughput will be similar to the distribution of sizes of items I delivered and my throughput over the last 12 months. Plus every new project gives me new statistics that I can use to base the next months prices on (and one month of year old statistics drops out of the moving average). If your project turns out to result in longer lead times or a drop in throughput (whether that has anything to do with item size or some other factor), then my cost per item will go up slightly, and I will raise the prices for the next project. Possibly however another customer’s project has factors (maybe item size, maybe something else) that result in shorter lead times and an increase in throughput and they will cancel each other out.”

Fabian: “OK, I see, there is a lot more thoughts in #NoEstimates than just denying to estimate 😉

Your explanations sound reasonable. But they open up two further questions for me:

1.) If your first step is to break down stories at the beginning of a project to relatively small ones – will you not be very detailed before starting to implement? This sounds kind of like a classical project specification for me…

2.) Using your mechanics, you would implicitly reward customers, that formulate larger and larger stories over time which sounds not good for neither your understanding of the project nor the next customer, who will have to pay that bill? After all, the distribution of story sizes is not a random variable, but highly determined by your customer!”

Kurt: “With regards to question 1, my preferred approach is in fact NOT to break down all stories in a project to relatively small ones. My preferred approach is to simply pick the single most important feature, break that down if necessary, deliver it, and repeat. Even if we might know what the next most valuable features are I would ignore them for now and concentrate on the single most valuable feature. This is not too radical for agile software development or lean startup. This particular case is a bit different for these reasons: you already know exactly what you want, and have already completed the initial phases of the project in a waterfall manner, at least the requirements gathering seems to be complete. The other reason why we do this initial quick splitting is because you wanted a forecast upfront about how the expected costs of the whole project might compare with your budget. This is definitely a hybrid project but that is ok, most are.

You are right that a customer who is paying per feature might try and make them bigger to get more for his money, that is why we always split before committing together to beginning development of an item. But it could still be the case, that even after splitting one customer’s project’s items turn out to have shorter lead times or less impact on system throughput than another customer’s items. This doesn’t necessarily mean one customer is being rewarded over another. It means that customers are paying for the value they get rather than the effort we put in. Why should a customer pay more for a feature just because we have to do a bit more research than usual? Such extra investments don’t just benefit him but help the team in general, so this method spreads the costs. Why should a customer pay more for a feature just because an employee has gone on maternity leave and we had to hire another. Costs will go up, throughput will go down. This will change our cost per item, but no specific customer should be rewarded or penalised for this.”

Fabian: “I think, I understand: Either I know exactly what I want to have (and am willing to invest heavily in analysis), then you would just break down stories to relatively small ones. Otherwise, you would suggest to proceed incrementally via MVPs (where you break down stories for the next increment only).

The activities in both cases seem relatively similar to what I would do when I would estimate a project (or a part of a project):

* Specify what will be delivered with the next milestone

* Break it down (to a certain degree), to see what has to be done

* Assign every item some specific effort

You just leave out the last item, which is putting a number on it, ain’t you?

The amount of work for assigning efforts seems relatively low for me, if you already broke down the work. This brings me to my next question: What are the concrete advantages of not estimating? What problems are solved by not estimating?”

Kurt: “The first bit is roughly right, although I don’t think anyone should ever need to invest heavily in analysis. If you know what you want in advance then the analysis has been done. If you don’t then we can start to think in a lean startup way, and conduct experiments to test our market assumptions and generate new knowledge. I guess initial story splitting is a kind of analysis, but it is more like a simple mechanical process, looking for keywords etc.

And of course as usual, both extremes are rare, more typical is something in the middle, where the customer knows something about what he wants, but not all the details.

I like your list of three points. I would leave out the third point, but I would replace it with something like “assign a risk category”, or “assign a class of service” or “calculate the cost of delay”. Actually these things don’t need to be, and shouldn’t be, done all at once in the beginning. That is waterfall, or hybrid not agile. I think it is better to do such things as late as possible, just before the actual development.

You are right that the problem with estimates is not just that it takes time. It is unprofessional. It is like fortune-telling. It is simply guessing, and in several decades of software development we have learned that it doesn’t work. The numbers that is produces cannot be reliably used for anything, except perhaps sprint and release planning. Now we are starting to understand why it doesn’t work. You cannot reliably predict the effort involved in completing work in the complex or chaotic domain. Even if you could predict it, this number will not have any meaningful relationship to anything important. Now the agile community has talked a bit about estimating, and done a reasonable job with it so that it is useful in certain circumstances, done in a certain way. Using relative units like story points has helped scrum teams perform sprint and release planning, particularly when the variability of PBIs is not well understood. It is important that everyone understands the limitation of this approach. That these estimates are not to be understood by a customer to be a promise, they are not applicable when considering the wider value stream, they should not be used to base prices on etc.

No one in the agile community ever said that effort estimates are the correct approach to use for calculating costs in an offer or invoice. No one ever said that effort estimates be used to determine project delivery dates. Doing this has resulted in losing huge amounts of trust and money (either the customer’s or supplier’s).

So there are several problems solved by not estimating: Project failure in general, mistrust and disappointed customers, teams that feel disappointed when the actual lead time and delivery rate doesn’t match their guesses, and huge loss of money.

Imagine these slight exaggerated scenarios. Imagine a Scrum team developing software according to a backlog, and they need to know what they might achieve in a week. In this case the units of work (PBIs) are relatively large and few in number compared to the container (the sprint). It is like packing large stones in a small jar. If the stones have a variety of sizes then guessing at their rough relative sizes can help determine if we can pack in 5, 10, 15 or 20 stones in the jar. This is all the agile community has ever used estimation for, and in this specific context, it solves a specific problem.

If we consider the whole value stream, not just the development, and look at the departmental or business unit level, or even if we consider whole projects rather than individual sprints, then we aren’t packing large stones into small jars. The size of the units of work is relatively smaller compared to the container. It is more like filling larger jars with grains of sand. Not only filling the jars, but collecting them from the beach, cleaning the jars, filling them, packing them into a box and taking them to a post office. In this scenario would you bother trying to estimate the size of each grain of sand? No. You would use concrete measurements of how many boxes could be delivered to the post office over the last lear, and use that information to base future business decisions on.”

Fabian: “Thanks Kurt! I think we covered many topics. And cleared up several misunderstandings about #NoEstimates. I really appreciated this dialog as I learned a lot!”

Conference Catchup

So normally I try and write up a bit about the conferences I attend, but I have been a bit slack lately. Since my last post about the play4agile event and the agile coach camp, I have attended 4 interesting events that I would like to share about. I am going to keep it short, partially deliberately, and also because the first two events took place a while ago, and the other two I forgot to take notes for.

In June the exclusive, invitation-only, Kanban Leadership Retreat in Mayrhofen, Austria took place.  This was my first one, and it was amazing to catch up with the world’s leaders in developing and applying the Kanban Method. One of the first sessions was also one of the best. Sigi Kaltenecker and Klaus Leopold talked about their still-in-development ideas about looking not just at Kanban practices but at change and leadership practices in the organisation. For me it was essential to see a list of concrete practices under this topic because concepts like Change or Leadership can tend to be a bit abstract. 

It was also interesting to hear from Dimitar Bakardzhiev about what has been happening in the Theory of Constraints community. He mentioned that they seem to be a lot less scared to talk about money than e.g. the Kanban (and Agile) community. I definitely think we should talk about the financial aspects of knowledge work and product development a lot more.

I saw a case study presentation from Nina Schwab at Tupalo in Austria. They had an innovative approach with a horizontal lane at the bottom for cards to leave the system and travel right to left and reenter the system, which to me could be used to implement the feedback loop required in The Kanban Method. Things learnt could be placed in this lane and flow back into the input queue.

I missed Troy’s session, which might have been a mistake as I heard it was really good.

Some miscellaneous points I noted down include things like:

• Change should not be a separate initiative, it should be part of the actual day to day work.
• We can start with the practices, and then move on to more abstract things like values and goals.
• If were to pay enough direct attention to change and leadership practices Kanban itself may become almost of secondary importance.
• Kanban is for building learning organisations.
• The principles and practices are “kickoff” focussed, and less relevant for running systems.
• I still need to look more into the Toyota and/or Improvement Katas.

I would like to thank my former employer ETECTURE GmbH for funding my participation at the Kanban Leadership Retreat.

 

In August I attended and even spoke at the Agile Lean Europe Unconference in Bucharest. I actually combined it with a family holiday, as the ALE unconferences have an awesome family and spouse program. I attended the one in Berlin in 2011, but missed the one in Barcelona in 2012. It was great to catch up with the agile lean community again.

I won’t go into too much detail about the sessions I attended as everything is available online. Videos and slides. The highlights for me were the keynotes from Jurgen Appelo  and Joe Justice from Wikispeed, and Vasco Duarte’s #NoEstimates session.

I chose not to take part in the evening social activities as I was enjoying exploring Bucharest with my family. 

I think my talk about Offers and Pricing went well, and inspired quite a bit of subsequent discussion. You can see the slides here:

Offers & Pricing from Kurt Häusler

 

My family and I actually stayed in Romania an extra week where we went to the beach on the Black Sea for a relaxing holiday.

Although I funded my own participation, I think it is important to thank the sponsors for their support.

 

The third conference I need to mention is the Lean Kanban Central Europe that took place in Hamburg in 2013.

This was a really well organised (by it-agile) event. Location, food, wi-fi, extra activities were all first rate. It was interesting to see so many people outside the core Kanban community in Germany interested in attending. In previous years I had been to the Benelux / Netherlands versions of the lean kanban conference and they were quite a bit smaller. It was actually kind of weird, but also kind of nice, to see so many people I did not know attending a lean Kanban conference. Could the Kanban Method be crossing the chasm? I hope so, because I really believe in the approach, and hope to work intensively with it in the future.

The top 3 highlights for me were:

• The Pecha Kucha Session
• The Ask a KCP Session
• Stephen Bungay’s Keynote

The last conference I attended in 2013 was the Agile Cologne 2013 Open Space.

I first attended 2 Kanban oriented sessions. The first one was quite interesting, the main theme ended up being clearing up misconceptions about what Kanban is itself. It seems most people thought it was a Scrum-like process for maintenance etc. The idea of it being evolutionary improvement tool was foreign for many people. I think this might have been the session where I decided to stop “correcting” people who have this other view about what Kanban is. It is starting to feel a bit like the emperor’s new clothes when the thought leaders are insisting on one view of what Kanban is, yet the actual community of people out there using it are discovering that to them, jt is something quite different? Which group is correct depends on whether we define words according to a descriptive or prescriptive approach. I have now managed to develop a wider model of what Kanban is in my head, and am more accepting of people using it as a flow-based development or maintenance process rather than an evolutionary change tool. I find it increasingly important to distinguish both approaches, i.e. “Kanban” which could mean a lot of things, and “The Kanban Method”, which really does refer to the evolutionary change approach. I still feel like a bit of a dick when people ask me what Kanban is, and I have to weasily answer it like “Well to me it refers to The Kanban Method, which is ….. however most people use the term to refer to their development or maintenance process which features some or more of …..”. Anyway. The second session was comparing Lean, Agile, Scrum and Kanban, We tried to identify where the overlaps were, and which ideas borrow from with other ones etc. It was a much better discussion the the typical Kanban vs Scrum comparison. The small group actually understood the differences better than usual.

The third session was one I attempted to moderate, based on the topic of #NoEstimates. I thought I did a fairly poor job. I found it especially challenging to introduce the topic, do most of the talking, facilitate the discussion, and write things up on the flip chart. In the future I will concentrate on doing just one of these activities. The fourth topic was supposed to be about different ways of pricing software development I think, and I thought I might be able to contribute quite a bit, but the group seemed to be stuck on the aspects of German contract law relevant for services providers engaged in hybrid projects, or projects that are presented to the customer as waterfall projects, but are developed internally with Scrum. This is fair, because this is what most German service providers are concerned with, but I found it boring. If you aren’t prepared to think outside the box, if you aren’t prepared to move beyond hybrid projects, or move beyond fixed price (which can work) or T&M (which is poisonous for knowledge work) projects, or move beyond the old German “Service Contract”s or “Work Contract”s, then of course your options are limited. I know the classic argument is something like “but our customers are only prepared to work in this way”, then I don’t know why you are looking for alternatives. Alternatives exist, but you have already declared your customers won’t accept them so in your case it is easy, you have to work according to how the customer demands! But for those of us lucky enough to have customers that have also had problems with classical approaches in the past and are also looking for working in a better way,  then there are plenty of really effective ways to control and manage risks, and avoid disappointment, misunderstanding and hidden costs. My secret is basically to stop looking for “Agile contracts”, that path only cycles back to where you are now. Look instead for end-to-end agility, radically different pricing models, and THEN write up a suitable contract, or maybe you will discover that contracts are not even always required, or at least they might start to have a different purpose other than declaring what to do when things go wrong. Sounds radical doesn’t it, but the agile community actually used to be radical. 

Anyway, I doubt I will be attending as many conferences in the future as I have in the past, the ROI is starting to seem noticeably less than it used to be. I will be attending the Frankfurter Entwicklertag next week, where Bob Martin will be delivering the keynote. I was lucky enough to win a free ticket to that thanks to Andrena who held a draw at the christmas meet up of the Agile Rhein-Main user group. So big thanks to Andrena for the ticket! I will try and be disciplined enough to write a blog post about the event soon after it.

Apart from that, I don’t plan to attend any conferences this year except when I can speak about something I have actually done that will be interesting for the community. I don’t want to talk about untested theory anymore, and I don’t think the community wants to hear about it either. Hopefully I will be lucky enough to work with some genuinely interesting ideas as part of my job and can report my findings at a conference.

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 3,600 times in 2013. If it were a cable car, it would take about 60 trips to carry that many people.

Click here to see the complete report.