Create the chart data

For this example I use the following data:

The Gantt Chart spans weekend dates. The fase Design takes two weeks, which makes the duration 12 days (Mo-Fr + weekend + Mo-Fr).

Manually create the chart

Create a horizontally stacked bar chart. The chart is empty at this point.

Insert first data range and vertical labels

Click on the 'select data' button.

• Add the start date of the fases and activities.
  The label is 'Startdate'. (Important, don't skip this one).
  The data range is indicated below in yellow.
• And the labels
  The data range is indicated below in orange.

The chart now looks like this:

There are a couple of problems here:

• The chart doesn't start at the correct start date
  Right click on the X-axis. Change the minimum value to 'fixed', value 40882.
  40882 is the decimal representation of Dec the 5th.
• The X-axis should have a weekly interval
  Right click on the X-axis. Change the primary unit to 'fixed', value 7.
• The Y-axis is reversed
  Right click on the Y-axis. Reverse the categories.

The chart now looks like this:

Add the Fase and Activity data ranges

Manually add both ranges (orange and yellow in the example below).

The chart now looks like this:

Notice that somehow the chart title 'Startdate' has disappeared.

Visually remove 'startdate' range

Delete the label 'Startdate' from Excel (make the cell empty) and set the bar color and border color to 'none'. 
Of course the Startdate bar and label are still present within the chart, there just invisible!

Optionally, beautify the Gantt chart

In the IT world such an iterative approach can also be beneficial. This Whitebook describes a successful project where the Lean Six Sigma DMAIC method was used to improve results by generating and analyzing data.

Case: data migration project

A client needed a new financial application due to changed legislation.  Also all data (20,000 customer cases) from the old application needed to be migrated to the new application. The project had a tough go-live date. The quality requirement was that at least 92% of the customer cases would be fault free migrated to the new application.
This project had the following challenges:

• The new table structure was different from the old structure. The data needed to be converted, an error-prone process.
• The new application was still under development.
• The calculated results from both applications could not easily be compared because of the functional changes.

So given all these challenges, how could we determine whether the data migration was successful and in what manner could we find a root cause when problems would arise?
Because of the many uncertainties an iterative approach was chosen with an automated process for comparing predicted and calculated outcomes. The approach was based on the Lean Six Sigma DMAIC methodology (Define, Measure, Analyze, Improve, Control).

Lean Six Sigma DMAIC

Introduction

Six Sigma is a quality improvement process. Six Sigma focuses mainly on reducing variability in production quality.

Lean is a method (almost a philosophy) focused on creating value in a process and reducing unnecessary process steps. Lean is largely derived from the Toyota Production System and now in use around the world in various companies (including Dell and Porsche) and also implemented in other types of processes (eg product, services and IT processes like software development project and project management).

In recent years, Lean and Six Sigma are increasingly combined into an integrated approach. Lean is initially used for large process improvements and Six Sigma to dot the i’s.

The core process within Six Sigma is the DMAIC  process. This is a variation on the well-known Deming Plan-Do-Check-Actualize cycle (though usually the process is followed only once and takes in between 1 and 5 months).

In the Lean Six Sigma DMAIC process every step within this process is supported by various ‘tools’. Think of statistical calculations, problem analysis, etc. In our data migration project we only used a limited set of Lean Six Sigma tools. By automation we speeded up the DMAIC process so that one DMAIC cycle could be finished within one day.

Define

Together with the client we determined how the quality of the data migration could be assessed. It was found that only testing the data migration itself was insufficient to guarantee the required outcome. The client obviously had no understanding of table structures and data types. Although our project scope was only to convert data, the project’s outcome could only be assessed by calculating the customer cases within the new application.

The client selected 200 client cases that were sufficiently representative for the entire contents of the database. These 200 cases were then manually calculated by the client. These results were delivered in a spreadsheet and we saved this data into the database as ‘predicted outcomes’.

Measure

It would have been too much work to manually compare results. We wouldn’t be able to meet the deadline. In addition there were too many changes in functionalities and data to rely on one single test iteration.

We needed an automated process to repeatedly compare the calculated and predicted outcomes. A migration framework which we could use repeatedly. The figure below shows this migration framework in green. In blue the newly developed application is visible. In grey the database from the old application is shown.

First a copy of the old production database was created. With a push of a button we could start the migration process:

1. The data in the old structure was translated to the new structure.
2. The new application was started.
3. The calculated results were then automatically compared with the results predicted by the client and the differences were reported.

Analysis

For the differences the root cause was investigated. Lean Six Sigma has many tools in the ‘Analyze’ step to interpret data and identify causes of problems. We made use of:

• Five times “why” question
  The “Five Times why” technique literally means that you ask the question “why is this wrong?” five times. Experience shows that the 5th time you should have found the real root cause.
• Pareto chart
  Classifying data into subgroups in order to exclude irrelevant data and focusing on problem areas. This helps to determine which 20% of the root causes are responsible for 80% of the problems.

The following root causes were found during the project:

• GIGO (Garbage In Garbage Out), the data in the old application was wrong (not previously discovered bug in the old application);
• an error occurred during the export of data from the old database to the copy database;
• the conversion of data from the old to the new structure went wrong;
• there was a bug in the new application;
• The new application worked as specified, but the specifications were wrong;
• The manually calculated predictions were wrong;
• the differences report itself was wrong.

In other words, there was no part of the data migration process without errors. From our experience with migration projects, we think that it is normal that errors occur in all parts of the process. We also think that it is unique that all these errors are found and dealt with.

For each problem identified a (possible) root cause and possible solution was determined. In some cases we had a clearcut problem and solution, in other cases we had nothing more than a hypothesis. By using the migration framework we could quickly perform experiments to test our hypotheses.

Improve

Solutions to problems found were implemented.

Control

Changes in software and predicted outcomes were secured by configuration management. The migration framework was restarted.

Results

The first two weeks of the project we created a design for the migration and set up the migration framework. Then several times a day we executed the migration framework.

The first migration results were far below the target of 92% error-free records. Less than 10% of the calculated results were correct. (See chart below).

By iterating the DMAIC process we could very quickly improve results. The data generated by the migration framework helped us searching for problems and root causes. Also we could afford to perform experiments. Rather than intensive and lengthy analysis we could quickly try out a small change by running the framework.

Ultimately the migration project was a great success:

• Completed within schedule;
• Quality better than required (99.2% instead of the required 92%, within a total of 20,000 cases that is a gain of 1,440 cases);
• During the migration project more than 30 bugs in the new application were found and resolved;
• We found errors in both the old application and database;
• Incorrect assumptions in the design of the new application were found and amended.

Other examples of DMAIC

DMAIC is a widely applicable approach for process improvement. In other types of processes this approach also demonstrated its value.

Helpdesk

A helpdesk organization notices that one specific client reports a lot more problems than other clients. After one year a structured process is implemented for root cause analysis and administration of these findings. Over time it becomes apparent that more than half of the reported problems are related to a lack of technical knowledge within the customer. A frequent consultancy session is implemented at which the reported problems and causes are discussed and specific steps are taken to build knowledge. As a result of this cycle of assessments and improvements the number of reported problems decreases significantly.

Availability

A client complains about the availability of the system. The statement is that 10% of the transactions fail. There is a lot of time spent on finding the root cause, but it is very difficult to find specific cases to analyze because there is no data recorded.

Gradually the application is modified to also measure and record the behavior of the application. It turns out that 3% of the transactions go wrong, where 0.1% of the cases have a root cause within the application and 2.9% a root cause within the clients infrastructure.

Data export

A financial organization provides a monthly export of financial data to another party. That export contains errors each month over and over again. The underlying financial calculations are very complex and changes to the software design lead to new errors each time. Then the approach is changed. The software is amended to store all intermediate results into the database to facilitate analysis. Root causes analysis of the problems, assisted by the additional data, helps determine the software changes that are needed . The next data export is fault free.

Software development

Examples of the DMAIC methodology can be found in various aspects of software development. Scrum has its roots in the Lean philosophy where the process of designing, making and testing of software is reduced to only those processes that create value (in this case working software).

Also, many best practices of “good software development” are based on the same underlying principles. An example is the incorporation of logging and tracing code into applications to measure it’s behavior, or test driven development by following a data driven approach to software quality.

Conclusion

When you do stop analyzing problems and when do you start proving your ideas and assumptions by measuring? Often we choose for analysis because we have confidence in our ability to create solutions by using our ‘brainpower’. Also we often think that analysis is more time effective than measuring and experimentation.

My experience is that in complex environments too much faith is put on analysis alone. If there are many uncertainties our mental models have very little predictive power. It is wiser to iteratively test theory with facts.

Building in measurements during the initial design of the system can greatly reduce time and costs. This also applies to applications or processes that are seemingly stable and predictable. The time and effort spend in building in monitoring will pay itself back when the application or processes do not perform as planned (which usually is the case).

References

• Six Sigma Wikipedia article (English)

After the presentations we had several Open Space sessions. The one I facilitated was themed ‘how to lower the agile adoption threshold?’. We had a very creative and productive session with lots of real life experiences and these are the results (in no specific order):

• Crisis
  ‘I’m sorry, everything else has failed, this is the only option left’.
• Stealth
  Starting working agile without asking permission first. When management finds out, it’s already created tangible results which makes adoption easier.
• Business Case/Time to market
  An agile project delivers fast so value is created early on (as compared to a V model approach where the project usually is delivered in whole at the end of the project).
• Pull the plug
  ‘If you’re not satisfied about the results you can pull the plug at any time’.
• Collaboration
  ‘You’ve tried everything else to get your people collaborating, this is the ultimate approach to accomplish that’.
• Pilot or experiment
  ‘So you’re trying something insane? That’s great, we’ve got the perfect matching crazy approach for that’.
• Learning/Uncertainty about specifications or outcome
  Address uncertainty head on. ‘This approach specializes in dealing with uncertainty and creates certainties fast through a process of learning and adapting’.
• Encapsulating
  Embed Scrum as the product delivery process within the PRINCE2 project management framework.  “Yes, we haven’t done this before, but you’re still in full control with all the processes you’re used to”.

Of course there is no recipe for lowering the adoption threshold that works every time. The agile adoption process is an agile process in itself

Anyhow, my two presentations are published on slideshare (see below). The third presentation by my colleague Peter Paul van de Beek can be found here.

Part 1:

Part 2:

We’ll be hosting this seminar on Thursday September the 15th at our Whitehorses head office in Nieuwegein, the Netherlands. It’s in Dutch and aimed at our customers or potential customers.

Hope to see you there!

I’m trying to point out that sometimes it’s better to stop theorizing and start proofing your assumptions by creating and measuring results.

Spending time on planning and reporting activities means that you and your team have less time available for ‘normal’ work. The problem is that you just can not ignore the need for control from your projects sponsor (or project board), but also can not fully give in to their needs because nothing would get done. It gets even more difficult when issues arise and the projects progress is stalled. The more uncertainties arise, the greater the need for control, the less time is available for getting work done.

The chart to the left shows the relation between time/effort spend on keeping control (horizontal) en time spend on production/progress (vertical).  The more time is spend on control, the less time becomes available for getting things done. (With ‘time spend’ I mean time spend by both project manager and team members).

The problem is that there is no fixed formula to determine the sweet spot between control and progress. It all depends on the projects environment and also has a relationship with the project managers personality.

Some action-oriented junior project managers tend to focus on getting things done and ignore the project board’s needs (point 1). If the project is small and predictable this shouldn’t have to be a problem. It becomes a matter of trust (a believe that things are going to be alright even though the progress isn’t made visible by plans and reports).
When the project becomes more complex, when the time between conception and delivery becomes too long, trust doesn’t cut it anymore and more reporting is demanded. This even might result in a killed project even though real progress was made.

Sometimes a junior project manager is more focused on methods and less on results (point 2). I’ve seen this happen on a project where PRINCE2 was followed to the letter, creating elaborate progress reports, while the actual project’s progress was severely constrained.

In my personal opinion there is no sweet spot in the middle (point 3). I believe that the project manager should continuously work on the projects effectiveness towards point 4,  reducing overhead and increasing the amount of time spend on creating solutions, while still meeting the project board’s demand for control.

Though there is no fixed formula I have a couple of tips.

Fit for purpose

The projects control/progress balance isn’t fixed. It’s normal that the need for control is higher at the project start, end and during phase transitions. Also it’s quite normal for projects to have easy and difficult times. It is wise to alter the amount of reporting when needed. Do not stick to the initial communication plan but discuss the reporting needs and change when necessary.

Delegate tasks

The number of teams and team leads should not only be determined by ‘span of control’. It is wise to determine the amount of attention the project board needs and determine the amount of time the project manager has left for operational project management. If there isn’t enough time to manage the project properly, hire an additional team lead or delegate more tasks without adding additional management.

Build trust

The greater the trust, the less need for reporting and accountability. An excellent manner to create trust is to deliver the project results in increments (Scrum) to demonstrate actual progress and keep progress transparent (lessons learned, burndown charts, velocity).

Synchronize operational and strategic controls

It is smart to synchronize the need for operational control (by the project management team) and strategic control (by the project board) so that both needs are based on the same data. I’ve often seen that the project board reporting demands are difficult to implement because these demands need additional administration. It is wise to discuss the reporting needs with the project board and decide on a common definition of status and progress that suits both needs. Also here I’ve some excellent experiences with some of the Scrum reports (especially project process based on velocity).

Informal progress reports

Another smart thing to do is to discuss the project status and progress informally and on a regular basis. In my experience the project board has much more questions than can be answered within a document or even during a project board meeting. This also works two ways, it reduces the need for an elaborate progress report (thus saves time) but also increases the project ownership. That is very important because an involved project board increases the chance on success substantially.

Here’s the Excel 2007 template, have fun!

The Toyota philosophy knows the concept of Poka-yoke, ‘mistake proofing a device by preventing, correcting, or drawing attention to human errors as they occur’. Poka-yoke is a means of building quality into the device since it prevents making mistakes. It doesn’t only have an effect downstream. In combination with ‘stop the line’ (stopping production and finding the root cause of defects) this also works upstream.

Maria Montessori, the inventor of the Montessori Method (child education), uses the same concept. The Montessori Material has a build in ‘control of error’. The children work with the material but don’t need the teachers assistance to check their own work. The check is build in.

Agile IT knows concepts like continuous integration, test automation and tracing and logging to build quality within the development process and within the IT solution. Guessing whether the solution works is not necessary, nor a lengthy manual testing phase. You get instant feedback on the quality of the solution. (Of course test automation does have it’s price). When the solution has gone into production, build in tracing and logging helps locating and fixing problems.

All three cases share the concept of ‘quality build in’, but that’s not the true connection. The true advantage of ‘quality build in’ lies in increasing the learning capacity.

The effectiveness of the learning process is greatly influenced by the feedback cycle. We need feedback to determine if what we do is right. The shorter the feedback cycle, the better. Building quality into the process and product shortens the feedback cycle substantially.

The true connection between the Montessori Method, The Toyota Way and Agile IT is that all three are learning processes.

How great leaders inspire action

(presentation by Simon Sinek, TEDxPuget Sound, Sep 2009)

A great and inspiring presentation about leadership. If you think this presentation is only about marketing and selling stuff, you’re missing the point. Simon explains that people are motivated by the ‘Why‘, not the ‘How’ or ‘What’. I fully agree. As a project manager (or any kind of manager) it’s much more effective to explain people the project’s purpose (the why) and let them figure out what to do and how to do it, in stead of micromanaging their activities.

The loss of wisdom

(presentation by Barry Schwartz, TED2009, Feb 2009)

Another great presentation. This one is about how we all try to get a grip on things by implementing rules and incentives. Barry explains that rules and incentives only can do so much, it’s never seems to be sufficient and at some point rules and incentives create more problems then resolve problems. Rules and incentives are no substitute for practical wisdom.
In business processes and project management, methods and procedures (rules) are only useful as a guideline, they can not replace common sense and practical wisdom. We also know the effects of ill chosen incentives, for instance department level bonuses that aim to make the departments more efficient, but create problems on the company level (in lean terminology: sub-optimization).

All models are wrong but some are useful.

The problem with complexity is that it creates unpredictability. We do not like unpredictability because both customer and supplier want to have a successful business case and need to know in advance whether the project is going to deliver within the boundaries as defined by the business case.

The classical, non agile, approach to unpredictability is to do more analysis upfront and follow a rigid change management method, usually combined with a large requirements document, contract and project plan. The assumption is that by doing a lot of thinking most of the potential problems can be addressed and that the few other loose ends can be managed effectively by change management.

I’m afraid this assumption is wrong. Not only because we continuously underestimate the number of changes during the project and are very poor in predicting the future. The larger problem is that the contract has become the project’s goal, not the underlying business case. This potentially creates a severe misalignment between customer and supplier.

Every time something unexpected happens there are two points of view.

The customer reasons from his needs, towards an ideal situation. From that point of view it is likely that changes are needed. Changes are considered necessary and an opportunity to create a better solution.

The supplier reasons from the contract (deal). Changes are considered a bad thing. It means that all the thinking didn’t create the desired results (a smooth and predictable project process). In most organisations projects are considered to be successful if the project is finished within the set boundaries of time, costs and scope (quality). It means that someone has to tell upper management that things do not go according to plan. It is in the interest of the project management team to reduce the amount of changes, to steer the project towards the boundaries set by the contract.

Though this misalignment happens in lots of projects, I do not think it is that difficult to turn the situation around. It requires an other mindset.

First you need to make clear within the supplier’s organisation that a project is successful when the underlying business case is successful. This means that time, scope and costs may change, it does not necessarily cause a problem.

Secondly I would advise the following action plan for each potential change:

• Determine the ideal situation
  Talk to the customer and ask for his needs. (In fact, don’t wait for his initiative and make some suggestions yourself).

• Look at the contract
  Only then determine what has been agreed upon by contract or project plan and determine the gap between deal and ideal.

• Change management
  Determine the right course of action. This can be something operational (managed by the project manager) or something on the project board level or both.

Thirdly, it is also wise to repeat this process frequently, even when there are no problems. It is an excellent process to keep the project healthy, to prevent unspoken assumptions and expectations. It also is a nice fit to the concept of learning and improving.

Of course you agile project managers already know all of this.
For you guys I have an additional suggestion. This process can also be applied to any situation where people need to work or live together. Between you and your team, between the team and Product Owner and yes, even at home between you and your partner.

The two largest project killers

Comments are enabled again, so please don't hesitate to ask questions, to discuss what you think is wrong or can be improved, to share your knowledge and experiences.

The world is complex, a dialog is an opportunity to learn and I welcome that opportunity! 

I’m not a psychologist and do not pretend to have a scientific prove for my statement that we all are rationalizing our beliefs. It is just my belief based on my personal experiences over the last 20 years.

Rationalization is what I used to do when I started my career. I thought I was very talented in logic and reasoning. I thought I was an excellent analyst and designer. That changed when my design decisions were challenged and I discovered that I couldn’t fully explain my choices. In the end it all came down to my personal believes about what was right and what wasn’t.  It wasn’t that my designs were flawed, it was that I fooled myself thinking that it was all logic, where in fact I was constructing a layer of logic around my personal beliefs.

The trouble with rationalization is that it makes your process of decision making less transparent, to others and to yourself. It creates friction in discussions with other people.  Time is wasted in defending unspoken assumptions and believes, while the other person cannot fully follow your logic and tries to determine why.

Rationalization also makes it difficult when to trust your intuition, to trust your gut. I believe using your intuition can be very important for effective decision making, especially in complex environments. But you need to know your mental state of mind to determine if you can trust your gut. Rationalization makes it difficult to determine your state of mind, especially where you have fears.

So here are my two rules to determine when to trust your gut:

1. Trust your gut when you are relaxed, when things are smooth.
   Go with the flow.
2. Do not trust your gut when you feel fear or pressure.
   Stop and think. Examine your initial instinctive response. Usually the right course of action lies in the opposite direction.

You can also apply both rules to other people. Especially in tense situations people have a habit of rationalizing their fears which leads to bad decision making. The problem in these situations is that most people won’t admit having fears, which forces you to discuss their flawed logic. The solution would be to create an environment with an open and fault tolerant culture.

According to Wiki, an anti-pattern ‘is a general reusable solution to a commonly occurring problem, but is ineffective and/or counterproductive in practice‘. Wiki contains a nice list of anti-patterns but IMHO there should be a ‘Business & IT’ category with some additional anti-patterns.

IT arrogance, ‘we do the analysis, we know what the business needs’

This anti-pattern usually starts emerging after a couple of failed projects where the business people had trouble specifying their needs. To prevent changing requirements, more and more emphasis is placed on analysis, change management and planning. Sadly, during that time the responsibility for analysis shifts from the business people to the IT people. The business is still accountable for determining requirements, but most of the actual work is done by the IT people.  As a consequence the business is less and less involved in the change process and also is even less skilled in determining their needs.

The end-state of this pattern is that the IT department has little faith in it’s customers capabilities to define requirements and doesn’t even try to collaborate. I’ve seen this a couple of times. A large and complex project is conducted with no customer involvement at all, because the IT people think they know what’s best.

Of course these project have there share of failures, but somehow these failures reinforce the notion that more analysis is required and that it should be done by IT specialists. Probably because each customer interaction leads to more uncertainties and not less, whilst additional analysis documents (seems to) provide work packages that can be planned and controlled.

Sales dominance, ‘we set the pace because IT is incapable to do so’

Sometimes another Business & IT anti-pattern emerges within sales-dominated organisations where IT has an important role in creating a solution. Time to market is critical in selling solutions and can make the difference between sale or no-sale. Some organisations have a culture where refusing a deal is not an option, where conversations only go one way; ‘how can we make this happen? ‘. This creates pressure on the IT team to accept projects with little chance of success within the given time frame or budget.

The result is that during pre-sales phase the IT team tries to claim more time in order to create a solution and that sales tries to limit the time (and budget) in order to make the deal. Of course sales is always right, so the project is started anyhow. The IT team does not want to fail and tries to deliver on time and within budget (but not without some personal sacrifices). Due to the ’Halo‘ effect and reverse halo effect, each time IT delivers on time it’s the sales team that was right, each time IT fails it’s their fault.

The end-state of this pattern is that a pre-sales teams with technical specialists is created which determine costs and time for each bid. This pre-sales team answers to the sales team. The IT team ‘only’ has to create the solution once the bid is accepted. The anti-pattern is reinforced each time something goes wrong during the project because ‘solutions’ for IT problems are implemented within the pre-sales team (for example by transferring experts from IT to pre-sales).

Anti anti-pattern approach

Both anti-patterns have in common that a stronger party dominates a weaker party and that this dominance is made even stronger. In the short term this might resolve some immediate issues, in the longer term it is a bad thing. You wouldn’t want to have such a relationship in your private life, would you?  By making one party stronger then the other party, the weaker party becomes even more weak. An unhealthy situation at the start deteriorates and becomes even more unhealthy.

A more effective approach would be to make the weaker party stronger until the collaboration becomes balanced and healthy again. It is the more difficult road to follow but leads to better results.

You can find more interisting videos at the RSA organization. I’ve added my favourites to the ‘Cool Videos’ sidebar.

Principle 1. Aim for the 70-percent solution
It’s better to decide and act fast then to create a perfect plan that’s too late.

Principle 4. Orient to speed and complexity
The combat environment changes quickly and chaotically. The ability to react quickly is the most important competence.

Principle 6. Build authority-on-demand into the hierarchy
This means that marines have the authority to make their own decisions when management guidance isn’t at hand. In the field teams are very self-organizing and self-supporting.

Principle 7. Focus on the small team
The Marines are very aware that the real stuff is done by the combat teams. The Marines do anything possible to empower these teams.

Principle 12. Cross train
Versatile managers are created by running through different jobs. That’s more important than the loss of efficiency.

Principle 13. Manage by state and intent
Don’t tell people what to do. Tell them what you want and why.

Principle 15. Reward failure
People whom don’t make failures don’t take risks and accomplish nothing.

Principle 17. Glorify the lower levels of the organization
The real heroes are the marines that make it happen, not the management.

Principle 18. Demand to be questioned
No one knows ‘all’. It’s healthy to criticize and discuss other points of view.

Principle 25. Keep plans simple and flexible.
It’s better to have a few simple options that can be adapted to changing situations then to try to make specific plans for every contingency.

Most of the principles I didn’t mention above are about leadership, which also is extremely important in any management position, but aren’t part of the Scrum or PRINCE2 methods. So I skipped that for now. Anyhow, I think almost all 30 management principles are also applicable to a business context. All in all, a great book and a recommended read!

Basically VSM works like this:

1. Determine the definition of Customer Value.
   Define what product or service is/should be delivered and determine its properties.
   Do this from the customer point of view.
2. Define the current VSM.
   Draw the entire process including both the flow of products, information and time.
3. Determine ‘waste’ (or muda in Japanese) and draw the future VSM.
   Each process step that doesn’t add Customer Value is waste. Each step that doesn’t add value but is necessary in order to create value is ‘necessary waste’. Each step that doesn’t add value and also isn’t necessary is completely redundant.
4. Optimize the current process and repeat.
   Eliminate redundant steps, optimize ‘necessary waste’.

The most difficult and critical part in VSM is firstly determining the definition of Customer Value and secondly determining ‘necessary waste’. Especially in change processes it is of the essence that everyone participating in the change is aware of it’s goals. I’ve seen too often that change processes (or projects) are sub-optimized because project-specific processes or goals have taken precedence over the goal the change process initially was created for.

Let me give you an example with an average ICT project.

Customer Value

What is the Customer Value that the project creates?

Is it design documentation, is it software? Or is it software as an enabler for business processes? I think it is none of the above. It should be software as a business enabler, but not at all costs or without any limit on delivery date.
The projects Customer Value is defined by the projects Business Case (which should contain the definition of the Customer Value, but also costs, benefits, time, etc).

Necessary waste

What activities or project products can be considered to be necessary waste?

Design documentation could be considered necessary waste. The design itself does not create value. It does not enable business processes directly, software does. Some value might be found when considering software maintenance.  If maintenance isn’t possible without documentation then there is some value there. If the software can not be maintained properly then, in time, the software does not enable business processes anymore. The thing is that other solutions exists that enable software maintenance. An automated test harness for example is a better approach.
Is documentation necessary  for knowledge transfer between customer and programmer? In short, the answer is no. Knowledge transfer on paper is very ineffective. Between customer and created software at least 75% of knowledge is lost. Just discussing the requirements and features and building mock ups are far better methods for knowledge transfer.

How about project management? Does giving orders and creating plans create value?
Project management is definitely waste.  It is necessary, but clearly it’s an activity that should be made as ‘lean’ as possible. My personal goal as a project manager is to make no decisions and generally do nothing at all. Why? Because this is only possible when the project runs perfectly, when the goal is clear, the processes are effective and everyone knows what to do. Here’s where the lean Scrum process adds value. Also PRINCE2 supports this goal with management by exception and with tolerances that enable delegation of tasks and responsibilities.

ICT project VSM

So how would a current and future ICT project VSM look like?
Of course that map would be completely different for each project. The interesting part is which activities are considered necessary waste and what optimizations are proposed. VSM is useful in making the definition of Customer Value transparent and applying that definition to each step in the change process. The discussions that arise should result in process improvements, in making the change process more effective. With an iterative approach discussing the VSM could be done after each iteration, so that change process improvement becomes a natural thing within the change process. It also fits perfectly within the Scrum and PRINCE2 methods (‘Sprint Retrospective’ and ‘Lessons Learned’ respectively).

In my opinion Scrum offers a number of advantages in maintenance:

• reliable financial forecasts, both for customer and supplier;
• reduced overhead in change management procedures and overall management costs;
• self organizing team with a lot of knowledge of the customers domain (which is crucial with a small team);
• fast delivery;
• last but not least; dealing effectively with unpredictability.

Actually, the advantages from a project point of view are also fully applicable to maintenance.

Strangely it seems that people revert to old habits. Scrum is applauded for the project’s success, but now ‘things can go back to normal’. I would argue that unpredictability still remains in the maintenance phase of the product’s lifecycle. I think this is where it goes wrong. People think that now the project is finished the problems are resolved and changes are small and can be managed effectively and cost friendly in the old manner.
That wouldn’t be my prediction

Jane wants some coffee. Pete agrees to get some. Both use PRINCE2 without being aware of it.

Pete	Jane
Hi Jane, how are you?	Hi Pete
	Actually, I’m dying for a cup of coffee. Can you get me some? (Project mandate)
Sure no problem.
How do you like your coffee?	Large with non-fat milk please. No sugar. (Product Description)
How much money do you want to spend? I can get some down the hall from the machine or do you want StarBucks coffee?	If you don’t mind I prefer StarBucks. That’s more expensive but I like it better. You can get some for yourself too. Here’s the money. (Business Case)
Okay, large, non-fat, no sugar. I’ll be back in 10 minutes if everything goes to plan. (Project Plan)	Thanks! (Plan authorized)
See you later! (Execute Work Package)
… 5 minutes later a call from Pete …
Hi Jane, there’s a large queue here, it will take another 10 minutes. (Exception + Exception Plan)	Guess I have to wait a bit longer. Thanks for the update. (Exception Plan authorized)
… 8 minutes later a call from Pete …
Hi Jane, I’m on my way now. (Highlight Report)	Great!
… 2 minutes later Pete arrives …
Here’s your coffee and change and a donut. (Deliver a Work Package)	A donut? (Quality Inspection)
Yeah, you looked a bit hungry too.	Well, that’s really nice of you but I’m on a diet. This is not what I asked you for. (Off spec)
Sorry about that, I’ll eat it myself, here’s the money.	I appreciate the effort but next time please ask me first. (Lessons Learned) Thanks for the coffee! (Closing a Project)

]]> http://www.borselaer.org/index.php/2010/03/getting-a-cup-of-coffee-with-prince2/feed/ 0 http://www.borselaer.org/index.php/2010/03/presentation-agile-systeemontwikkeling-met-scrum-dutch/ http://www.borselaer.org/index.php/2010/03/presentation-agile-systeemontwikkeling-met-scrum-dutch/#comments Sun, 07 Mar 2010 11:50:08 +0000 Martin http://www.borselaer.org/?p=368 Last Thursday I gave a presentation about 'Agile system development with Scrum' to an audience of project managers, business consultants and more technically involved IT people.

