Is it Agile to be SAFe


I have recently updated my SAFe cetification to 4.5.

Scalable Agile Framework. A framework for running agile developing projects in a larger context. SAFe emerged in 2011 in version 1.0 and now, in 2017, 4.5 has been released. SAFe are the most mature and probably the most accepted framework to run Scrum in large organizations.

Most people looking at SAFe for the first time are a bit overwhelming. It looks like a lot of new procedures, a lot of new documents and a lot of new roles to be defined.

The roles in the Safe organization are:

  • Team – same role as in normal standalone Scrum (safe suggest a team up to 9 people).
  • Scrum master – same role as in normal standalone Scrum.
  • Product owner – same role as in normal standalone Scrum.
  • System architects
  • System engineers
  • Release train engineers
  • Product manager
  • Business Owners
  • System team
  • System team scrum master
  • System team product owner
  • Solution train engineer
  • Solution architects
  • Solution engineer
  • Solution manager
  • Communities of Practice
  • Shared Services represents
  • Lean Portfolio management
  • Enterprise architects
  • Epic owners
  • Safe program consultant
  • Lean-Agile Leaders

And yes, if you look closely at the main framework diagram on you can find one small icon on the outer right side representing the customer.


Coming from a clean Scrum world, where everything is evolving around the customer you could be afraid of that SAFe could neglect the customer and the fact that all we develop are for the customer.

In the two days of certification training, the customer wasn’t mentioned ones, in the 555 pages training book the customer are mentioned on 6 pages and in the certification test, there weren’t any customers at all.

Most of the time the customer is mentioned in SAFe, it is when the agile manifesto is quoted:

“Customer collaboration over contract negotiation” 

The customer is a quarter of the entire Agile manifesto – but nearly forgotten in the SAFe framework.

So if you plan to implement SAFe – please take a time-out session, perhaps with your sales director and get your priorities straight. You could write a big statement on the wall in your project room about your customer or make a painting like the one I described in “don’t forget the customer”.

Before I worked in my first SAFe project, I had looked at SAFe as just another way of killing Scrum with a lot of unnecessary administration. And believe me, a lot of people have tried to kill scrum since the Agile Manifesto was reviled in 2001. But I must admit that SAFe is probably the best frameset for dealing with developing tasks there are larger than what one Scrum team can handle.

The SAFe frameset comes in 4 different sizes:

  • Full SAFe
  • Large Solution SAFe
  • Portfolio SAFe
  • Essential SAFe

If you are about to introduce SAFe, my strongest advice is to focus on the Essential SAFe – ones you have the agile teams up running.

Basically, the Essential SAFe is just a way to handle multiple Scrum teams working together on the same overall system backlog.

It’s a way of handling all the interfaces between Scrum teams, and there are actually quite a few nice ways to ensure, quality, progress, planning, and demos, by operating with a SAFe Agile Release Train.

In my mind, SAFe should only be enforced when there is no other way to get the job done using one Scrum team. No matter how many versions of SAFe are beaning released, and no matter how many framesets are introduced, no matter how much SAFe are talking about Lean Management and Lean-Agile Leadership,  everybody there are forced to shift from basic Scrum to SAFe, should be aware of that they are selling out of the fundamental Agile ideals:

  • Individuals and interactions    over processes and tools
  • Working software                     over comprehensive documentation
  • Customer collaboration           over contract negotiation
  • Responding to change             over following a plan

SAFe introduce some management roles there will take “power” away from the scrum teams, and it introduce som administration and planing meetings there will have a negative impact on the team’s burndown chart.

But out of all the models, framesets and management handbooks trying to manage Scrum, SAFe have become my favorite…..

Two out of tree isn’t so bad

