Author Archives: Sjors Meekels

Leading Image

Principles, prince2ples, everywhere… Part I

Many Agile professionals in the field are wary to use terms like project management or even dare to consider possible benefits of Prince2 compared to the Agile way of working. On the other side the project management professionals, like the APMG [1] with AgilePM or Prince2 Agile from Axelos [2], are really hooking into the Agile way of working. Their approaching is, of course, from the management perspective. It is interesting to observe as to whether any shared values can be found. What better way to start investigating than the foundation of both worlds – their principles.

According to the Cambridge Dictionary a principle is:
A basic idea or rule that explains or controls how something happens or works.

In this diptych I will elaborate on the principles of one, perceived from the viewpoint of the other. In one corner stands Prince2, an acronym for PRojects IN Controlled Environment, described as a de facto process-based method for effective project management. The first version came out in 1989, followed by a few updates later on. At the moment it has seven core Prince2 principles. In the opposite corner we have the Agile Manifesto, containing 12 Agile Principles. The Manifesto and its principles emerged in 2001. As Prince2 saw the light in 1989, it is only fair to start with these principles.

1. Continued business justification
The Business Case is the most important document, and is updated at every Stage of the project to ensure that the project is still viable. Early termination can occur if this ceases to be the case.

In Agile terms no project artifact can be more important than working software. However, the ongoing justification of the business case should relate to the value delivered. This idea is at the core of the functioning of the Backlog and the priorities the Product Owner provides. Each sprint these can be redefined. In Scrum there is no official notion of a business case, just shifts in priority, followed by new stories to be picked up. These stories are driven by the value they generate for the business; that is as close to a business case as you might get.

2. Manage by exception
Regular meetings, especially the dreaded “weekly team meetings” are considered inefficient and unnecessary. Instead, work packages are assigned by Team Managers to Team Members including deliverables with time and quality tolerances. If work progresses smoothly then the workers have no need to interfere with the Team Manager’s time. Only if something deviated from the plan is communication and management required from them.

By far this is the principle Agilists get most agitated by. What do you mean, personal communication inefficient and unnecessary? A long story short, in Agile the approach is the opposite – by a mere 180 degrees.

3. Learn from experience
Each project maintains a Lessons Log and projects should continually refer to their own and to previous and concurrent projects’ Lessons Logs to avoid reinventing wheels.

Good, learn from your own experiences and those of others. Within Scrum we are accustomed to looking back and forward each sprint in order to improve ourselves. In that way, we can hardly disagree with the third principle. Learning in Agile teams, however, is a team matter and is effectuated more hands on. All team members actively participate and the stage is set in each retrospective for so called “full disclosure”. In contrast of the Prince2 way where the project leader is responsible for keeping the logs, these may even be unknown by the team. The learned lessons log resembles the good intention of a paper tiger. From the Agile perspective it is not helpful enough and the distance to the team and everyday work is just too large. So the principle is good, the effectuation in practice is far less.

4. Defined roles and responsibilities
Roles are separated from individuals, who may take on multiple roles or share a role. By naming and defining roles in the Prince2 standard it becomes clear exactly who has what responsibility and decision making powers, avoiding arguments.

Roles and responsibilities are important for organizing groups of people who work together. In Prince2 the defined roles are those of all people involved except the actual team members. The two methods overlay on the roles of Team Manager and Project Manager on one hand versus Scrum Master and Product Owner on the other. It might be interesting to see how these roles are mixed and mingled; or even further, how all roles from both worlds may be complementary to one another. They both have a different approach, Prince2 provides the maximum configuration whereas Scrum describes the pure basics. But I ought to stay focused on the underlying principles here. In my opinion it is clear the principle of clear roles and responsibilities is shared, they just describe roles from a different angle.

5. Manage by stages
The project is planned and controlled on a stage by stage basis. This includes updating the Business Case, risks, overall plan, and detailed next-stage plan after each stage in the light of new evidence.

