Category Archives: Agile projectmanagement

Leading Image

Visualization helps Agile Teams & Organizations

Transparency is one of the corner stones of great Agile teams and organizations. If that is the case, isn’t it strange that so many teams have little outwards visualizations? Not only teams benefit from visualization, but also management and other stakeholders could gain direct insights from the information presented. In this blog, I will discuss visualization from different perspectives using my own checklist as a starting point (see at the bottom of this blog). At the end, I will share a few pointers to get you started.

The eight examples on my checklist are a nice start. Depending on your team or department characteristics, you can probably add a dozen others. Some at least as important as the ones on the list. However, the true value for me lies in the dialogues and questions that arise from them instead of the – more fundamental – discussion on which items should or should not be on the list.

Team perspective
Let’s start with the team perspective. The first reaction and question that usually pops up is: for whom are we visualizing? Unarguably, it should be for ourselves and our stakeholders. So, if we do it for ourselves, we need to have information radiating that is important and useful for us. In my opinion, all topics on the checklist should matter to any given team. If not, there is a chance something is off in the basic way the team is functioning and/or supported by its organization. Do it, pick one topic and argue that it is not important for a healthy routine of your team.

The second reaction from teams can come from two directions: “we don’t have that information” or “it takes too much time to gather it”. Both arguments are excellent starting points for valuable discussions – during retro’s or just over coffee. Not having the information means that your team is flying in the dark. Either the product or the company’s road map is not clear or perhaps the feedback loop for continuous improvements is not implemented. If collecting these basic team drivers takes too much time, chances are that tooling is not in place or not used correctly. The reactions mentioned in this paragraph are indicators that the Way of Working can be improved.

Management perspective
Let us shift to the managerial perspective. In more Agile oriented organizations this perspective often leads to a different reaction compared to the ones above. “My teams are self-organizing, self-managing or self-supporting, so they decide what is shown and needed.” Wrong! As long as managers are responsible for their performance – either hierarchical or via a more servant-leadership – it is their job to have an interest in these subjects. If not, they’ll have a tough time explaining what added value they have for their teams and thus their organization. For example, how can a team manager not want to see Impediments or improvements made by his or her teams? In addition, teams often need directions and coaching on organizational goals and drivers. Outward visualization helps the process of aligning the organizational goals and the Way of Working of the teams.

In practice, it can be challenging to implement and decide on the most useful visualizations for your teams or department. Remember it is good to try things and ask around who is interested in what information. Or as a manager, discuss with your teams what the goal and improvements are from an organizational point of view. If done right, the information not only benefits the teams, it is also a source of information that could substitute numeral status meetings.

Stakeholder perspective
The third and last perspective is that of the stakeholders. Top priorities for stakeholders usually contain the question: “When is this or that feature finished?” By showing this information crystal clear in the team area, the team provides the stakeholders with direct insight. Moreover, it helps by building confidence and making the team predictable for its environment. Perhaps the expected date example is a bit simplified. How about this one: create a good Story map of the current product (iteration) and put it in a visible place in the area. Make sure you add significant release dates, in case you don’t go to production in every sprint yet. Now, the timeline has its own functional context which makes clear what the stakeholders can expect. For teams, it is good to adjust to the stakeholder’s needs. Thus, especially as a Product Owner you should invest in what the stakeholders would like to see and hear from the team. Also, be confident to use visualization and communication forms you have seen working before.

A few pointers to get started
Responsibility: who’s responsible for visualization? When teams just start, most of the times it is the Scrum Master who begins with Burn down charts and Impediment boards followed by other more Scrum – or process – related information. In my opinion, it should be a Scrum team effort. In other words, everybody – also the Product Owner – is using the team area to show road maps, examples or key metrics. This will stimulate the philosophy that if it is important for the team, we put it up there. Anyone can decide or try to use some new metric or insight. This does not mean that other stakeholders cannot let the team know what they would like to see.

Gemba walks: one practice that provides insights to all stakeholders is doing Gemba walks across multiple team areas. Don’t ask how things are going straight away. Instead, look around and see what the information presented is telling you. I have used this technique also with colleagues visiting other teams. Besides entertaining it is an easy mechanism to share practices and bring teams a little closer. A Gemba walk might be a catalyst for explorations on visualization benefits for teams, managers and stakeholders.