My main purpose was to provoke a 'paradigm change' since most people in the audience aren't involved in agile system development currently. So a large part of my presentation was about predictability and dealing with changes and why Scrum is a better approach to this then the traditional waterfall method. I remember clearly the first time I heard about Scrum a couple of years ago. My first reaction was that it couldn't work and only after a couple weeks I began to understand the strengths of the agile way of thinking.

We had some great discussions Thursday and I think I've been able to 'turn' some people. Mission accomplished

Why combining PRINCE2 with Scrum?

I think Scrum is great and we all should use the Scrum approach whenever possible. The ‘whenever possible’ bit does concern me. I’m not at all happy with the ‘implement Scrum as cleanly as possible and work from there’ approach. Sometimes the gap between reality and the ideal agile approach is too wide to bridge, which results in a failed project and frustrated people. It isn’t healthy nor productive and just isn’t necessary. (And also isn’t agile in itself).

I’ve learned by experience that there’s only so much change people can endure. A little bit of radical change so now and then is acceptable and healthy, but not too much in the same time frame and certainly some time is needed to get accustomed to the new situation. Implementing lean is also a lean process, an iterative process of change, learn and adapt.

So the first reason why I think PRINCE2 and Scrum combine very well is because people are accustomed to PRINCE2 and a PRINCE2 project management wrapper around Scrum makes the Scrum implementation much easier.
The second reason is because I think the PRINCE2/Scrum combination does add value to the customer.