Stages as such are not a known concept within Scrum. What we do use is the notion of small iteration with focus on a subset of the entire scope. And that is exactly what stages are intended for as well. The project scope is not managed as a whole but is divided into concrete smaller portions. As with Scrum, the idea of a smaller scope, and thus with fewer risks or pitfalls, leads to a better manageable period of time.
Sprints are the rhythm and ‘stages’ of Scrum. You could argue the planning session of a new sprint resembles the ad-hoc making of a next-stage plan. The Backlog, output of the retrospective and input from all team members is used; these reflect the business case, new evidence and all kinds of logs. The exact way to manage stages is different, for one we tend to minimize the production of voluminous documents. Another difference is the length of a stage. Of course this depends on the type of project, but a stage of two weeks is not all that common. Back to the principle at hand, again the form differs, yet they both appreciate the value of the principle.

6. Focus on products
Each work package is defined by one or more deliverable products, preferably with tolerances to time, cost, scope and quality quantified in advance.

Why would Prince2 keep such a focus on products? It does help if a team knows up front what the requirements are for the software they are going to work on. The better these work packages are described, the better a team can make estimations and do programming on them. That sounds familiar. In Scrum we focus on concrete finished user stories at the end of a sprint, measured against the definition of Done. In that way the factors scope, cost and quality are taken into account. The teams’ direct influence on the stories, mini work packages, in Scrum is much larger. Still, we can conclude this principle is valued in Scrum.

7. Tailoring
Prince2 should not be applied blindly in a dogmatic, bureaucratic form. Rather it is defined to be a method in need of tailoring to specific projects.

Tailoring enables teams and projects to adjust the processes, documents and other parts to fit their needs. Prince2 has a variety of means to manage projects of any size. A dogmatic attitude is the arch enemy of an Agile project. In Agile we use the motto “Scrum the Scrum”. That is the exact same. So the two methods can embrace each other without a fight on this principle.

Halfway conclusion

We have reviewed the 7 principles that form the basis of a Prince2. Short to say is that 6 out of 7 principles are well rewarded in Scrum and only one principle presents a direct conflict. Is this a surprise? No, it is not. Scrum and Agile don’t have a monopoly on good principles. Besides that Prince2, has been designed on years of project experiences and has evolved over the years. But to say the least, Prince2 was never as successfully as Scrum is today. Before judging the rate of success based on principles, we will have to discuss the Agile principles from the Prince2 perspective. That subject is covered in the next part of this Blog. One cliff hanger though, the team and persons are much more centered in Scr…

Contributions & References

[1] AgilePM:
[2] Prince2 Agile:
[3] Definition Principle:
[4] Prince2:
[5] Prince2:
[6] Agile Manifesto:
[7] ScrumGuides:

Filled Under: agile,agile projectmanagement,prince2,scrum,software development Posted on: 17 May 2016

Leading Image

Quality == Speed

I like the sound of this brisk statement. In my recent experience and discussions with fellow Agile practitioners, I am more convinced than ever that this statement is true. It doesn’t matter what subject or profession, any neglect on quality will always come back to haunt you and your project. I will discuss a few recognizable examples we see every day, each sprint and all year round.

Aiming for quality or aiming on costs // quality in engineering skills
First, is it really necessary to mention that in order to create great software you need great – at least good – programmers and excellent tools to support them? Yes and no perhaps. Why is it that in our field of expertise we always have to defend our teams for the costs (wages) they carry? A greater and ability experience should be worth something. Research has shown good programmers can be more efficient by a factor 10 of than average programmers [2]. This is nothing new. However, it does seem paradoxical that even experienced managers are addicted to use “cheap labor” to staff new teams. Why? If you can afford a team of above average engineers, the speed of coding is most likely going to be well above average. These guys will have a profound understanding of quality code [3] and nothing will be holding back the team from becoming very, very efficient. This is why I am convinced that any investments made in enough above average programmers to set up a team, for arguments sake say 15 Euro more per hour than average pay, will be worth your money.