From time to time, I use stories to illustrate a point. When talking about prioritization, I always use a story from my early childhood.
When I was growing up my family had a vacation house by the see, where we stayed during school holidays. My father was working in the city and would normally return to the house around dinnertime. One afternoon my mother was in the kitchen preparing dinner. I was constantly asking her for permission to go out and play. I came up with all kinds of suggestions: “Can I go out to the field and fly a kite?”; “Can I go down to the beach and fish for crabs?”; “Can I go to the stream to sail my model boat?” and probably a lot of other such suggestions typical of a 7- or 8-year-old boy stuck alone in a vacation house in the countryside.
On this occasion, as dinner was nearly ready and my father due home, my mother was reluctant to give permission. But I must have been really annoying her, as she suddenly said, “Ok, go where you want to go and play with whatever you want to play with – but be home for dinner in half an hour.” I ran out to play and came back long after everybody had finished dinner. My mother wasn’t pleased with my behaviour. But before she could say anything, I told her, “You said I could go anywhere and play with anything and be home for dinner.” I remember listing the three instructions on my fingers as I spoke. “I went down to the stream and played with my boat,” I continued as I held out my second finger, “so two out of three isn’t so bad, is it?”
It turned out it was. My mother and I did not prioritize the list of activities in the same way …
The last time I used this childhood story was at a project management meeting in a large development department. The project chief started the meeting by announcing that the senior R&D management committee had finally prioritized all the different development projects in the company. As he proudly read the list, I noticed two things: one, the project I was hired for was number one on the list; and two, there was noticeable scepticism among the 20 other project managers. When the project chief had finished reading, the questions came promptly from the other project managers.
“What about this new prestigious project we are developing with the large Japanese company?” … “That should be a higher priority – it’s much more important than our own projects.”
“What about the projects we are testing at our different test sites?” … “Isn’t it obvious that we can’t stop or reschedule any tests just because we’ve prioritized our own projects – do you know what it costs to start up a test?”
“What about customer claims? Should we put those aside to work on the top priority projects?” … “No, no, no, the customers are most important – at the end of the day they are the ones paying your salary.”
The questions kept on coming, and in just five minutes my project was not even in the top ten. The existence of a priority list hadn’t changed anything. During the course of my project resources were constantly being dragged out of the project and redirected to customer claims, or to help the team working on the prestigious project and all kind of other projects with an official lower-priority status. It was a constant struggle with service managers, test managers and all kinds of line managers, all of whom obviously didn’t accept the official priority list.
I have been in many other companies with the same problem. In most companies, it is easy to prioritize tasks within one department, but nearly always impossible to do so across many departments.
In project management training and in project management books, concepts such as “change management” and “exception handling” are important and well covered. However, the problems facing a project manager when his/her project suffers a lack of priority is quite another story. I have seen many new project managers and many projects failing due to this issue.
In my opinion, there is only one thing to do – accept that your project has a low priority and act accordingly. One of the key tasks is to identify the project resources – not the allocated resources, but the required resources – for your project, and then plan accordingly.
The first plan you make, before the project kicks off, should take into account the allocated resources, even though you know they may not always be available. However, as soon as you see project members being dragged away from the project you should review your plan – not just by postponing the end date by the couple of weeks you are behind, but by planning the remainder of the project with the percentage of the project’s resources that have been available in the project so far.
When the review board ask why, you can tell them your plan reflects the lack of commitment and prioritization, and back this up with your resource data. In most cases, they will tell you that the problems with resources were due to extraordinary circumstances and that you can’t base your entire plan on one isolated incident. You can then assure them that you will update the plan for the next review meeting with the actual project resources there have been available.
If a senior specialist have been allocated 100% to your project, but he constantly have been working half the time on other projects, you should only plan with 50% for the rest of the project.
Most project planning tools have an adjustable percentage for each resource, so it’s a fairly simple task to revise your plan based on the actual resources used.
In the first three to four drafts of your project plan your end date will change a lot, but after a while it will stabilize and your plan will start to reflect the actual state of your project. Your plan should always reflect the state of your project, and not the promise you were made by the resource owners.2outof3
If your project isn’t prioritized, your plan must show it – that’s the only way to get things changed. At the end of the day it’s the project triangle all over – and two out of three is bad!


Have you ever played with you balls glowing in the night

“Have you ever played at night with your balls glowing?” That’s the best question I’ve ever been asked. It was the first thing a young Indian girl said to me after she rang my doorbell, just after midnight, on my first night in my new apartment in India.
I like sports expressions and have used them regularly in both my private and professional life. With a long football-coaching career behind me, most of the expressions I use naturally come from football:

  • Keep your eyes on the ball
  • Go for the ball, not the man
  • They are always our twelfth man

However, sports analogies aren’t always appropriate. Once I was helping to downscop a large IT installation project in an Arabic company. We had assembled all the project managers to tailor the tests scope. The project managers there were a mix of Indian and Arabic IT specialists, was debating what tests there were essential to meet the contract, but in the middle of the discussion, the American sales director said, “If you are cutting these functionality tests, I have to throw a flag.” You could see from the project managers’ faces that they couldn’t understand the necessity to involve any flags in the discussion. The sales director’s point about wanting to investigate whether cutting the tests was against company policy was totally lost on them, as none of them knew anything about American football and the usages of penalty flags.
If you work in an Indian company, you will undoubtedly hear many cricket-related analogies, such as:

  • We are batting for the average
  • You have been bowled out
  • That’s in your corridor of uncertainty

Expressions anyone there don’t play cricket, will have a hard time to understand when they are used to describe thing outside the cricket lain.
Nevertheless, many people use words and expressions from all kinds of sports they have never played. Many say, “We should touch base” without knowing the rules of baseball. Many talk about using scrum in their project, without knowing anything about rugby. You can find people threatening to give a yellow or red card, without knowing the rules for issuing penalty cards in football.
My three football expressions could be interpreted quite differently, depending on whom I use them with:

  • If you say, “Keep your eyes on the ball” to a European football player, it means, “Don’t get fooled by your opponent’s body movement.” However, if you say it to a cricket player, it means, “Focus on the game, not on the spectators or the weather.”
  • If you say, “Go for the ball not the man” to a European football player, it means, “Please follow the rules – tackle the ball not the man.” However, if you say it to an American football player, it means, “You are too weak to tackle anyone.”
  • In football the “twelfth man” usually refers to the fans, but in cricket it refers to the youngest player who will serve the tea during the break.

In most cases they are used informally and can be quickly explained … if you are communicating face to face. However, if you are using sports expressions in written communication, things can easily be misunderstood, especially if you are operating in an international environment.
My first encounter with my Indian neighbor was face to face, and I think she could see by my face that I needed more information in order to answer her question. Luckily, she had a brochure explaining that her husband had an indoor team-building center, with a miniature golf course, where you could play in the evening using fluorescent golf balls.