How to show: I did not elaborate on the form in which information is shown. That is on purpose. Depending on the team, tools and context, you’ll get different outcomes. The fact that I am not a great sketch artist results in more print outs for my teams. In companies with big screens available in team areas you can have as much metrics and info on the screen as you would like. In some companies on the other hand, there is a strict clean desk policy and very little information is allowed to radiate from team areas.


The discussions and feedback from teams and stakeholders can be as valuable as the visualizations themselves. So, make sure you are aware of their thoughts and needs before mounting all kinds of information to the walls. Depending on your role you can initiate the dialogue with or within your teams in diverse ways. Use the checklist, the Gemba walk or any another conversion-starter in your team or department to explore the benefits of visualization. I am curious to hear your experiences and/or remarks. The discussion and feedback from teams and stakeholders can be just as valuable as the visualizations themselves. So make sure you have these before you start mounting all kinds of information to the walls, or demanding this as management.

Download the one-pager: Visualization helps Teams and Organizations


There is a lot of information out there, so I added just a few examples to get you going:
[1] Visualize Agile
[2] Ben Linders: Visualizations
[3] Story-mapping
[4] Toolbox for the Agile Coach – 96 Visualization examples, Jimmy Janlén, 2015
[5] Coaching Agile Teams, Lyssa Adkins, 2010

Filled Under: agile,agile projectmanagement,kanban,scrum Posted on: 1 September 2017

Leading Image

Principles, prince2ples, everywhere… Part II

In the first part of this blogpost I have elaborated on the Prince2 principles from the viewpoint of the Agile mindset. Today we are going to turn the tables. We could consider the four Agile values defined in the Agile Manifesto as our primary subject; however, with a full set of twelve available Agile core principles that would be a shame. It is possible to recognize benefits for projects from all of the twelve Agile principles [3]. This is an interesting exercise, but it is not the same however, as judging these principles from another viewpoint.

A small side note: in order to keep this blogpost from becoming an unwelcoming long read, I will be short on those principles that are not part of Prince2 at all and rank these as neutral votes.

1. Customer satisfaction
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Being on time and within budget are still often the classic elements on which a project is rewarded, with quality often as the lesser third.Although Prince2 values finished work packages, these are often part of progress reports; early and continuous delivery of software is not required. Working software is just not the highest priority. As the iterative flow of Prince2 does encourage smaller delivery moments, a neutral vote fits best for this principle.

2. Embrase change
Welcome changing requirements, even late indevelopment. Agile processes harness change for the customer’s competitive advantage.

Welcoming change is a different approach compared to a strict defined change process to cope with adjustments. A little exaggeration to indicate the contrast: Prince2 follows the paradigm “Stick to the plan” whereas Agile is designed on the paradigm “Change the plan”. Changes in Prince2 follow a formalized process. Due to their nature of being a change to the current project plan, they often require an official approval from the project board. The principle is therefore not shared and placed in the conflicting corner.

3. Frequent delivery
Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale.

As discussed in the first part of this blog, Prince2 uses stages or iterations to create a smaller scope. We linked this principle to principle 5 “Manage by stages” and concluded these were shared.

4. Ongoing collaboration
Business people and developers must worktogether daily throughout the project.

This principle is not part of any official Prince2 description. While there is nothing against it as well, we consider it as neutral.

5. Support self organization
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This principle has one interesting aspect that stands out for me. It is the last phrase, “trust them to get the job done”. In the very acronym of Prince2 the term “Controlled” is present, which makes me refer to a quotation attributed to Lenin: “trust is good, control is better”. I have a hard time convincing myself the principle is shared.

6. Face-to face communication
The most efficient and effective method ofconveying information to and within a development team is face-to-face conversation.

In the discussion of the second Prince2 principle “2. Manage by exception principle” we already concluded the two methods have an opposite approach. The conflicting votes have gained another member.

7. Progress measurement
Working software is the primary measure of progress.

While monitoring progress and clear reporting is an important aspect of Prince2, there is no defined measurement of progress itself. The project manager is responsible for setting up fitting measurements and reporting to the project board. Given  the fact that working software is in practice an important part of the progress report, I lean towards a neutral vote.

8. Sustainable development
Agile processes promote sustainable development. The sponsors, developers, and users should be ableto maintain a constant pace indefinitely.

