Ingredients

• The need to make a decision, as a rule of selection; the more impact the better
• Information that are complete and based on objective information
• The risk of making the wrong decision and potential consequences
• 1 random deadline
• 1 or more humans

Preparations

1. Take the human and make sure that the human will do its utter best to avoid pain in any form. Pain could include, not limiting to; physical pain, cold, grief, discomfort and so forth.[1]
2. After asserting that the human wants to avoid pain, make sure the wiring in the brain is working correctly and that it adjusts all external information it processes with memories, experiences and expectations based on fore mentioned.[2]
3. Realize that this recipe is based on generalized observations on various humans in various positions and that there are always examples to contradict the rule.

Directions

1. Take the need to make a decision and add it to the human
2. Stir gently so the need is fully absorbed by the human
3. Let the human rest for the period of time you think it needs to retrieve all information that influences the subject of the decision.[3]
4. After the human thinks it’s done, add the risk of making the wrong decision and the potential consequences. There is only a need to shake gently since the ingredient is usually quite quickly absorbed by the human.
5. Repeat step 3 after the brief moment of panic in the human has passed. This should trigger the urge you asserted in preparation step 1.
6. Explain the human the assertion you made in preparation step 2 and wait for 2 seconds.
7. Repeat step 3 after the second moment of panic in the human has passed.
8. Grab some popcorn and a coke and add the deadline to the human.
9. Again, repeat step 3 after the third moment of panic in the human has passed.
10. Listen to the decision of the human, at, or just over, the time of the deadline.
11. Ask the human to evaluate the context in which it made the decision, specifically why the specific decision has been made and how complete and objective the information was.
12. Serve the slightly-burned decision with the evaluation outcome on a warmed plate. A stronger wine, such as a crianza is a good complementary wine choice.

[2] Numerous researches on this subject are widely available and certain entertainers have made a profession out the fact, calling it illusion.

[3] While it’s fully acceptable to go do something else, this can be quite interesting to watch.

After walking through the tool and specifically the features that dealt with organising releases, projects, etc. I found the tool lacking on one part, like all the others I’ve seen and/or evaluated; My current client is an enterprise organisation that has hundreds of employees that work on the software development, due to control of the environment works with fixed date releases and has multiple programs and projects running simultaneously.

What I would like is a tool where I would be able to manage the interdependencies of programs, projects, applications, application chains, releases and preferably even resourcing of the overall development effort of the company.

I started to discuss this with my colleague and drew a very high level relationship diagram, dividing the relations into 3 groups;

1. Project organisation
   • A program has N projects
   • A project has N teams
   • A team has ~5 +/-2 core members
   • A team has 0:N members that are brought to the team for a single task
2. Chronological organisation
   • A Release consists of 1 to N projects
   • A project can consist of N project phases (prince2) and each phase can consist of N sprints
   • A project consists of N sprints
3. Technical organisation
   • An application chain (by lack of wording; the chain of applications, that together provide the business functionality) consists of N applications
   • An application can be part of N application chains
   • An application can be modified/build in 1:N projects
   • An application chain can be modified/build in 1:N projects

This was just the 5 second version on paper. When I got home I got interested in the relations and this is my initial view (it’s not 100% correct, since the relations between programs and other parts are bigger, but out of sake of simplicity I decided to model from the project part outwards):

• A program consists of 1-N project
• A project consists of 1-N teams
• A project can be part of 1-N releases
• A project consists of 1-N sprints
• A project can work on/influence 1-N application chains
• A project can work on/influence 1-N applications
• A project can have time-related dependencies on 1-N projects
• A team works on 1-N sprints, 1 at a time
• A team consists of 1-N core members (which can change over time)
• A team can have 1-N temporary members added and removed to execute single, specialised tasks
• A team works on/influences 1-N applications
• A team works on/influences 1-N application chains
• An application chain consists of N applications
• An application chain is deployed in 1-N releases
• An application chain is created/modified in 1-N sprints
• An application chain is worked on in 1-N sprints
• An application is deployed in 1-N releases
• An application is created/modified in 1-N sprints
• An application is worked on in 1-N sprints
• etc.

So far I have a lot of N:N relations and dependencies where teams can work on the same application for the same release. Not to mention all further dependencies for teams on sprints of other teams, etc.

What I need for my client is a tool where you can manage multiple product backlogs (for different businesses within the corporation), assign them to different programs and/or projects, model the dependencies on applications, projects, etc. Then have the dependencies calculated between the projects and applications, teams, resources, etc. And keep a history of everything for performance tracking purposes. All of this, just to generate a single release planning, get a simple management dashboard that gives the status of every project at any moment in time and shows problems with dependencies, resourcing, etc.

So far I haven’t found a single tool that is able to do this.