I don’t hate spreadsheets as the tool they were designed to be, back in the ’80s when Lotus was struggling to count to three, in the days where Borland, IBM and Apple were trying to keep up with Lotus and develop a quality computer program to replace the paper-based spreadsheets used by accountants. But I do hate what Excel has become today. Even the name spreadsheet has been replaced with Excel sheet, together with the total annihilation of all its competitors in the spreadsheet business. Excel has become the magic wonder tool that turns everybody into amateur computer programmers and wannabe database managers.

Some time ago, I was the new external project manager for the high-end technology-development project of a large global company. I was presenting my first project update at a project review management meeting. At the meeting, one of board members insisted on receiving a special Excel report on my project. A report that another project manager had developed a long time ago. A report that the project manager had maintained, updated and delivered to the board at every monthly project review meeting for the previous two years. A report that made no sense whatsoever in my project, as it was developed to track progress in an operational-cost-optimizing project, whereas I was running a technology-development project.

When the board member described the report to me at the meeting I knew precisely what I was in for. Endless late hours trying to understand the mind of a person I had never met; trying to understand his view of a project I only knew from headlines; and trying to align the mindset of an organization nine time zones away from my project. I could spend all the time in the world decrypting a non-programmer’s illogical formulas, tracking his cryptic cell references around the worksheet, and trying to understand two years of continual “improvement” made by copying and pasting cells around – and for what? Just to have a graph that very few people could understand and which nobody would ever benefit from.
I feel the same way about Excel as I do about my toothbrush: I like it, I use it several times a day, I even like to update it from time to time, BUT I would never use another person’s toothbrush or let them use mine.

I was right: I received the 10 MB Excel file. It had been created two years previously and was now at version 22. It contained 15 tabs, with references flying around them and even some to an external Excel file that I didn’t have. It contained an enormous amount of data, calculations, lookups and references, and on the very first tab was a graph that only made sense to two people in the whole world. When I finally received the external Excel file, it contained just one number in one cell: 1.23. I thought it was a joke, but it turned out to be the exchange rate for euros to dollars. To the best of my knowledge 1.23 hasn’t been valid for more than a year; it was probably valid when the worksheet was created, but not anymore. I immediately wrote an email to the file’s author: If you really want a precise, updated exchange rate in Excel, use “Data” – “Import external data” – “Import Data” – select “MSN MoneyCentral Investor Currency Rates” and click OK.

Oops – there I go again. I really hate Excel and what it does to people. Just because I knew a cool Excel trick, I couldn’t stop myself from flashing my knowledge about and demeaning the nice man who was just trying to help me by providing a copy of his Excel files.

Looking at the different tabs in the sheet and the content of some of the cells, I gave up. This man surely didn’t know what he was doing – he must have spent hours developing the Excel file and he must have spent hours every month updating it. In no time at all, I found myself starting from scratch, copying only the graphs so no one could see the difference.

But OK – on with my project and my project-status-Excel-spreadsheet, now containing an empty graph and a link to all the currencies of the world. I created a data connection to the oracle database containing BoM (bill of material) for the mechanical parts my project was developing; one to another oracle database with the schematics that included the BoM for the electronic components; one for the company’s enterprise resource planning (ERP) system with prices for components; and one final connection for the employees’ time registration database. And then, by adding, subtracting, adjusting for currency, linking to the project budget in the business case, linking to the target cost price in the detailed business case, adjusting the data set for the graph, and finally setting all the database connections to update automatically every five minutes, I had created my Excel sheet. It not only gave me the online status of my project, with cost price for the product and cost of the project, but I had also created a minor monster that had more than enough to do in merely updating itself: it used all my CPU power and 90 per cent of the internet bandwidth in the office. And for what? Just so I could have a graph that changed once a week, and so that I could ask team members at the weekly team meeting to update their BoM and time consumption registrations.

My team might not be online 24/7, but my Excel graph and I were. And all of it created by clicking around in some harmless-looking boxes in Excel, without any warnings and without any “Are-you-really-sure-you-know-what-you-are-doing” pop-ups.

At the next project review meeting, I proudly presented my online version of the project-status Excel sheet. After explaining where the data came from and how all the bits and bytes were joggled around from company and external databases into different tabs in the sheet and onto other tabs for their final destination (the graphs), a senior member of the review committee looked at the projected graph with great interest. I secretly wished for yet another meltdown on Wall Street so he could see exactly how online my sheet was, but instead he looked at me and said, “But what is the status of the project? Are you progressing as planned?” I was astounded. He had just looked at three colourful Excel diagrams telling him that, at that very second, the projected cost of the project was 82.12% within budget, the cost price was 22.30% less than the target price and that all project tasks were 34.31% completed. No one could ever give him a more precise status. So I just said, “The status is fine and we are on track.” “OK,” he replied, “next project.”

All that work, and a simple “OK” was all it merited. The procurement executive who had initiated my work wasn’t even paying attention to my colourful online Excel graphs. And then it struck me. The project review committee were only interested in “Are you progressing as planned?” and not in how and why or how much with two decimals’ accuracy. They had hired a senior project manager with a lot of experience in managing large global development projects, and they just needed to hear me say, “The status is fine and we are on track.” Nothing more.

So for the next review meeting, I turned to another of the wonder tools coming out of Redmond these days: Microsoft PowerPoint. I created one slide with a screenshot of my graph from the previous meeting and one slide with a screenshot of my graph based on the present month’s numbers. And yes, I am embarrassed to admit, the new graph was several hours out of date by the time I presented it at the meeting. For my third and last slide I showed a traffic signal with a green light.