One of my favorite Agile principles shows the difference in approach from the classic project methods. From a Prince2 perspective, with a temporary organization and fixed time frame, it seems there is no direct need to keep a sustainable pace. Projects with fixed dates even find themselves falling back to proven anti-patterns such as dead marches or scaling up teams to mythical proportions [2] when the end of the project comes into view. On the other side, I have seen this happening in Agile projects as well. Leaving the real life experiences behind, Prince2 does not have anything against a sustainable pace, so this principle finds itself on neutral ground.

9. Invest in Technical skills and design
Continuous attention to technical excellence and good design enhances agility.

This principle is not known or rewarded in Prince2; even more, enhancing agility is not a useful project goal to have at all as itcan lead to gold plating and over engineering. Good design in itself is valuable indeed. You can raise the argument that actual continuous attention to good design for agility is only a project goal if Changeability (as a dimension of Maintainability in ISO 1926) is in the official requirements. The omission of a Prince2 view on this principle puts it in the neutral camp.

10. Simplicity
Simplicity – the art of maximizing the amount of work not done – is essential.

Focus on concrete products, doing what is in the plan and not losing valuable resources on non-attributing work, these ideas are all perfect from a Prince2 viewpoint. In an actual project there will be discussions as to whether something is in- or out of the scope of the project. This is especially true in fixed priced projects. In Agile projects we have similar discussions in deciding when a story is Done (an interesting approach is Just Barely Good Enough [5]).  There is a mutual appreciation of this principle.

11. Self organization for the best results
The best architectures, requirements, and designs emerge from self-organizing teams.

Prince2 does not acknowledge self-organizing teams; on the contrary, team managers and project managers are responsible to guide the project and teams. The usual organizational approach is by Product Breakdown Structures (PBS) and distributing work packages to teams and individuals. Team involvement is then accomplished through team plans and team sessions. Although this means the teams are involved, they are not self-organizing. This raises the number of conflicting votes by one.

12. Inspect and adapt
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Learning is a defined part of Prince2: this corresponds directly with principle 3 “Learn from experience” and avoids reinventing the wheel. So this principle is shared.


The votes of the Agile principles perceived by Prince2 are in: there are 5 neutral votes, 3 shared ones and the remaining 4 present us with conflicting ones. The contrast to the outcome of the first part is big, where 6 out of 7 of the Prince2 principles are rewarded in Agile as well. How can this difference be explained?

First of all Prince2 is a general project management method, this means it can be used for any types of projects. Furthermore, it is stated the specialist contributions (in software engineering all team members) are not part of it. Agile is founded on software engineering best practices and describes a way how teams and specialist should interact. This explains why 5 out of 12 of the Agile principles are not present from Prince2 perspective: they are just too specific. The fact that the majority of Prince2 principles are rewarded by the Agile mindset can be attributed to this difference in granularity as well. And they are still good principles, in the previous blog we concluded that did not come as a surprise.

The next interesting observation is about the four conflicting Agile principles. Three out of four of these principles (5, 6 & 11) are tightly coupled to self-organizing teams and communication. Besides the previous point about being too specific, the Agile mindset is based on a very different starting point. This is best illustrated by the Agile Manifesto itself: “Individuals and interactions over process and tools”; it contrasts to the defined process that Prince2 is about. The remaining conflict, principle 2, can also be explained using the Manifesto: “Responding to change over following a plan”. Again, these plans are at the core of Prince2.

What can we learn from this exercise in principles? The most important aspect is that the views and actions of project management should be fundamentally changed when they combine Prince2 and Agile. The two methods can be set up as complimentary, but the shift in paradigm for project managers is bigger than for their practicing Agilists specialist (teams). That shift is not easy. In fact it is really hard to change attitude and behavior, particularly when the pressure is high in a project. Sadly, that is why so many ‘Agile’ projects or organizations [9] slip and fall back to the same mistakes made by old school project management – years and years ago.

Contributions & References

[1] Prince2:
[2] Mythical Man Month, F.P. Brooks:
[3] Agile Project Mngmnt for Dummies, M.C. Layton:
[4] Simplicity: agile-principle-simplicity-the-art-of-maximising-the-work-not-done
[5] JBGE Just Barely Good Enough, Scot Ambler:
[6] Changeability:
[7] Agile Manifesto:
[8] ScrumGuides:
[9] Failing Agile- InfoQ:

Filled Under: agile,agile projectmanagement,prince2,scrum,software development Posted on: 3 June 2016

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

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

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.