People over process, but still process // quality in communication processes
The following seems to happen quite often. At the start of an important project the project leader organizes a team kick off; somehow he fails to explain and discuss the communication lines you have with your client. This can be risky. Team members might be losing precious time in unstructured discussions about what is required. They contact the wrong people, or the right people with the wrong questions, or the right people and questions but at the wrong time. Delays and unclear requirements will pile up. In no time any team will feel the urge to improve on these processes and will hopefully do so. Yet, at a time where projects are getting smaller and customer expectations only bigger, the need for clear communication from the start is paramount. Yes even in Agile & Scrum you need to have this well organized. Quality in communication processes is often an underestimated factor in software engineering. Potentially it is one of the biggest drains and wastes of energy and time [4]. So take a little time to establish clear ground rules for interacting with your Product Owner and client.

Pipelines and usage // quality in deployments pipelines
In the not so distant past, 10 years ago, it was state of the art to have an automated build in place. By having these in place, your code would be compiled and unit tested every night. In the last few years the continuous-x-movement has provided us with numerous tools and platforms in which almost every step of the software process can be automated. There is no argument left to Not implement the smallest feedback cycle possible for programmers as described in chapter 5 of the CD Bible. But, better yet also for Product Owners and clients. Programmers can get their direct feedback on their code check in, based on coding guidelines, pre written acceptance tests. Enabled by the continuous deployment [5] on specific environments, Product Owners and clients can actually experience how new code – the newest version of the product – is working, and how the UX design looks and feels. If these benefits are so huge, why don’t all projects use them already? Well, setting up a build pipeline takes time and requires knowledge of infrastructure and a lot of tools. Large companies have dedicated teams to set up and maintain these pipelines, so development teams can focus on actual software. Smaller companies may well be helped by CD consultants helping them, and in doing so increasing the quality of their delivery process. But even for smaller projects it is still well advised to do so. Not convinced yet? Check out Jez Humble’s post and Poppendieck’s “Lean Software Development”[6] and come back if you are still having second thoughts.


As you might have noticed, I am convinced about the enormous role a quality-in-everything approach can have in software projects. Quality on all levels but also the right level of quality for a specific project. The examples mentioned above will obviously not hold for some demo projects in which a only new design needs to be demonstrated. However, the moment you are starting a new project or team (or redefining existing ones), that is the time to think and design your strategy based on a good quality approach and implement as good as possible right from the start. Take a look at some of the points below and ask yourself if your project is sufficiently equipped:

• Team mission is clear and shared
• Enough talented engineers
• You (as manager), the team and your customer agree on a realistic planning
• Communication process is clear
• Team & customer are aligned on strategy
• Continuous delivery pipeline set up
• Releasing goes without stress
• Code quality is measured and good
• Delivery keeps a steady pace
• When finishing a project no skeletons are found

This list can go on and on of course. Remember nothing is set in stone, but a good start can provide a necessary jumpstart for a successful project.

Contributions & References

[1] Leading image: 3d-systems-project-ara-high-speed
[2] Origin of 10X: 10x Software Development – Origins of 10X
[3] Clean code:
[4] Communication in software projects: White paper Effective project communication:
[5] Differences Continuous X: Continuous-Delivery-vs-Continuous-Deployment-vs-Continuous-Integration
[6] Lean Software Development – An Agile Tookit, Poppendieck 2003

Filled Under: continuous delivery,lean,scrum,software development Posted on: 2 April 2016

Leading Image

Where is the fun in Agile IT Management?

You might wonder what this ancient machine has to do with Agile IT Management. Well for me this is where it started. In 1986 when my parents got me and my brother an old second hand Commodore Vic 20 [2], I was more than happy when we plugged everything in. We did not have a computer before, nor did I have any clue what to do with it. So with a few instructions from my cousin we were on our way to play some rudimentary games – for hours. From the scrap books on Commodore Basic included in the package, I marveled at the English instruction sets and the various effects they had when I tried them. At that point my enthusiasm for computer science and programming was awakened.