Everybody was happy and we spent most of the remaining review meetings talking about more interesting things than graphs and numbers, such as the different natures of technology projects and operational optimizing projects. And even I learned a thing or two.

From time to time someone tried to get a copy of my Excel sheets, but I always refused. Instead, I offered to sit down with them and help them make their own. Nobody is borrowing my toothbrush or Excel files. Partly on principle but mainly because I am afraid that even I can’t decipher the “logic” behind my own Excel sheet anymore.


I teamed up with an old buddy of mine recently. He was working as an international management consultant like me and, as we both travelled a lot and had month-long assignments all over the world, it had been some time since we had seen each other.
After a couple of beers and a lot of talk about work and assignments, I asked about his girlfriend – the last time I had seen him he had divorced his wife and was living with a new girlfriend. He immediately changed the subject and started talking about how difficult it was to update to the new Microsoft Office pack, something like – “You know how you have the Microsoft Office 2003 pack, which you have had for some time and are quite familiar with, and even though the old 2003 version is fulfilling all your needs and doing a nice job you still get tempted to try a more modern version like the new Office 2013 pack which has a nicer look and feel? Well, I have recently realised that you shouldn’t try to run both versions at the same time: even though they might be loaded onto different computers (for example, the old 2003 version at home on your desktop computer and the new 2013 one on your laptop) you will eventually find yourself in a situation where you have created something on the new Office pack and forget that the old Office pack isn’t compliant and won’t accept it.”
I replied by saying something like, “I have the same problem, though I don’t have the money to go and buy new Office versions every time Bill Gates releases one. On the laptop I use when travelling I have the Ubuntu operating system with open Office pack installed – I actually only use free public software when I travel, but I also have to be careful not to mix the documents and I can’t use the open Office routines when I come home to my old Microsoft Office pack.”
He smiled at me and asked, “Aren’t you afraid of getting infected by a virus when using free public software while working on assignments?” I tried to explain to him that I was very careful to have reliable antivirus software at hand, when halfway through the sentence he laughed out loud … and I realized then that he had never changed the subject at all … he was talking WAGS – wives and girlfriends – while I was talking Office PACKS!

One of the more important tasks for a manager in the IT business is to make sure that all members of a project team are talking about the same thing. A project team often consists of people with different backgrounds and talking different ‘languages’ even though they all speak English. The sales guys, the finance guys, the programmers, the service guys and the operations guys might use the same words and they can even be at the same meeting, hearing the same things, reading the same minutes of meeting, but they can all draw different conclusions from that meeting.project

We have all looked at office cartoons like this one and thought, “Oh, how true” but project managers should make it a key task to ensure that all team members talk the same language and all pursue the same objectives.

Some simple guidelines for aligning a team in a meeting:

    • Write all major conclusions up on a white board or directly into a document shown on a projector during a meeting. The spoken language can in many cases be interpreted quite differently but when people have to relate to written text on an anonymous white page they seem to have a more common understanding of how to interpret the text than hearing the same words spoken by a body-pierced, long-haired programmer using facial expressions and hand gestures.


    • Avoid unspecific terms such as:
      - best on the market
      - as soon as possible
      - nice user interface
      - fast upload
      - high usability
      - no downtime
      Whenever a term like these are mentioned, make a task in the backlog to specify them so that at the next meeting you can say, “The upload has to be at 3 Mbit/s on average and faster than 1.5 Mbit/s for 99.8% of the time” instead of “Fast upload”.
      Sales people using the term “Best on the market” will seldom have the best on the market, because the best on the market is most likely to also be the most expensive and the hardest to sell on the market. They have to do their job just like everybody else and make sales calculations on different product prices, calculate payback time and all the other sales stuff.
      “No downtime” doesn’t exist – 99.9 % uptime does, if you are willing to pay for it.


    • Use a clear common language; avoid special acronyms and discipline-specific slang. A NDA could be interpreted as:
      - Non-Disclosure Agreement by the purchasing department
      - No Data Available by the database managers
      - New Dimensional Applications by the SAP programmers
      - Network Design Activity by the network guys
      - Non-Destructive Analysis by the test guys
      - Normal Daily Activity by the operations guys
      - Never Die Alone if you are a young apprentice and into heavy metal …


    • Avoid non-standardized document formats – I was providing consultancy services to a company that had recently introduced Scrum. In spite of their hard work and goodwill the introduction had not been successful. One of the issues was a simple matter regarding the use of the company’s Word template. The sales department always inserted a line at the bottom of Minutes of Meeting (MoM) document summarizing the items that had been resolved during the meeting. The development department also inserted a line at the bottom of their MoM – but they summarized the unresolved issues from the meeting. In each department the two different ways of using the company’s Word template worked fine – and had done so for years – but when the company introduced Scrum and the sales guys took up the roles of product owners in the developing teams, things got quite confusing!


    • Be careful regarding the use of company slang or terminology. A phrase can be repeated so often in a company that every employee understands the full meaning of it … inside that particular company. However, be aware that the same phrase used in a different company can have the opposite meaning. I was working in a large Danish company where the phrase “hay to the goat” meant profit, but later I worked for a German company where the same phrase meant that production was not optimized and too much waste material was generated.