Which makes me wonder; how do parties like Nokia deal with this and do they deal with it? Do they even have things like project portfolio management implemented on board/director level to steer the company operationally on a consistent level that is in line with the company goals?

In other words; is Scrum really being used in the enterprise?

Somehow, in the Netherlands, it is fairly common that once a person becomes the best in his department (in operational sense), they get to lead the department.
Nobody has ever been able to explain that to me though; why does your best programmer/business analyst/etc. make a good manager?
The qualities that lead them to be the best in their field are mostly not the qualities that are required for a good manager.
Besides gaining a potentially bad manager you also lose your best operational person; sounds like a lose-lose situation to me.

An interesting note would be that a lot of the professionals that switch to a management position would rather keep doing the job they were doing before switching.
There are several reasons for people to switch from jobs they would actually like to do, and are good at, to something they perhaps like less. The following list is unordered and there are most probably research papers out there that cover this subject, giving an ordering (or more options)

• A new challenge
• Most people like to do something new from time to time, the problem is with switching to management; it’s usually quite hard to switch back.
• This is actually a good motivation for people to switch to a management position, as long as they get the opportunity to switch back when they don’t like it or aren’t as capable enough to fulfill the new role.
• Being able to do the job better then the current manager
• A common story is that of people thinking their manager lacks capacity and they would be more suited for the job.
• The motivation is not a bad motivation per se, but a lot of people quickly step into the same pitfalls as the manager they don’t deem competent.
• The money
• Managers earn more in the Netherlands then the best operational employee, I still haven’t figured out why.
• When I hear this as the motivator, I usually steer the conversation to a contractual conversation regarding the current position the employee is in. I consider it a big no-no for people to switch purely for the money.
• The status
• Somehow people still think that being a manager gives you a better social standing or status over being an operational employee.
• This, for me, is the absolute no-go reason for people to switch to a management position. The persons who have this as their “real reason” to switch usually have a tendency to control people top-down, with a fine ability to kill the motivation and spirit of a team for their own gains.
• The motivation to help people
• This is, again; for me, the real essence of being a manager. You put yourself on second place to the stakeholders (the company, the customer, the operational staff, etc.) interest.
• The people with this motive usually have the potential to quickly grow in their role and usually become part of the (short) list of good managers.

But how do you get to the “real” motivation of people when they say they want a management position? In my experience quite easy; just ask them, continue the conversation, ask the question another way and try to uncover some personal trades which are also good indicators. What makes the person tick? But besides asking, which will not always give the true answer, assessments and different questioning techniques have proved useful for me in the past.

Okay, so you have selected your manager, a motivated person with great skills to match. He got a 5 day course on management, a goal and now it is day 1 in his new role.
The manager holds a meeting where he is reintroducing himself in his new role, explaining the plans, his take on them and allowing the group to ask questions.
After that they start reading up on all the documents that are available and important now, shaking hands with their new colleagues from other departments.
Then it’s day 2, a deadline within a week, and the manager hears something isn’t going to be done on time. Panic strikes the new manager, if he doesn’t solve this one his colleagues and his own managers most probably will think poorly of him (in his own mind that is).
He mobilizes all related personnel and tells them that they have to solve the problem by working harder and, although he hates it, they might have to do some overtime as well.
After a long weekend of overtime and telling people what to do the manager subdues the crisis and life continues.
Within a month, your new manager is the manager he always resented himself and is deemed “not fit for the job” by his former peers.

My advice would be; don’t ever let a new manager start without clear goals, boundaries and coaching. Every manager (and person in general) learns by making mistakes, but coach them, give them constructive feedback and give the manager clear goals and boundaries.
This is where most managers get stuck, they never get the support they need to grow and learn, just because the senior managers are “too busy” and they were deemed “good for the job”, so they should be able to do it themselves. A 5 days training isn’t enough to make someone a good manager

Is there a moral to this story?
I doubt there is one, but if there is it would at least involve the following things;

• Be careful who you chose as a new manager
• Get the real motivation of the person who wants a manager position clear
• Use assessments to see if the potential manager has right personal traits for the job.
• Give your managers clear objectives and boundaries.
• Coach and give your managers guidance in their job, not just trainings.

And last but not least, try not to oversimplify everything to rational objects; managers are there to deal with people and they have the tendency to be complex.
Below is a small section from Mintzberg (“Strategy Safari”) which made me smile:

Five easy steps to destroying a rich culture

• Step 1: Manage the bottom line (as if you make money by managing money)
• Step 2: Make a plan for every action: no spontaneity please, no learning.
• Step 3: Move managers around to be certain they never get to know anything but management well (and kick the boss upstairs – better to manage a portofolio then a real business)
• Step 4: Always be objective, which means to treat people as objects (in particular, hire and fire employees the way you buy and sell machines – everything is a “portfolio”)
• Step 5: Do everything in five easy steps