That said, how in earth can a ‘heavyweight’ method like PRINCE2 be combined with a lightweight Scrum approach?

PRINCE2 is more agile than you think

PRINCE2 doesn’t have a great reputation in the agile world. PRINCE2 is anti-agile and applying PRINCE2 makes you an evil ‘command and control’ type of manager.

PRINCE2 actually is intended to be scaled down to the project’s context. The manual explicitly states that ‘right-sizing PRINCE2 is a critical success factor’. The 2005 version of the PRINCE2 manual doesn’t explain right-sizing PRINCE2 very well though. It’s written in a very formal style and (almost) doesn’t mention the choices you can make. This is where the bad reputation comes from. If you implement PRINCE2 straight from the book, usually very heavyweight, failure is imminent.

This all has changed with the 2009 version. PRINCE2 principles are introduced to explain what’s really important. The implementation of these principles is highly adoptable. The manual also clearly explains that PRINCE2 can be merged with other methods. This is because PRINCE2 is only a project management framework, it says nothing about delivery methods. PRINCE2 also isn’t waterfall. The word even doesn’t exist in the manual.

Positioning Scrum within the PRINCE2 framework

The Scrum process is all about delivery. Fast and effective delivery is key. Within PRINCE2 the delivery process is a black box. PRINCE2 is all about managing the project’s process.