As a project manager you sometimes have to assume the role of the imbecile team member, asking all the embarrassing questions, displaying ignorance and a lack of understanding. You must do this – regardless of your knowledge and understanding of the topic in question – on behalf of the shy team members who don’t dare ask the questions themselves. Remember you are the manager – your job isn’t to be the know-it-all but to be the one who makes sure that all the team members know the things they need to know in order to carry out their job.

So, if a team member is talking about “wives and girlfriends” and you think other team members might think he is talking about “office packs”, ask the question … “Are we talking about WAGS or PACKS?”

Vigilante-European-know-it-all guy

indiaI travel a lot, and I meet a lot of people. Most of the people I meet are just that: “people I meet”. But from time to time, I meet people that leave a life-long impression on me: some positive and some negative. One of these was a 12-year-old boy, dressed in a very worn and very dirty blue and white school uniform, on the streets of Pune , (India) outside the entrance to one of the many slum areas.

At that time I had been living in India for a month, working on a large IT project. As usual, I had put on my sneakers and had gone walking around the city – not on the high streets, with all the other white folk – but in the residential and shopping areas of the local Indian citizens. The high streets were like a hunting ground for beggars, pulling all kind of scams on whoever looked like easy prey. And I must admit that at that time beggars were beginning to get on my nerves; not the fact that they were there and were begging – it was India; I had expected that from the beginning – but partly because I was beginning to change into a cold-hearted person that didn’t care anymore, and partly because some of the beggars’ scams were so obviously a scam that I felt it was an insult to my intellect.

When you have been approached a couple of times by the same two sisters begging for money, one of them pretending to be blind, you start to notice that it isn’t always the same sister that is ‘blind’. Or when you have seen a 12-year-old ‘mother’ with her newborn baby, begging for money, constantly repeating “No milk” and pointing at her pre-teen breasts, “Need milk, please sir” and pointing at the baby, then running into the slum to return the baby and split the profit with the real mother, you start to get cold-hearted and a bit pissed off on behalf of the vast majority of the hardworking Indian population.

So when that boy came up to me, and said, “I have a letter for you” and handed me an envelope he had clearly held for a long time, I immediately suspected his scam: he had found a trashed school uniform in a dumpster and had got someone to write a letter saying he needed money for his education. And I was right: the letter started “Dear Sir, Rajani is a very gifted student, coming from a very pure family …” going on to say how many sisters and brothers he had and how his father had been killed working in the construction industry, and … and … It ended up listing what he needed to complete that semester in school. And the scam was so perfect that it looked as if the letter were ‘signed’ by the principal of the local school – some smeared ink could look like an official school stamp.

I looked around expecting to see some adult hustlers monitoring how their golden calf was doing. The only one I saw was a security guard from my building complex on his way home; he smiled to me and pointed up the road to Bishop School. I interpreted his gesture as “Ok, let’s take this boy to the school, so they can handle the misuse of their name”. The guard took the boy’s hand and started walking to the school, talking Hindi to the boy – I was a bit proud: justice in the making, “one down – 1000 to go”. When we got to the school, the guard handed the boy over to the school’s security guard who recognized the little hustler – ok, it wasn’t the first time that this joker had been caught.

When we went into the administration office, things changed – the secretary knew Rajani, and was so happy he had found a sponsor … I was so astounded that I nearly couldn’t move a muscle, and so ashamed that I had taken on the role of vigilante-European-know-it-all guy. I had never before been so wrong in interpreting a situation, anywhere in the world.

It took some time before I realized that no one knew my original interpretation of the boy’s intention: everybody thought I was a genuine white wealthy Christian saint, so I put on my poker face and negotiated a payment plan for notebooks, pencils, school uniforms, school lunch, milk and … quite frankly, 1½ years of schooling sponsorship for Rajani in India – which wasn’t more than my own three teenage kids would burn off over one weekend in Europe.

It’s the same with a project team – do not enter the team with the attitude that you know it all, and that you shall now take control of everything, and do what’s right. It may come as a big surprise for many IT Project Managers but:

You don’t know everything and you shall not control everything.

If you really know everything, you shouldn’t be an IT Project Manager; you should be a specialist in the team, where your expertise isn’t wasted on managing the team.

Project management is a discipline; it takes skill, training and experience to master. It’s not something that automatically falls down from the sky after you have programmed C++ for five years, Java for three years and have been an infrastructure architect on two large IT products. That doesn’t turn you into a Project Manager: it turns you into an experienced IT specialist.

Unfortunately, project management is a natural career move in many IT companies for experienced programmers and architects.

You can always spot a project that is running under the command of an IT-Specialist-Project- Manager. I deliberately use the word ‘command’ instead of ‘managed’, because that’s precisely the difference. A manager manages the project, but if you know everything – and actually think you could have done it all by yourself – you tend to step into a command role: commanding people to do this and that, without asking the team for solutions, without opening opportunities for creativity and innovation … why bother, when you know all that needs to be done.

I would at any time choose a Specialist-Project-Manager if the project was to build twenty identical houses according to the drawings and specifications from an architect and a building engineer. But when we are talking about an IT project it is never that defined or structured. With an IT project, the building bricks aren’t the same size or shape as the bricks in your last project; the methods for handling the bricks change, even in one project’s lifetime, but what’s more important is that the goal of the project keeps changing all through the project.

