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

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 want 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 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 10:50:08 +0000 Martin van Borselaer 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 Phases

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 phase. This really isn’t a problem, there are a couple of solutions.

You can execute several ‘technical phases’ (Sprints) within one management phase and in this way ask approval for several Sprints at once. My favorite solution is to agree on an implicit approval for the next phase. I use the Sprint Planning meeting as an informal approval for the next phase. The Sprint Backlog is my phase plan. During the first days of the next Sprint I deliver a phase 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 phase 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.

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”?