This makes Scrum a natural fit to the PRINCE2 ‘Managing Product Delivery’ process. This also makes PRINCE2 the project management wrapper around Scrum. I think this is a great combination and I’ll explain this below with some real life problems we all have with Scrum. I’ll also explain some PRINCE2 implementation choices which are needed with the PRINCE2/Scrum combo.

PRINCE2 solutions to Scrum problems

The Product Owner ‘superhuman’

The Product Owner is the one and only person representing the customer. This person also represents all stakeholders. Frankly, it’s very, very hard for anyone to meet all the requirements for this job. It’s clearly one the most common problems we have with Scrum. There are some solutions, like the ‘proxy’ Product Owner, but PRINCE2 has a much more adult and proven approach; the project board.

The project board knows three roles: Executive (accountable for the business case), Senior Supplier (accountable for delivery), Senior User (represents the users, accountable for the product’s requirements). Usually the Senior User is represented by a user team on an operational level.

It’s very easy to split up the Product Owner’s responsibilities between the Project Board’s roles, it doesn’t change the Scrum process. It actually adds value because Scrum doesn’t cope well with customer/supplier projects where the supplier takes commercial risks.  That’s because the supplier isn’t represented in the Scrum process.

The project board doesn’t make a project more heavy weight. It might seem so but in real life you still have the same talks with the executives involved even when a project board doesn’t exist. The project board actually makes your life as a project manager easier because in PRINCE2 the project board is accountable for the project’s success, not you. This makes the board your ally in removing impediments, also because the board members usually have the authority to do so.