You could even ask, “If a company had all the specifications for an IT project, didn’t care what was going on in the real world and just wanted the project finished using the known tools and methods, would they need a Project Manager at all? Wouldn’t the project be better off with a librarian-style secretary to help find the documentation on these known tools and methods?”

There are IT Project Managers like that, and there are companies where these managers are considered excellent managers. They know the business development handbook inside out; they always fill out the right form at the right time in the right way. These same managers can present a complete plan for the project at the first project meeting but they are managers who command people to perform tasks. They are often the managers who either get stressed out if there are too many changes or – if they manage to reject all the changes – end up with a hopelessly outdated product. These are the same managers that constantly get frustrated over the team not performing as anticipated and who stop managing the team and start ‘helping’ them by coding special libraries, designing databases, making architecture, etc.

Most IT guys know these managers, and hate them, but at the same time they accept them as experts and let them carry on. If you approach the team with that know-it-all attitude they will automatically categorize you as a Specialist-Project-Manager – even though you are not. They will stop being creative and innovative, go into autopilot mode, and won’t do anything unless you tell them when and how to do it.

If you are a very experienced IT professional, use your experience to guide the team in the right direction; don’t take their jobs from them, manage them – that’s what you are there for. Steer them out of trouble and inspire them. Who knows, the knowledge they are gaining from the project and the solutions they come up with, might even impress you …

By the way, a couple of months after my first meeting with Rajani, he came and visited me together with his mother and his younger sisters: Rajani in a brand new school uniform, proudly showing his latest English essay with his teacher’s excellent remarks. Over an hour, we drank tea and ate ice cream. Rajani’s sister was scared of a wooden cobra I had on the table and got so attached to the teddy bear I replaced it with, that she had to take it home. Rajani translated the few things his mother said and he told me about school and his family … Ten times he mentioned that his sister was very gifted and should start school in a month … but this time I got off with a bowl of ice cream and a teddy bear.

I still have the wooden cobra on my desk, to remind me of Rajani and that I don’t know everything and shouldn’t act like I do.

Agile scapegoat

It happened again – I ran into the Agile scapegoat.

Do not picture a nice cuddly goat jumping agilely around an alpine hillside, while blonde pigtailed Heidi is yodelling in the background … don’t!


A scapegoat is one of mankind’s more cruel inventions; it’s a special breed of goat with a hereditary neurological disease. The disease makes the goat freeze when it’s scared. So if a medieval farmer had valuable animals grazing in an area with wolves or other predators, he planted a cheap scapegoat in the flock, knowing that the scapegoat would freeze and be the easiest prey for the predators, allowing time for the valuable animals to flee the attackers.

The 20th century agile scapegoat is perhaps an even more cruel invention; just like the medieval farmer who had no intention of taking care of his goat, some R&D managers introduce the agile developing model into R&D organizations with no intention of turning the organization into an agile organization. Their only intention is to have a scapegoat to use when the predators from senior management start to attack the organization with irritating inquiries into missing results, bad project planning, endless rescheduling of deadlines and project budgets that have run wild.

In the beginning, the introduction of agile development methods was driven from the bottom up. Enthusiastic grass-root employees had seen the agile-light, and had started using agile methods, not caring what the corporate strategy was. Everyone working in some of the first agile projects was forever “scrumifyed” – it was fun to go to work in the morning and you were proud of what you accomplished. Day after day, the team spirit grew and you were sure the whole world would recognize how cool it was to run projects using agile development methods.

But the more enthusiastic you were back then, the sadder you got when you met the agile scapegoat. Typically it grazes in developing departments where R&D management have introduced Scrum by buying a fancy IT tool and hiring external consultants to make the introduction.

A top-down introduction of Scrum, without any heart or soul involved, will result in the most amazing interpretations of the Agile Manifesto.

The original Agile Manifesto Some of the interpretations I have seen in agile organizations
Individuals and interactions over processes and tools Let’s buy an IT tool to take care of all the Scrum stuff and then we can stop talking together.
Working software over comprehensive documentation Let’s drop all documentation.
Customer collaboration over contract negotiation Let’s drop written contracts with subcontractors; an email with an amount and some good intentions are ok.
Responding to change over following a plan Let’s drop all plans and task shift several times a day.

I’m sorry to say that it seems like a pandemic – a worldwide virus spreading out of control at a speed that no WHO official would accept.

Perhaps there’s a conspiracy behind it all – a conspiracy to kill Scrum.

A conspiracy of gold-digger consultants and wannabe IT companies marketing all kinds of foolish tools, where the only Scrum parts of the tools are some of the words they have picked up and reused in the program.

My favourite line in the Agile Manifesto is:

Individuals and interactions over processes and tools

You clearly don’t have to agree with the Agile Manifesto in order to market an IT tool as agile … Nor, apparently, if you are introducing a tool to ‘take care of all the Scrum stuff.’

But what puzzles me most is that you will find team members and managers with proper Scrum training and tons of Scrum experience in these organizations that so clearly abuse the Agile Manifesto. You will find programmers and testers that have worked in other organizations where Scrum was introduced and used properly with great success – and they are not afraid to tell you.

So what is going on? Why do some people in R&D departments accept the agile scapegoat?