More IT……
However, it wasn’t until University that I learned to code properly, using languages like C, C++ and Java. Really challenging were the assignments (often using functional programming languages like Clean [4]) where algorithms were implemented to solve complex problems [3]. This connected well with my love for puzzles and strategy games. I never lost interest in programming and new languages features from that period onward. The transformation from properly coding to professional software development happened in my first years doing projects at Info Support. Quality standards were, and are, high and the peer reviews were strict and opened my eyes.

In software projects, just as in the real world, you have to work closely together with people. All kinds of stakeholders, managers, users or colleagues are interested in the project and have a say in it. For some wonderful nerds & technical experts that is a necessary evil to support their daily portion of coding. In my case it is quite the opposite, I actually like interacting with people and I enjoy accomplishing something together, more than just working on my own. My personal drive is to get the best out of a working group of people (a team). It is very interesting to see how a team develops in time if they can indeed become a high peforming team (HPT). Despite the love I have for programming I have come to realize I can contribute more to projects and teams in a leading general role than as a programmer. This does mean that I no longer regularly code, but I still understand and relate to the daily struggles and problems in my teams. I still want to contribute visibly to the results of the team, project or department.

The rewarding feeling about puzzles and problems is the moment you have solved a part of it and you can show it proudly to your clients and peers (or twenty years ago to your parents). This also applies to the Agile way of working. Every sprint (or iteration) we have solved some problems and are able to demonstrate our newly built deliverables to the product owner and other stakeholders. In this way we all see the actual result. Who doesn’t like to see regularly actual outcomes after hard work? From showing working software the discussions starts to furter sharpen the vision on the product and how to proceed next. In the Agile way of working this is fully incorporated, even more so when the results are delivered continuously in production or acceptance environments. The same holds true for improved personal running times or karate exercises, as long as my efforts are being rewarded it just feels good.

So where is the actual fun I promised in Agile IT Management? Well, for me all three parts of the term come together in the daily routines concerning software projects. We are trying to provide IT solutions for complex problems. The Agile methods we are using enable us to organize ourselves and show our deliverables to our clients. And most of all, working with people or coaching people to become a better team or better professionals is for me personally rewarding. So, if you are a little nerdy, like to deliver result and love to work and guide people, what is not to like about Agile IT Management? I enjoy the progress made by my teams just as much as the teams themselves. For me it does not matter if you are actually in a team or managing one. And of course the real boost comes when our newly made software is released on production environments and is used by customers.

Contributions & References

[1] Heading image: by Evan-Amos (Own work), via Wikimedia Commons.
[2] The illustrious Vic20:
[3] Nice collection of programming assignments:
[4] Information about Clean:

Filled Under: agile projectmanagement,personal,scrum,software development Posted on: 14 March 2016

Leading Image

Start Agitma

Welkom op het nieuwe Agile ‘blog-platform’ van Agitma! Op 1 maart 2016 is Agitma daadwerkelijk gestart. Voorbereidingen en communicatie zullen in eerste instantie vanuit Sydney worden uitgevoerd. Met een ander perspectief, vanuit Down Under, naar Agile kijken gaat vast tot nieuwe inzichten leiden.

Om alle ideeën en ervaringen met de community te kunnen delen, zullen er regelmatig nieuwe berichten via het Blog worden gedeeld. Natuurlijk is het Nederlands een prachtige taal, maar om het grootste deel van de Agile community niet buiten te sluiten zullen deze en de hierop volgende Blogs in het Engels zijn geschreven. So we continue in English….

Please feel welcome and absolutely free to contact me if you have any questions, remarks or just want to discuss topics on Agile & Scrum.



Filled Under: personal Posted on: 1 March 2016

Mission statement

Setup, guide and coach high performing teams capable in delivering truly great software.

Be Awesome

How? Try to improve something small everyday..... In management, in coding or life.

Learn from anybody

Be aware that every colleague, teammember or friend is capable of something that you are not.

Fail and letting fail

Failure is the only way to success, so fail fast and fail often, especially in software development.