The CSM: responsible for the Scrum process, not for results

Most people don’t seem to know that a PRINCE2 PM is not accountable to the project’s outcome, the Project Board is. That’s why the project plan must be approved by the Project Board, that’s why all important decisions are made by the Project Board. PRINCE2 has introduced the concept of tolerances to make the project’s process more independent (management by exception). The fact remains that the PM’s main duty is managing the project’s process. That’s not unlike Scrum, where the CSM also isn’t accountable to the project’s outcome.

In my view both the PM and CSM have the same challenges and pitfalls. Managing the process and creating strong teams. The difference is that a CSM hasn’t authority over the team, the PM does. Sometimes problems arise in Scrum projects when the CSM exceeds his/her authority when trying to impose changes in the team’s process. Sometime problems arise in non-Scrum projects when the PM rules by ‘command and control’. Sometimes problems arise when the customer isn’t used to a self-managing team and expects more from a CSM then Scrum allowes.

In all cases it isn’t easy to create a focused and self managing team. IMHO being a PM doesn’t impediment the co-existence of a self managing team. There always exists boundaries of self-determination and a PM with the proper attitude and management style also is capable in creating an effective team. A difference is that the PM does have the authority to impose changes when necessary.

Of course in the combination PRINCE2 and Scrum it also isn’t a problem at all to have a PM with one or more Scrum teams, each having a CSM.

The project startup

There exists different views how to implement a Scrum project, especially the startup phase.

One approach is to ‘just start’, and manage the implementation impediments along the way. This shouldn’t be a problem, because impediments are expected and the iterative Scrum approach with Sprint Retrospectives is an excellent way of learning and adapting.

The problem I have with this is that during the first few Sprints a lot of impediments are to be encountered. I find it difficult gaining trust and confidence in a Scrum approach when a lot of ‘problems’ occur. In my experience managing expectations helps but isn’t enough. I prefer a preparation phase, sometimes called a ‘Sprint zero’.

Within PRINCE2 the preparation phase is an essential part of the method. The processes ‘Starting up a project’ and ‘Initiating a project’ are used to get approval to starting the project, based on a common understanding of the project’s business case, methods and procedures and also is important to get commitment from the people involved. This preparation phase doesn’t have to be heavyweight and can be executed quickly.

Trust

A traditional sequential approach offers confidence by predicting a delivery date, costs or a fixed scope. We all know that that won’t happen, but a commitment is given which is something a customer likes. Scrum doesn’t offer this level of commitment. There exists more uncertainties. Fixed date yes, but no fixed scope. Only after some Sprints the outcome becomes somewhat more predictable. It is something the customer has to live with. I’m not saying that this is wrong. I’m only saying that it’s difficult for a customer.

Scrum has some instruments that help, like velocity or the burndown chart. It still is an alien approach to most people, certainly during the first few Sprints.

I’ve experienced that a PRINCE2 wrapper around Scrum helps a lot in gaining trust, especially before or during startup. PRINCE2 is well known, the customer is accustomed to the instruments that PRINCE2 offers and the PRINCE2 process ‘Directing a project’ is a more explicit means to influence the project’s progress than the Product Owner tasks as described in Scrum.

Product Backlog

A problem with the Product Backlog is keeping overview. The list is very dynamic and contains all kinds of User Stories: small/large, different priorities, different business domains or processes. Also sometimes interdependencies exists (which shouldn’t but it happens anyhow).

I can’t help notice that the PRINCE2 technique called Product Breakdown Structure is useful in creating some order in the chaos. It’s not unlike other solutions I’ve seen explained in blogs.

Risks

Within Scrum there’s no explicit method for managing risks. Partly it isn’t a problem because a lot of risks are managed implicitly by delivering in short intervals. Each Sprint is a checkpoint in which both solution and process are discussed and improved. This is a very effective approach for problems inside the sphere of influence of the project.

In my opinion there is a problem with risks that lie outside of the team. The CSM is reponsible for managing these problems (impediments) but he/she has limited authority. Also it isn’t an pro-active aproach to problems. Problems should be managed when they are still risks. (Although a valid risk-countermeasure is ‘do nothing’, which can work with an agile approach).

The PRINCE2 approach with explicit riskmanagement and an active involvement from the project board to me works very well. It shouldn’t cost too much time and effort and can add a lot of value. The PM (CSM) can deal with risks/problems within the team’s process, the project board can deal with the other risks and problems.

Agile PRINCE2 implementation

There’s more to making PRINCE2 agile then described above.

Agile business case and Product Definitions

PRINCE2 nowhere states that scope is fixed or that the project’s business case is fixed. It’s perfectly allright working with an evolving business case. (Though most people seem to think otherwise, maybe because most people think PRINCE2 equals waterfall). There is no impediment here combining PRINCE2 and Scrum.
The agile approach is to start with a high-level business case and amend this business case after each Sprint. In addition to this you can also start with a single high-level product definition (like a Vision statement). For single products I use Scrum User Stories in stead of product definitions. The PRINCE2 format for a product definition is much more comprehensive, but most information is about the process of creating, validating and accepting the product. With Scrum/PRINCE2 it would be useless repeating this information over and over again in each User Story because it’s the same for each story. (Though in special cases the PRINCE2 format might be handy).

Tolerances

The PRINCE2 management approach is to manage ‘by exception’. At the start of the project specific boundaries (tolerances) are established in which the team team can move freely. The project board only becomes involved when there is danger that the project moves outside of these boundaries. This works very well with an agile approach. The tolerances for money and time can be fixed (no tolerance) where the tolerance on scope can be used to establish a minimal scope to be delivered, for instance all User Stories with a ‘Must Have’ Business Value.

Reporting

The new PRINCE2 2009 manual states explictely that templates other then the official PRINCE2 ones can be used for reporting, as long as you report what is important to your customer.  It is a good idea to use specific Scrum information like release planning based on Velocity and Product Backlog, Lessons Learned based on Sprint Retrospectives.

Sprints or Stages

Since Scrum iterations (Sprints) follow each other closely, there is no time to get a formal approval from the Project Board to start the next Sprint. PRINCE2 states that approval is mandatory for each next project stage. This really isn’t a problem, there are a couple of solutions.

You can execute several ‘technical stages’ (Sprints) within one management stage and in this way ask approval for several Sprints at once. My favorite solution is to agree on an implicit approval for the next stage. I use the Sprint Planning meeting as an informal approval for the next stage. The Sprint Backlog is my stage plan. During the first days of the next Sprint I deliver a stage report, describing the results of the previous Sprint and the consequences for the release planning. Also tolerances are useful here. When the Sprint results or release planning are within the boundaries approval can be obtained automatically.

Lessons Learned

Lessons Learned are essential for any effective project. This is the case with both PRINCE2 and Scrum. In a traditional approach lessons learned usually aren’t. That’s because when lessons are only discussed when the project is finished, it is of no use to the project anymore. There is a large difference when compared to Scrum. The project’s process for each Sprint remains basically the same, you have the same people on the team, so you have lots of opportunities to try out solutions and learn. I also make this process of learning explicit to the customer by reporting the Sprint Retrospective results in each stage report.