I think it is a combination of many things:

  • R&D managers like to have one person that they can call into their office: one person that is responsible, one person to blame for not completing the project yesterday. In real Scrum, lack of progress isn’t really the Scrum Master’s fault – the Scrum Master is just the facilitator of the Scrum process. Neither is it the Product Owner’s fault – the Product Owner is just prioritizing the backlogs. So it must be the team’s fault, but you can’t really call in the whole team, and by the way who was it that initially appointed the team? So there is only one person that the angry R&D manager can point the finger at: himself … and no one likes to do that.
  • Scrum Masters are in many cases Project Managers tricked into becoming Scrum Masters. Project Managers who saw it as a step up in their career, without knowing that a real Scrum team is self-organizing, and that a real Scrum Master doesn’t delegate tasks or manage the project. When the new Scrum Master realizes that his job is to facilitate the Scrum process, he begins to see himself as a team secretary and not a team manager anymore. No ambitious manager wants to take on that role, so most of them fight to regain some of the power they had as Project Managers, resulting in a self-appointed Scrum-team-manager-Master role.
  • Introducing Scrum in any team takes a lot of discussion and explaining. Most teams are terrified by the new freedom to be self-organizing – mostly because they realize that responsibility goes hand in hand with their newly gained freedom. They can’t go home and tell their partner that the Project Manager is destroying the project. Team members can’t hide in a proper Scrum team: no more pretending to work; no more explaining that a task takes longer to do than it actually does; no more taking time to investigate things of personal interest just because the Project Manager doesn’t understand the fancy words being used; no more nerdy details just for fun … just work, work and work!
  • At the beginning of a Scrum introduction in a company, all Product Owners are overwhelmed with happiness – especially if it’s a guy from the sales department: finally somebody appreciates their knowledge and deep insight into customers’ requirements; finally somebody gives them real power to get the products they have been asking for all along! But it takes more balls to be a Product Owner than the average sales guy has. After the first product release, the sales department will find that they cannot use their most popular excuse: “we can’t reach our sales targets with these lousy products.” And in no time at all, the youngest sales guy becomes an old-fashioned Product Manager and is moved into a separate department belonging to neither sales nor R&D – just floating around the organization like a hot potato under the CEO.

It is hard and it takes a lot of work to implement agile development methods. A lot of organizations can’t get it right the first time and have to try several times before they succeed in creating a truly agile developing department. But unfortunately, a growing number of organizations don’t even try wholeheartedly; they start out knowing that they are going to fail, just to get the agile scapegoat.

I think it’s at that point in the organization’s change process that the foolish wannabe-Scrum-IT-tools enter the arena. Everybody knows that the change process has failed; the old developing process hasn’t been replaced with anything – just abandoned – and anarchy rules, with defeat just around the corner. But unfortunately, some manager comes up with the snake-oil wonder medicine – a fancy Scrum-IT-tool. Don’t misunderstand me – there are useful Scrum-IT-tools on the market, but if you just implement an IT tool to emphasize that your organization is agile, even though it so clearly isn’t, you are only making things worse. Looking at the market for agile tools, it seems that there are some tools available whose only purpose is to help the organization look agile, without any functionality to support the agile process whatsoever.

Tools just made for the Agile Scapegoat …



Mind over paper


I recently started a new project – one with a lot of external partners. We decided to use a Stage-Gate model for the main project and then allow the managers of the sub-projects to use their own favorite models.

As it was a large company (75.000 employees) I wanted to do things the right way, and as I’m a certified PRINCE2 Project Manager, I found the latest P2 templates for working packages and got started …

No, not filling out the six pages of nonsense in the official P2 work package template. I started deleting. In no time the work package was reduced to one single page containing the information I needed, the information the company needed, and not least of all, all the information the recipient of the work package needed.

A lot of what I deleted was useless nonsense, such as:
- Escalation Procedures
- Configuration Management Requirements
- Operations and Maintenance Interfaces
- Techniques, Processes and Procedures
- Reporting Arrangements
- Problem Handling
- And ……
I did think it might be wrong of me, as somebody had spent a lot of time putting all “the nonsense” into the PRINCE2 template. But justification came the next day when one of the recipients complained to the R&D director about too much ‘project management’. You might ask yourself how he could do that without a one-page schema of escalation procedures in his work package. The answer is simple: he was an intelligent human being.

If from time to time I work under a manager that ‘hides’ himself behind paper, I have a hard time respecting him – one who always write emails with more than 10 lines of text, or CCs everybody on all mails, or spends endless time in meetings showing the fancy PowerPoint presentations he has made or write long documents containing nothing of value and extremely detailed minutes of meetings.

I can still recall the first time I saw a powerpoint show. It was a Project Manager for a project I worked in the 90’es, he called in a project meeting with 14 members one week before the planed release date. With only one point on the agenda – we were one day behind schedule in the test process – he spend over half a hour to explain how important the project was and how much our marketing department have invested in the release. The company have just got its first Microsoft PowerPoint, and I would estimate that he have spend the most of the day making his first PowerPoint show and as the company only had one projector in the board meeting room, we were all there for the first time – I can still see us – a bunch of young programmers in jeans and t-shirts, sitting around the big rosewood table in the fancy white leader chairs, looking at the big portraits of the company’s founders. At the end of the meeting he ordered us to stay in the meeting room until we came up with a plan to gain the day we were behind. It was just before lunch. The two testers knew what was expected of them, they should sacrificed there weekend to make test and the 12 others of us knew that the project manager expected us to bully the two tester, so we could go to lunch. But we all agreed to order pizza and stay over lunch in the board meeting room helping out the testers. When the project manager came back from his lunch the project was back on track, and we all made it crystal clear to him, that the whole team expected him to clean up the pizza boxes instead of writing a minutes of meeting – now he had wasted our time with his PowerPoint show. I think he got his secretary to clean up – but we never got a minute of meeting from the last project meeting.