Conclusion

Scrum is a highly effective approach for getting results. It does take a lot of thinking, knowledge and wisdom to make the right choices when implementing Scrum. Implementing ‘Scrum by the book’ in my opinion won’t always work, because there are too many problems to resolve, the change is too large. The problem with changes is that you can’t change instantly to an ideal. Changes are done from reality and in small steps.

In the real world PRINCE2 complements Scrum very well. The team works with Scrum, the project manager largely works with PRINCE2. Both methods are compatible. The real advantage of the combination is that a PRINCE2 layer around Scrum makes it much easier for a lot of organisations to move to an agile approach and more successful project outcome.

One warning though. In 1.5 hours it isn't possible to explain all the details of both PRINCE2 and Scrum, so I didn't. I told a little bit about Scrum and almost nothing about PRINCE2. The presentation was mostly about the specifics of the combination. In other words, some knowledge on PRINCE2 and Scrum is assumed.

Gemba means ‘the place truth can be found’.
Kaikaku means ‘radical improvement’.
Kaizen means ‘gradual improvement’.

Projects are all about change. Usually we’re talking about a large change (Kaikaku). That’s why it’s a project: a temporary organization with a specific goal.

You might also argue that an agile project approach also has some Kaizen characteristics: small iterations, learning and improving. Still, when the project is finished, there should be a large improvement in comparison to the pre-project situation.

So what happened to Gemba? Where’s Gemba within projects?

First of all, I think there’s Gemba in learning by doing. Analysis is only theory. Truth is found when the software becomes available. Of course everyone involved in ‘Lean Thinking’ or agile practices knows this. No news here.

There’s another level of Gemba though that’s equally important from a change point of view. That’s the current state of things, the reality as we know it.  After all, if we’re talking about change than there is a current state thats needs to be transformed to a  future state. It does not suffice only to think about the future state. You do need to know the current state.

This is how lean is implemented. You need to know the future (ideal lean) state, but you also need to know the current state. Initially that current state isn’t lean at all. Then you decide on a course of action. Usually an iterative process of Kaikaku followed by Kaizen. Of course the ideal state is constantly changing, so lean is more of a process than a state.

So what’s the relevance to project management?

When it comes to the project approach I think it is important to have a vision based on the ideal state, for instance the Scrum process. Ideally the project should be based on Scrum.

However, Gemba is also found in the current state of the organisation. Here it becomes important to determine the readiness for an ideal approach. Usually, in most cases the organisation is only partially ready, there are some issues. That’s normal, most organisations are not lean.

Implementing a fully lean approach such as ‘Scrum by the book’ possibly fails because there are too many impediments. Also I don’t  think the leanliness of the project’s process is that important, what matters is that the project’s process is lean enough to do the job. Preferably very lean, but less lean than ideal might also work, or might even be better. Anyhow, implementing a project without the Gemba of the current state isn’t lean in my book.

I’ll try to post an English translation on this blog somewhere next week.

I'll share my experiences combining PRINCE2 with Scrum and explain what makes this combination very successful. Also, we have reserved plenty of time for questions and discussions, so hopefully there is a lot of knowledge to be shared and 'lessons to be learned'.

For more details please see our Whitehorses website or the LinkedIn event.

• The Executive is accountable for the project's Business Case.
• The Senior User represents the people whom will use the product. He is accountable that the product meets the needs of these people.
• The Senior Supplier represents the people whom will create the product. He is accountable for the quality of the product.

The project manager is NOT accountable for the project's success. He is only accountable for managing the project's process. His job is to execute the plan agreed on by the Project Board. As long as the project manager does not exceed his authority the Project Board is very helpful. Why?

• Accountability is not transferable It just isn't so. You might assign other people within the project. The fact remains that if something goes wrong, the people which are accountable bare the consequences. Not the project manager but his boss, not the team but the supplier's director.
• Accountability creates responsibility The project manager executes the project plan as approved by the Project Board. If something goes wrong the Project Board has the resposibility and also the 'power' to help out. Problems shouldn't be the project manager's problem. In fact they are the Project Board's problems, because these people are accountable. A bit of an oversimplification maybe, the project manager still has problems, but the principle is sound and very effective.
• The Project Board process is mostly an informal process The 'Directing a Project' process within PRINCE2 describes a number formal documents and procedures. It describes only the formal part of directing a project. The formal part isn't that important and should be executed as light (agile) as possible. The real process take place informally, in meetings and discussions and only if needed ('management by exception'). So this process doesn't take much time if executed properly.

To me Project Boards are agile because:

• they are the ultimate impediment removers;
• they let me focus on the project's process;
• take only a little bit of my time, since the process is mostly informal and would be executed anyhow (if the Project Board wouldn't exist the same progress reports would be asked);
• the distinction between Executive and Senior User for me is a much better fit than only a Product Owner (however sometimes the Executive and SU role can be combined within one person);
• the Scrum scoping and reporting processes are a perfect fit from a Project Board point of view, so there's very little need to amend the Scrum method.

I've managed a PRINCE2/Scrum project for 8 months now and the Project Board is really helping me out when problems arise. It's great!

The business side of Scrum however is almost blank. Only assigning a Product Owner is not enough. There’s a lot more to projects than only the Product Backlog and ownership of the Product Owner. That’s why there is so much discussion concerning the implementation of Scrum. You do need to fill in the gaps.

The most obvious gap with Scrum is the management of stakeholders.

With Scrum there’s only a Product Owner. This task can be delegated to someone else (the ‘proxy Product Owner’) or to multiple persons. The problem here is that Scrum needs a ‘single wringable neck’, which is difficult when it’s not one person or when the actual ownership lies somewhere else.

Then there’s the problem of the differences in interests. PRINCE2 makes the distinction between Senior User and Executive. The Senior User is the ultimate user, the person whom will accept and use the finished product. The Executive is responsible for the Business Case. He needs to balance costs and benefits. (By the way, the Business Case is a gap in itself!). Only in small projects these roles can be combined, in that case the Product Owner is both. In most projects the roles can not be combined. That creates a problem with Scrum. A process needs to be in place to manage differences in interests.  Scrum does not have such a process.

Another example occurs with projects with a commercial customer/supplier relationship. If there’s some risk involved then the party whom bares the risk needs some kind of control. Not only on an operational level but also on the executive level. Scrum does provide some level of control with the Burndown charts and Product Backlog, but there’s no process in place to manage progress and issues on an executive level.

These gaps are manageable. Also there is not a single solution that fits all. A lot of Scrum Masters (or project managers) have found a lot of solutions to cope with stakeholders. For me PRINCE2 complements Scrum very well. I use Scrum for the Delivery process and PRINCE2 for everything else. The team doesn’t notice PRINCE2 at all, they use Scrum. The customer notices the differences compared to a traditional PRINCE2  project, but the main processes remain the same. So again, Scrum sucks at some areas but combined with PRINCE2, I couldn’t live without it.

However, in ‘normal’ PRINCE2 projects, I’ve seldom seen a real Lessons Learned session. Sometimes the project manager quickly creates a Lessons Learned document near the end of the project because the document is part of the deliverables. The actual learning doesn’t take place, not just because of the mindset at the time but also because the project is finished.

To be fair to the people involved it’s quite difficult to actually benefit from Lessons Learned when using waterfall or when using lengthy iterations. In what way can Lessons Learned from the design phase be applied to the build phase? If something has gone wrong you do feel the pain, but nothing can be done about it.

PRINCE2 argues that these Lessons Learned should be documented for future use, so that the next project might benefit. That may be true, but I haven’t seen it happen yet. Even if the documents are read, knowledge transfer by writing documents is quite useless. If the same people do the next project there’s a chance that lessons are learned.

What really matters in projects is transforming Lessons Learned to actions within a short time frame. Otherwise the Lessons are not Learned.

Here’s where Scrum comes in. When PRINCE2 is combined with Scrum it suddenly becomes easy to learn from mistakes. Here’s why.

• Each Scrum iteration is done by the same people, delivers the same kind of products and uses the same methods and processes. Lessons Learned from the previous iteration are immediately transformed to changes in the next iteration’s approach. Furthermore, the team can track problems and changes over multiple iterations and really improve things.
• Each day the team has the Daily Scrum meeting in which progress and impediments are discussed. It only takes a day to notice problems and (hopefully) there’s plenty of time to do something about it.

That’s one of the things I love about Scrum.

Based on a quick risk-analysis a month ago he concluded that project management was a high risk area  because of the combination of PRINCE2 with Scrum. In his view this was an impossible combination.

After an in depth analysis the last couple of weeks his final conclusion is that the ‘combination can work as described’. In fact, he stated that if we do what we say we do (and I can assure you, we do) that it ‘possibly is an effective approach’.

In real life it is an effective approach. We have been working with PRINCE2 and Scrum since March now and have trippled the project’s output and quality compared to the time frame before March (using waterfall). The customer is very happy with the results, the supplier is happy, the team is happy, we are all happy

But still, I’m pleased that it’s officially confirmed now, the combination can work. 

In this Whitebook I explain the differences between the 2005 and 2009 manuals and why the new manual is an important leap forwards.

The method has not been changed, it’s the description of the method that has changed.
This new book emphasizes not the theory of the method, but the principles behind the method and gives much more practical advice on the implementation of the method.

In my opinion PRINCE2 is a very successful project management method, especially when combined with the agility of Scrum. It always has been a struggle explaining that such a combination is possible. A lot of project managers don’t see that combination. It’s either ‘command and control’ or ‘let go’. Finally it is PRINCE2 itself that explains the proper way of implementing the method.

Currently all the projects at my current customer are audited. I’m really looking forward to the discussion about my agile PRINCE2 implementation! I’ll keep you posted on that…

You can find it here.

In an ideal (theoretical) world, the next iteration’s velocity should be the same (or slightly better) then the last one. In the real world this is not the case. One cause is the fact that people don’t work all the time. They go on holidays, become ill, need training, etc. and don’t distribute there time off evenly over all iterations. Less capacity means less products delivered means less story points delivered.

The difference between the projected amount of story points and realized amount becomes even larger when the sprint duration is short (for instance a week) and the team is small in size.

In the long run it probably doesn’t matter that there’s a difference between estimated and realized story points for a specific sprint, but that’s not good enough for me:

• I want the team to have an amount of workload that is realistic, is taken seriously and is something the team can commit to.
• I don’t want to explain to the customer the differences between projections and realization when I can avoid it.
• I need a more realistic planning for the near future when a specific release approaches. Estimating based on the long run doesn’t do the job.

That’s why I do both velocity planning and capacity planning.
This is how it works:

1. Each team member registers on a daily basis in Excel the amount of hours they have worked per user story.
2. And the end of the sprint I calculate the total amount of worked hours.
3. Dividing the amount of delivered story points by the amount of worked hours gives me the sprint’s velocity: man-hours per story point.
4. Before the next sprint planning session I determine the availability of the individual team members during that sprint and summarize that into the available man-hours. Then I divide the available man-hours by the velocity (expressed in man-hours per story point) and I have the amount of story points to be delivered by the next sprint.

Measuring and reporting of velocity in man-hours per story point in stead of story points per sprint is much more precise and more transparent. It makes it easier for me explaining the differences in delivered story points per sprint. It also helps me creating better forecasts and a more precise release planning. Furthermore, the team likes to have forecasts that makes sense and don’t mind the little amount of paperwork involved.

Sometimes also the business process needs to be determined. This is the case with new processes but also when process optimization is needed. The problem with this is that analysis can take a long time and often software development is stalled. Another potential problem is that the people whom do the analysis are not the same people as those that build the software. A transfer of knowledge is required and that’s something to be avoided when possible.

The traditional waterfall approach of course is not the solution. This approach creates other, much larger problems.
So can a substantional amount of analysis be done in an agile manner?

The analysis is done in a separate project “waste” is created in two ways; there’s the waste of (extensive) documentation used for knowledge transfer and there’s the waste of waiting (between analysis and design). Both should be avoided where possible.

I think there’s not one single successful approach but I’m reasonably happy with the approach we’re following at my current project.

First of all, we have introduced a second Product Backlog. This Product Backlog contains the user stories (risks, problems, whishes) on the process level. The Scrum team consists of analysts. The companies director is the Product Owner.
Each sprint the analysts create a draft business process model. In collaboration with the Product Owner of the Design & Build team they also create the user stories for the other (regular) Product Backlog. These user stories are derived from the draft business process model.

Both teams are co-located in the same room. The draft business process model is used as a guideline by the Design & Build team. During the Design & Build activities the analysts are available for questioning and support.

It’s very difficult to explain the advantages of Scrum when the customer is not used to “agile” thinking. Because Scrum delivers tangible results in short increments one could think it’s possibly better to let the results do the talking.

Here in the Netherlands the Prince2 project management method is widely used. Prince2 has a “controlled start” phase in which an elaborate project plan is created. Only after approval of this plan the project is started. Interestingly, this startup phase is considered to be a major success factor within the Prince2 method.

Is there any use for a controlled start when implementing Scrum?

May be it is a cultural thing (or maybe it’s me) but I find it very difficult to sell the Scrum approach without a project plan. On the other hand, I find it quite easy to create a project plan when implementing Scrum. Because the customer is used to Prince2 I create a Prince2 project plan (a so called “Project Initiation Document”).

When possible I use Prince2 terminology (like “Stage” in stead of ” Sprint”). I also propose a Project Board which isn’t a Scrum thing but complements Scrum very well.
The Scrum specifics like a “Product Backlog” or “User Stories” are also part of the plan.

This way the customer has a more “traditional” feeling to the Scrum process and it becomes much more easy to get things going.

The assumption is that the team is capable of limiting itself to tasks that can be completed within the timebox. But what happens when the teams discovers that a specific task can not be completed?

There are several options:

1. Continue the task until the end of the timebox, but do not deliver the corresponding product (because it is not finished).
2. Continue the task but lessen the scope of the corresponding product so that the task can be finished within the timebox.
3. Kill the task all together.

The first option might be tempting. There’s no discussion involved and nothing is scrapped. It seems to be more efficient because the task can continue the next iteration.

The problem with this approach is that there is no real deadline to meet. It really does not matter if something is not finished because you can continue in the next iteration. The same applies to the customer involved. Yes, a specific product might not be delivered at the end of the timebox because of the delays, but it will be next time.
There is no need to focus, no sense of urgency.
The timebox has become a formality, a statement within the progress report.

The timebox approach only becomes effective when the people involved feel the need to meet the deadline, again and again.
This need creates focus. The team is constantly aware of the next deadline and each decision and action is geared towards that goal.

So, options two or three are the ones to go for.

There are a couple of prerequisites though.

• You need a “definition of done” (Scrum terminology).
  The definition of done defines as explicitly as possible the boundaries of the products delivered by the timebox.
  For instance the kind of documentation involved, whether the product is tested and how, standards to comply with, etc.
• A quality process must be in place to confirm that products meet the criteria set by the definition of done.
• The project manager must consistently enforce the rule that only products which meet the definition of done are delivered.
• The customer needs to understand and comply with the consequences of definition of done.
• A team capable of working within this process.

In reality every problem needs a multi-disciplined approach. There are the end users expectations, the managers point of view, the need for training, for marketing and internal communication, the accounting department and sales people, etc.

It is impossible to create a solution that meets all demands with a team skilled only in specialists knowledge. Creating any solution needs a team capable of collaboration, capable of seeing each others point of view and finding a common, workable approach to the problem. A team with people without these abilities actually isn’t a team. It is a group of people in which each person is very good and efficient in doing his thing, but overall progress is slow and quality is mediocre at best.

When creating the project team it is important to place people with interpersonal communication skills in key positions. Sometimes this can be quite difficult because both supplier and customer might have different opinions about the team’s composition.

On a higher level, when looking at the project’s approach, it might become even more difficult to get approval for a process in which collaboration is placed above specialism. That’s when the knowledge of lean principles and the project’s manager people skills comes into play!

A fine example of this is the change management procedure. Sometimes more energy is spend in analyzing and discussing changes then in actually creating the changes. The change could have been realized in less time then was spend on discussion and creating paperwork. 

Sometimes this is caused by the complexity of the product but more often it has to do with the misalignment of the stakeholders interests and a lack of trust. Somehow a project that has started with a common goal has become ugly. How come and how to prevent this from happening?

I think a lot of projects have an intrinsic win-win scenario. That’s why the parties decided to work together in the first place. It is very important to state each stakeholders interests in the project explicitly from the start. How can there be trust when the intentions and stakes are not clear? 

The initial project plan should use the win-win mentality as a basis for procedures and responsibilities. This is not naive, it is very effective. 

Sadly often the project manager feels the need for some ‘leverage’ and creates a plan which does not balance each others interest and responsibilities.
Of course what happens then is that the customer is pushed from a collaborative mode into a formal mode with a lack of trust.

Also each time something ‘bad’ happens effort should be put in aligning the stakeholders. This is also often not the case which makes collaboration harder and makes the project team less effective.

I would argue that managing expectations is much more challenging than one would think and that a Scrummaster should spend a lot of time managing these expectations.

First of all Scrum (or Agile) project management is new to most people. 
The first reaction is either “that will never work” (it was in my case ) or “wow, this is great, we can achieve anything now”. 
Without previous experience expectations are not realistic.

To overcome the initial doubts sales people often tend to focus only on the positive aspects of Scrum.
The customer is told that the Scrum approach is more effective than a waterfall approach and delivers more functionality in less time.This is because within Scrum a multifunctional team works together and the focus is geared on the customers requirements and not on documents. This is also because the team has a very professional test process so that technical issues almost never occur. 
Furthermore the customer is told that they can change the scope on a detailed level anytime, almost without penalty in time, budget or quality. This is because a Scrum project has a rolling approach to analysis and design. Each new sprint the design is complemented with new features and changing features that are not documented yet do not cost anything.

There are a couple of prerequisites to make this statement true.

You need a disciplined team that can focus on the results of one sprint and makes that a team effort.
Usually the people in the team have not worked together before and need some time to become effective (Michael James, my Scrum trainer told me that a team goes through the process of “Forming, Storming, Norming, Performing”).

The test process within the team needs to be efficient, repeatable and generally on a highly professional level. Without proper “proof” that the solution created within the sprint is a good one that complies to both functional and technical requirements, there is a big chance that issues arise later on thus compromising progress.
Usually the test process is not that professional and lots of technical issues frustrate the learning process.

Both supplier and customer must be able to breakdown the solution in small pieces and work only on these small pieces. 
For both parties this is a big change in thinking. It is not what they are used to and even seems counterproductive (but isn’t).

Both customer and supplier must be able to delegate control to the team. In order to raise productivity the team needs the authority to make it’s own decisions (and also must be capable to).
Usually both project manager and business executive are accustomed to “stay in control” by using all kinds of formal procedures and documents.

Probably there are a couple more prerequisites….

The reality is that while it is very difficult to create a hyper performing team, a lot of the aspects described above also do occur with more traditionally approached projects and the agile approach still will be more effective.

The problem occurs when the customer expects a hyper performing team and only receives well performing results.

So what is the role of the Scrummaster in this?

One role of the Scrummaster is to advocate and monitor the Scrum process.
I think it is essential that realism is a big part of that. 

“No, the first few sprints probably will not deliver any tangible results… this is because we need to learn to work together and need to get our test process working”.

The Scrummaster must be able to communicate both the positives and the negatives of Scrum and still have a compelling story.
The team needs to know that they are given some time to get accustomed to each other and get a performing process together.
The customer needs to know that the start will be slow but that the team will make it up later on (and if not we will find out very soon and can do something about it).

First of all, let me ask you another question. “Do Scrum projects have a business case?”

Well of course they do. Every project has a business case. A “reason why”, a “justification of”, a specific goal. Sometimes a business case only exists in the mind of the business executives, sometimes an elaborate analysis has led to a business case document.

As stated in my previous post projects tend to align to the measurement system and it is wise to align the measurement system to the business case. The same applies to Scrum projects. It does not help when the business case is not defined explicitly.

Within the PRINCE2 project management method the business case plays an important role. Unified Process also uses a Business Case. Scrum doesn’t have it, but if there is really good teamwork going on then probably the business case is clear anyhow.

So, does a Scrum project need a business case?
I would say yes. It plays an essential role to maintain focus on what is important. Even when teamwork is great it still helps a lot. It also can help managing the customers expectations.

At the same time I think the Business Case should be agile. It is of no use to spend too much time on analysis or describing the solution. That would not be agile and probably not effective. To me an Agile Business Case resembles a User Story. It describes the need of the customer and defines the boundaries of the solution/product, it does not describe the solution itself.

Yes that’s correct, I do mean all processes. And trust me, it still can be lightweight, depending on your choices.
Let me explain.

With implementing a process I mean following the principle behind the process, it’s intend. That does not necessarily mean that the process and given templates are followed to the letter. It is your choice as a projectmanager to determine the amount of paperwork and the extend in which all the criteria described for a process are followed through. You can use the whole of the template, you can choose for no paper at all. As long as the intend of the process is covered.

An example.
There is a process within PRINCE2 called “Managing product delivery”. It has three subprocesses “Accepting, Executing en Delivering a Work Package”.
It is used for managing individuals or teams within the project as well as managing subcontractors. The Work Package template describes things like “acceptance criteria, communication aspects” and so on. It can be quite elaborate.

But when should you use such a template in your project? If the work is assigned to a single person whom has done much of the same work before, please don’t!
In fact the whole process can be executed verbally. To start with the process three questions are enough; “Do you understand this assignment? What kind of help do you need? Can you do the job?”.
These questions cover the intend of “Accepting a Work Package” (and are effective and “fit for purpose”).
Of course, when the work is to be done by a subcontractor then you probably need the template at it’s fullest…

There is a very powerful tool to create and maintain focus on project and that is the progress report. The progress report is used to communicate the progress to the project board or senior executive/supplier/user; on scope, budget, time and risks (and sometimes quality). Implicitly it is a kind of measurement system. The success of the project is measured by this progress report. Of course people tend to deliver what is measured, in other words, projects tend to align to the measurement system.

The big question is “does the measurement system reflect the project goal“?
In my experience this is often not the case.

The project’s goal is expressed in the underlying business case. If the business case is not defined explicitly then it still exists implicitly. (There is a reason why the project was funded). The business case should not only describe the development phase of the product (the project itself) but also the production phase of the product (maintenance, support). A common business case is that process improvements lead to a decrease in costs in production.  The costs of the project will then break even in X years.

The problem with a business case is that very often it is defined only once, before the start of a project. When the project commences the business case is never looked at again. That is a shame because the business case not only defines the validity of the project, it is also a very good tool to keep the project aligned on the end result.

In fact, in fixed-price projects, there are at least two business cases. One for the customer and one for each supplier. The customer wants a new product or process improvement. The supplier wants to make a profit on the project. Depending on the amount of “transparency” the project manager should have two progress reports, one on the customers business case and one internally for the supplier. The first focused on the customers goals, the second one on profit.

The book did not really provide me with new insights, but it is nicely written and short too
It will make an excellent gift.

Sometimes I feel like this critic when looking at how projects are managed. People tend to stick to accepted methods, best practices and known rules and regulations, but at the same time lose track of the things that really matter. Methods that were once introduced as guidelines for doing things better have become goals in itself.

Let me give you an example.

The UK government once studied successful projects and found some similarities. These similarities led to the project management method “PRINCE2″, a method widely used in Western Europe. PRINCE2 covers all kinds of projects, small and large, ICT related or not. So the method is quite elaborate and explicit about procedures, forms and project documentation.

Though Prince 2 is used widely in the Netherlands, many people consider the method to be very formal, producing a lot of paperwork and overhead. This is often true if you look at how the method is implemented. Also Prince 2 is often only partially implemented (“PINO”, Prince in name only) to make it more “lightweight”.
In both cases often Prince 2 does not lead to (very) successful projects.

So why is it that a method that is derived from successful projects often does not lead to successful projects?

In my opinion it has nothing to do with the method itself but everything with the mindset of the people implementing the method. It is not the method that does the trick; it is the rationale behind the method and subsequently the awareness of these rationales by the people using the method. If you know why a specific process or form helps creating a better project result then you also know what choices to make when implementing the method.
(Of course there are a lot of other things that determine the project success but that’s out of scope for now).

In the case of Prince 2 my advice is to implement all the processes described in the method, but to choose carefully the extend of paperwork/overhead for each process. The reason behind this is that each process described in Prince 2 has a rationale behind it, a reason why that specific process helps creating better results. Omitting that specific process could mean that the project (manager) is less in control. Implementing that process with too much paperwork has a negative impact on the effectiveness of that process (to a point that the process becomes counter productive).
The rule should be: “as much paperwork as needed but less is better”.

It is interesting to see that sometimes people with the least knowledge of PM methods create the best results. May be they practice a little bit more of “commonsense”?