Remember, every time you spend thirty minutes writing the minutes of a meeting and send it to the ten project members attending the meeting, your project is five and a half hours short, not counting the time that everybody will have spent reading the emails and replying with stupid comments! (Some people think that they have to write something just to show others that they have read all four pages of the minutes). And then there’s the time you will spend in the next meeting going through the minutes from last meeting … and the comments. The thirty minutes you spend after the meeting writing the minutes of meeting can easily explode into several days of missing project time.

But what to do then? There is no golden rule, but first of all think and adapt your approach to the people you are communicating with. Don’t ever just press send; take time to read, reduce and clarify your emails and documents.

A two-line email combined with a face-to-face talk can be a better approach than a twenty-line email with attached documents.

A picture of a nice structured whiteboard made during the meeting with all the important issues, tasks, decisions and diagrams can be far better than a four-page minutes of meeting.

A good IT tools to collaborate on designing documents can save a lot of meetings and unnecessary meetings.

And please don’t hide behind a paper wall: in the real world it will not protect you; it just kills the rainforest, the project and you.

Duct tape the fatsos


Most people think of pre-teen boys suffering from extreme obesity on a fast food restaurant when they hear the word ‘fatso’ and that’s an okay image to have in mind – kids with mothers that love them so unconditionally that all sane eating habits and their kids’ physical well-being are put aside to make room for satisfying the endless desire for food.

I took over a scrum team ones. The former scrum master had more or less given up. The burndown chart was fluctuation in a degree that everyone could see that he wasn’t doing a good job, and the team didn’t deliver anything even though the team was build up by senior programmers.

It didn’t take me a long time to see where the problem was – the team room was busier than Termini railway station in Rome in the tourist season. It shouldn’t come as a surprise to anybody, that when you put all the senior programmers in a company on the same team, a lot of developers from other teams, salespeople and service people need to talk to them from time to time.

So one morning I addressed the problem, by introducing a board with the headline:

“Folks who eat our resources”

We agreed that everybody could put a post it-sticker on the board, with any incidents where they observed team members wasn’t working for the team. After three weeks we had a session where we used “the parking lot” methode to grope all the post-it stickers.

I asked the team to prioritize the groups of disturbances we had encountered and to come up with ideas to deal with them.

At that time the magic marker I have used 3 weeks earlier for the headline, wasn’t so magically anymore so the headline only was…., so when we made the list of solutions one in the team gave it the headline

“Ducktape the fatsos.”

Properly as a hint to my BMI at the moment and properly because they thought the excise was a waste of time invented by an external consultant just to annoy them.

Some couldn’t we do anything about, and some of them could the team handle them self, but surprisingly enough was there quite a bit of disturbance the team would like me to handle.

But never the less – the disturbances dropped to a minimum and the burndown chart became relabel.

Thinking back on the team, I shouldn’t take any credit for the improvement. 50% of the disturbances disappeared just by talking about the issues, making people aware of what impact their behavior had on the rest of the team. The other 50% I’m sure the team could have handled themselves, but Its always easier to have an external consultant to be the “boogeyman”….

If you use the same approach, remember to get the hole team in on it, so you get an acceptance of that the youngest programmer point out that the most senior programmer is late to half of the team meetings. But also take the indirect disturbances into consideration, tell the team that there is a meaning with having a team and the people in the team are handpicked to perform as a team:

  • If you have team members from different departments, it causes a lot of noise if the department meetings aren’t synchronized.
  • If you have flexible hours and some team members come in at 7:00 and some at 10:00 the team is missing momentum.

So explain that we are looking for all disturbances internal, external, direct and indirect.

When you are prioritizing the list of disturbances you have to do it form the team side, not from the company side or from the individual team members side. And remember to take the time used for task switching into account also. We made the prioritization by roughly calculating the minutes there was stolen from the  team :

  • If a secretary comes into the team room to tell one of the team members about her skiing vacation in a way that nobody can work, it is 10 minutes x 7 team members + 7 team members x 5 minutes to gain focus on the tasks (instead of the promiscuous after skiing party), but if a guy use 5 minutes in the hallway to arrange who is picking up the kids after work, its only 10 minutes.
  • If you are talking on a mobile phone in the team room it’s 5 minutes, nothing if you are texting or writing a private mail.

Even though some of these disturbances coming out of missing team members are unavoidable the impact can be minimized if the scrum master is informed about the team members absent in advance or if everybody is updating a visual calendar.


So if you ever encounter big fluctuations on your burndown chart and sense you have the right team, but to many disturbances:

1)      Talk about the FATSO – make the team aware of the problem.

2)      Identify the FATSO – let the team identify the disturbances.

3)      Ducktape the FATO – let the team come up with ways to minimize the disturbances and keep on enforcing the rules – as a ScrumMaster you have to enforce the team’s suggestions, you have to be the one protecting the team – but now it is legitimized by the team – it is not just you telling the secretary to wait until the lunch back….it is the team.

And please don’t use the acronym FATSO – this one is mine