Daarnaast ervaart 83 procent van de Nederlandse bedrijven die Agile werken hebben geadopteerd, meer werkplezier en 85 procent meer teammotivatie. Dit percentage is aanzienlijk hoger dan vorig jaar, toen gaf driekwart van de respondenten aan meer werkplezier en teammotivatie te ervaren. Dus de mensen die Agile werken varen er wel bij, naar mijn mening een van de belangrijkste redenen voor het succes van Agile. Dit komt ook veelal tot uiting in een lager ziekteverzuim en grotere loyaliteit naar de werkgever toe.

Andere belangrijke effecten zijn een verkorte time-to-market volgens 79 procent van de ondervraagden en toename van de productiviteit (66 procent). Het onderzoek laat ook zien dat kostenverlaging een belangrijker effect van Agile werken is dan vorig jaar (38 procent in 2011 tegen 21 procent in 2010). Niet zo vreemd natuurlijk in deze economisch zware tijden. Maar dit betekent wel dat Agile steeds meer wordt ingezet als onderdeel van een kostenverlagingstraject. Dan is het wel heel belangrijk ervoor te waken, dat met het (meer) sturen op deze doelen de Agile gedachte niet ten onder gaat in de zoektocht naar kostenverlaging. Indien kostenverlaging wordt neergezet als primair doel met Agile als middel, is de kans groot weer te verzanden in ‘ouderwets’ contract en KPI management waarvan we in het verleden nou juist geleerd hebben dat dat niet effectief is.

In de overgang naar het Agile werken is de bedrijfscultuur net als vorig jaar de belangrijkste bottleneck voor veel organisaties (49 procent). En ook dat is geen nieuw inzicht. Maar het is wel iets dat te vaak onderschat wordt, zeker door belangrijke personen die juist onderdeel zijn van die bestaande bedrijfscultuur. De adoptie van Agile vereist veel focus en energie voor langere tijd en de daadwerkelijke borging vindt plaats juist via een inbedding in die bedrijfscultuur.

Door het verbeteren van kennis, kunde en bovenal mindset van Agile zal de uitrol een grotere kans van slagen hebben. De ondervraagde organisaties erkennen dit gegeven zelf overigens ook, want volgens 36 procent is een gebrek aan kennis en kunde de belangrijkste beperkende factor in de (verdere) implementatie en uitrol van Agile. Door juist in deze economisch uitdagende tijden in kennis, kunde en mindset van Agile te investeren zullen organisaties meer rendement kunnen behalen. Het verbeteren van bedrijfsresultaat is nu bijvoorbeeld voor veel financiële instellingen in Nederland een belangrijke reden om Agile te gaan werken: zo kunnen zij namelijk effectief hun te hoge kostenstructuur aanpakken.

Agile belooft dus veel, maar maakt dit ook waar. Zeker gezien de huidige generaties Y en Z die nu opgroeien en de toekomstige werkbevolking van Nederland gaan vormen, is er geen ontkomen meer aan (iets als) Agile. Regelmatig spreek ik diverse (jongere) sollicitanten die Agile, en de manier van werken en omgaan met elkaar die daarbij hoort, heel normaal en gewoon vinden en die gruwelen bij een beschrijving van het traditionele waterval model en bijbehorende werkaanpak. Het aantrekken van jong talent en een werkwijze die niets met Agile of elementen daarvan te maken heeft, staat bijna haaks op elkaar. Blijvende continiuteit en succes op langere termijn voor ieder bedrijf bestaat voor een belangrijk deel uit het aan kunnen blijven trekken en behouden van jong talent. Agile worden of zijn, lijkt hier een belangrijke voorwaarde voor te zijn.

Ik ben benieuwd wanneer u op de succesvolle trein stapt die Agile heet!

The perceived need for scaling could follow as a reaction to the scope of the project at hand. It is quite common within projects to try and do as much as possible parallel development of different semi-detached functional areas of the product. This comes quite close to how I used to manage projects in the past. Whatever in the same timebox could be done in parallel, should. I was very efficiency driven back then, but also taught and stimulated to think this way.
Within this paradigm it would be preferable, that the PO has some sort of party around him helping to create the user stories he would be in charge of. Creating big teams gives us more capacity to do more work in our timebox. Larger teams and more work create the need for more coordination, because of limited span of control, thus creating the need to scale.

Also, I think we are still very much driven by the paradigm of the chain of command. It is simply comfortable when there is someone who can make the tough decisions for us and mediate between us whenever conflicting interests arise. The need for extra coordination between and over PO’s in the same context thus fits very naturally with our needs in a growing project context.
Come to think of it, maybe it is no coincidence that the person designated CPO is more times than not the first PO that was on the project. If we look deep within ourselves wouldn’t every PO actually want their first project steps to be so successful, that the extra means are granted to grow the team and consequently rise above to lead the way as CPO? And should we be that CPO, would we ever fully trust another colleague with the work we carefully prepared and poured our blood sweat and tears into? It would be great if we could somehow keep some sort of supervision on the others. Make sure the projects success and our hard work isn’t killed off in the next sprint or two. Scaling with a CPO construction would provide means to fulfill these needs.

Of course the above reasons to scale could be valid, but there are also downsides to them.

Although doing parallel work may sound efficient, maybe validation with your customers shows that the product increment doesn’t fulfill their needs as thought up in the first place. Since you have done a lot of parallel work, the risk of waste is also greater. Should you need to radically pivot your product in another direction, it will be much harder due to the already large scale of your operation.
I thus think that scaling towards having different teams work on the same backlog potentially inhibits us from maximizing validated business value, as you are pulling forward less important features from the backlog, before actually validating and thereby knowing whether you have actually delivered value with your top items. From this angle, it would be wise considering not to scale.

When scaling from success, we run the risk of slipping into a power monger mode and form a team beneath us to gain status and control instead of branching out sideways.
When this happens we are not working towards joint company stakeholdership any more, but we trying to build our own ivory towers. When the CPO leading the PO’s claims decisive power in certain areas, I believe you would not be creating the right entrepreneurial environment in which decisions are based on arguments and value for the customer and company. Maybe, as a PO, if you already know you need a decision from the CPO, you are inclined to use other influencing methods rather than comparable and less subjective measures than for example business cases, jeopardizing the quality of decision making and therefore the success of the product.

During my study, I was taught “there is no one best way to organize”. I think of this line as a universal truth, that in my opinion also applies to scaling the PO role. I therefor think that form is less important than the route taking you there. Knowing that there are risks involved in scaling and consciously dealing with them helps you along this route to find a form that works for you.

(*)Scaling is also common in productline contexts (for instance a CPO over a group of PO’s managing a product family) or within business units where you would have various strategic themes that the CPO would like to have implemented over the same time period.

What puzzles me, is that if we are wired by nature to enjoy cooperating effectively in a collective, then why do we encounter problems with it in our workspace. I think the main cause of these problems lies in the lack of shared purpose that motivates us, and the ability to trust each other in the pursuit to be purposeful. Maximizing income, and therefor your own benefits, is not real purpose that is felt across your organization. This doesn’t work in complex environments like the IT companies we are used to support with agile. Real purpose, mastery and autonomy however do, as Dan Pink shows us in his illustrative video on this subject. Others, like my colleague Olav Maassen, recognize this as well, trying to channel mastery into new forms for the workspace and beyond.
Another great example of seeing Dan’s findings in action, in my opinion, is the IDEO initiative openideo.com. People can literally join forces and find solutions that actually help to solve collective real world problems. They do so for free, just because they want to. Talk about working together to change the world! Although you can score points for helping in openideo, showing off your mastery in product and idea development, I think the greater driver here is the urge to help others in a collective fashion. Wouldn’t it be great if we could have an openideo in every company out there? We have so much knowledge, creativity and willingness in-house to collectively bring our companies to the next level. We only need to truly engage our co-workers.
That’s were autonomy comes into play. We should trust each other enough to facilitate more autonomy in the workplace. Provide room to your stake-takers and become genuine stake-sharers on route to joint company stakeholdership. Why not trust on one another rather than being fearful of the negative impact on our own stakes. I guess this also has to do with purpose somehow. Idealistic purpose with no sense of realism leads nowhere and maybe even worsens the status quo.

As agile consultants and coaches we try to foster teamwork and consult in change towards sharing ecosystems. I guess we could say we are blessed to have nature on our side. I guess we can also say we need to balance idealism and realism in creating purposeful systems and that this requires a significant level of trust within our clients organization. Although this may sound pretty far away, why not start with people in your direct circle of influence. Try to be as transparent as possible towards your client. Work together and build trust through trust, paving the road to change.

I encountered a lot of story-maps based on this principle in financial services lately. The “hello world”-first slice, or walking skeleton, comprised of nothing more than the bare minimum technical necessities to get a working chain environment end-to end. Later being fleshed out with additional functionality.

Most of the times this is the right thing to do, because in most cases there are dependencies with other systems and internal “suppliers”. The risk to see whether the system would work with these external systems later on in the project is too big to postpone, to when the features come up that possibly depend on these external pieces of the product puzzle.
Getting these dependencies out of the way, means seeing a working chain and having a better picture of how things work, mitigating the risk associated with delaying dependencies. For the external factors it means building the essentials and stubbing the rest, creating the barest technical walking skeleton possible, a working end-to-end chain.

Strangely some projects I saw with large amounts of external dependencies did see the value of this possibility, but still decided to go for a more functional first slice of the product, leaving them struggling for months before delivering end-to-end working software. How could this be?

The issue here was, that at the start of the project people all saw the dependencies but none of them could be addressed effectively. The major issue was the fact that all but one external supplier to the project were actually other internal departments that couldn’t/ wouldn’t lend resources and rather stick to their own release calendars (making them real old skool stakeholders by the way which is pretty evil). They also had a lot of problems getting their own environments from outside of the project, which didn’t help as well.

In the ideal world this project should not have started without the necessary support in place to complete the first ideal optimal technical slice in a couple of sprints. Which is actually not so different from when you create a regular walking skeleton come to think of it ☺. Remember to keep a technical walking skeleton an option when working in complex chain environment and or existing system environments. You might be amazed how fast you can get the first feedback, from customers and other stakesharers.

Should you have some interesting other slicing dimensions you would like to share, or you totally disagree with me, please leave a comment below! Many thanks in advance.

At that time I was the project manager and scrum master of a software development team. As a team we embarked on our exciting mission to develop a new product. We did this in a Scrummish, more or less Agile way.

We set-up a continuous integration environment and we measured a lot of things. The metrics we collected included #PMD violations, unit tests ok/failed, #FitNesse tests ok/failed, code coverage, cyclomatic complexity, distance, velocity, etc.
For the product we knew that performance was going to be very important. So we ran various automated benchmarks on a daily basis. The results were collected automatically by the build system and stored in a database for reporting purposes.

Besides that I needed this to report to management, it was also quite fun to implement

Dashboard

Then I had a brilliant idea: it would help the team if I would make all this information available on a dashboard! So I spent a couple of months (including lots private spare time) implementing this based on JBoss, Pentaho Portal/Reporting, and MySQL. While implementing this I learned a lot about portals and Pentaho. On the portal side of it, the team members could define their own dashboard and view on the metrics. Cool.

Except…..nobody (except for myself) looked at it…..how come?

Coffee Machine

In the weeks that followed going live with the dashboard it struck me that team members stood by the kanban board discussing possible bottlenecks and what to do about these. The kanban board happened to be within 2 meters of the kitchen where the coffee machine stood.

So what happened was that every time people went to get a cup of coffee, they gathered by the kanban board (because the kitchen was too small) and discussed the latests events and what to do about it!

…..the next day I printed some of the most important charts and stuck them at an empty spot on the whiteboard. Guess what happened!

Conclusion

Before deciding on a tool think about what you want to achieve with it. In the example above the goal of automatically collecting metrics and create charts was OK, but having an electronic dashboard to replace interactions within the team was not a very good idea. That was time to eat my own failure cake, with a cup of coffee.

One of the mechanisms in Kanban to manage flow is to explicitly set a limit on the amount of work in progress for a process step. By modifying this to include part of the next process step, this article shows that the amount of work in progress is limited more and therefore also lead times are reduced.

Kanban Board

Kanban is an approach to scheduling that gives insight in the flow of tasks. It makes this flow visible on a wall by defining a column per step in the flow. Every task starts in the first column and is moved to the next column if all the work that needs to be done in this step of the flow is completed. A Kanban board typically looks like:

This Kanban board has five columns named

• Ready,
• Design,
• Build,
• Test,
• Deployed.

The numbers in red indicate the maximum number of tasks allowed in a particular column. E.g. for the ‘Design’ and ‘Build’ columns the limit applies to the total number of tasks in the purple and green areas.

It is customary to further split the columns except for the first and last into two. This is indicated by a dashed line. The sub column left of a dashed line contains tasks that is being worked on. The sub column to the right of the dashed line contains tasks that are completed.

Notice that both the ‘Ready’ and ‘Design’ columns have capacity for 2 additional tasks, i.e. the number of tasks in the column is less that the maximum allowed number of tasks shown in red at the top of the column.

Modified Kanban Board

Let’s modify the Kanban board a bit. For each column extend the limit areas so as to include the first half of the next column. For the columns ‘Design’ and ‘Build’ the result is shown in the picture below.

The effect of this change is that the limits now apply to the number of tasks in three sub columns (one and a half column) instead of two sub columns. Also, the purple and green areas, now overlap having a sub column in common, namely the ‘In Progress’ sub column of ‘Build’.

The overlapping of the two areas clearly shows the difference with a ‘standard’ Kanban board.

Finally, notice that with the introduction of overlapping ‘limit areas’ the ‘Design’ column now has reached its limit of 4 tasks and no more additional tasks are allowed.

This illustrates that the introduction of overlapping ‘limit areas’ further limits the work in progress.

Work in Progress

Why should one care about reducing the amount of work in progress (WIP)?

Benefits of limiting the work in progress are:

• Reduced lead time resulting in shorter feedback cycles and shorter time-to-market,
• Smoother flow of tasks resulting in less variability,
• Less task switching resulting in more efficiency and more focus.

For the interested reader who wants to know more about the importance of limiting WIP there are numerous good articles and blogs on this topic, e.g.

• LimitedWipSociety – Explaining why limiting WIP is so important
• LeanAgileMachine – Some thoughts on Limiting work in progress (WIP).

Origin of the Modified Kanban Board

The main idea for the overlapping limit areas is taken from POLCA. Just like Kanban is the scheduling tool in Lean, so is POLCA the scheduling tool supporting Quick Response Manufacturing (QRM). In manufacturing POLCA was successfully introduced for low volume, custom products in which case kanban does not work very well.

What is POLCA? POLCA stands for Paired-cell Overlapping Loops of Cards with Authorization. In the context of the modified Kanban board shown earlier the interpretation is

Paired-cell
The two columns between which tasks move.

Overlapping Loops
The overlapping limit areas.

Cards
The tasks.

Authorization
Whether a task is allowed to be moved to the next column.

Properties of POLCA that are particularly interesting to software development are:

• Downstream bottlenecks are signaled faster to upstream processes,
• Less work in progress (WIP) resulting in shorter lead times,
• The ability to ‘look ahead’ which aids in scheduling decisions in case of multiple story streams.

These are more advanced subjects that will be addressed in future blogs.

Conclusion

This article explains the basics of POLCA and how it can be applied to a Kanban board. In Kanban the amount of work in progress is limited by explicitly setting limits on the columns. By letting the areas to which these limits apply overlap, work in progress is limited even more. This results in additional benefits such as less task switching, more team focus, and reduced lead times.

In next blogs I will write about other aspects of POLCA and benefits result from this.

More focus on “the string of rights” generally brings a great deal of success but also a lot of stress to cope with. The stress comes from the fact, that if all capacity in our production system is focused on doing the “rights”, that those “rights” might not always be the “rights” you are responsible and accountable for right now.

Dealing with the stress means stakeholders have to change their attitudes from viewing themselves as stakekeeper to stakesharer. Stakesharers put more value on the overall company results than the stakes they hold (semi) individually. This as opposed to stakekeepers. To facilitate “stakesharership” means, we have to scan our organizational context to see what elements are not aligned with the concept and to improve on them (e.g.; communication structures for dealt portfolio management, job descriptions, budget-management processes, leadership styles etc.)

Your focus on the string of rights increases if there are less stakekeepers around, as Burm’s formula for joint company stakeholdership shows us:

If there are also mature teams with enough sense of responsibility and involvement to become staketakers, chances are your increased focus on value and joint company stakeholdership are just around the corner.

Say goodbye to traditional stakeholdership. If you want to create real ownership in your agile company and maximize focus on value delivery, embrace the concept of joint company stakeholdership today!

PS: If you fill in Burm’s formula for your company right now, how would you score?

In agile adoptions I have been part of, efficiency was something the business wanted to see from day one. Most of the time they want to see things like: team-goals, KPI’s, metrics and stuff like that. Of course that’s very important information because we need that sort of info to run our businesses in a sensible way, I understand that and even advocate it.
On the other hand I try too temper people in their drive for efficiency. I believe that people first need to learn to effectively work together, before they will be able to reach a next level towards better efficiency.

The talk show item gave me some new ammunition in discussing efficiency and effectiveness. It was about a thing called elephant trails. Elephant trails is the name for shortcuts people tend to take when walking along a pedestrian path. Take a look at these photo’s (http://www.olifantenpaadjes.nl/) and you’ll see exactly what I mean.
So the funny thing is, that there first needs to be a path that leads us somewhere (effectiveness), before we see means to better adapt to this new context and take the more efficient route (efficiency). Hence if the context of the footpath wasn’t there to bring us effectively from a to b, we would have never thought about taking a more efficient route. Why we actually tend to walk along these paths I don’t know. If I found definite proof that Efficiency always follows effectiveness, I don’t know. But what I do know, is that this is a good way to explain the concepts and to discuss your route towards your goals.

Thanks to Jan-Dirk van der Burg for bringing this strange and interesting phenomenon to our attention.

PS, please do try and get your metrics in as soon as possible, just make sure to do it in a non-intrusive fashion towards your team members.

But the question (and the initial answers) kept nagging at me all day. And while I sat down with a glass of good whisky in the evening I got back to the question. Here is what I came up with:

• Agile is simple, not easy
• Experience bootstraps learning
• Organizational gravity

Agile is simple, not easy

Any agile methodology is usually very light on rules and have-to-dos. That makes it simple, but not easy.
Behind and because of those simple rules there are still very complicated issues.
“Features must be broken down into chunks that can be implemented in x days” is very simple, but very hard to do if you have no experience. (and sometimes even if you do have experience.)
“At the end of every sprint you need to have a retrospective”. Again very simple. But actually creating a team and environment that can really learn and improve their own process is hard.

So yes Agile is simple, but hard

Experience bootstraps learning

One of the most important things about Agile methodologies is that they make it possible and encourage learning teams.
Having someone with experience however allows a team to accelerate learning in the beginning. Someone who has been in a similar situation before can pick lessons learned and share those with the team so some wheels do not need to be reinvented. As long as the team only uses those ideas as a starting point for their own learning it can accelerate the initial learning.

Organization gravity

Lyssa Adkins has a brilliant quote in the book “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”.

“Gravity Works”. Yes it does. Rock climbers know this and plan for it. So do Agile coaches.

Agile transitions are not limited to the teams doing the actual development. They are part of much bigger picture. Other departments need to at least be aware of the transition and probably have to change considerably.
For example walk into the operation department of a big company that is doing waterfall projects and tell them that you are going to release every project every month. They’ll laugh at you.
Most managers actually really like the fake certainty of waterfall projects..
Agile does not solve any problems by itself, it just makes them painfully clear. Not all organizations are mature enough to realize that and will usually blame Agile for all those problems that are suddenly surfacing.

Those are only some examples where organizational gravity will play up. They will constantly pull your Agile transition towards the old status quo.
An experienced Agile coach will recognize those signals and work with the clients to keep an Agile transition on track towards the goals that were set.

Just like a regular coach.

Xebia is helping many organizations in the Netherlands, France, the United States and India with implementing an agile way of system development. In most of the cases the Scrum method is applied and very good results are achieved. Business and IT are working much closer together, resulting in more quality and much more customer satisfaction. However, lately we also see a trend in problems that seem to occur in (almost) every organization. Software is developed in a fast way with high quality, but it takes forever to get it in production. The more teams are being formed, the more interdependencies between the teams occur, disturbing the heartbeat of the teams. Teams have to wait for other teams to finish, or they have to work together to complete the work. Also it’s not always clear which team should do which job. Next to this product owners are being over asked. They have to supply the teams with user stories / epics, but also have to know upfront which team to ask it, have a clear understanding of the direction of the solution and at the same time define non-functional requirements like availability or system responsiveness.

The scrum masters in the teams are not able to solve all this. They have the interest of their team at hand and are mainly focused on the process to do a good job. They are less focused on the contents of the product backlog or how team deliverables are related to the broader context. However the real situation in many organizations is different. The environment of scrum teams is complex and often not very agile. Scrum teams need to work in the context of an existing organization, which has formed over years. To be able to do so, they need a context. Especially the context in the content in important. Here is where architecture comes in.

The picture below shows how Scrum synchronizes the business cycles with the IT project cycles. Without Scrum the time lines for supply and demand are out of sync. By delivering software faster, Scrum is able to follow the priority of the business and develop IT systems which are in line with current demand (not with a demand from last year). However, businesses also have a longer term strategy, which can make them give significant competitive advantages in the near future. To be able to direct the IT development towards this longer term goals, the business needs architecture. In this way the short terms Business cycles and IT development cycles are in sync, but they move forward towards reaching the ultimate business goals. The picture shows the three different stages from being out of sync, to being in sync and also be moving towards the strategic goals.

Therefore, architecture in the agile world has a very important role to play. However it has to adapt to the new way of working and the new way of looking at the world. In an earlier blog from Xebia, we talk about the 3 C’s of architecture. We defined three goals of the architecture function in IT organizations: The Three C’s of Architecture. These are: Connection, Cohesion and Changeability. Taking these as the prime principles of architecture provides focus on what to do and how to position architecture in the Agile organization. We deliberately do not speak of “the architect”, because architecture is created by many people: domain experts, (experienced) software developers, testers, operations people, software architects, enterprise architects, etc. Therefor we will talk about the architecture role.

The Connection with organizational goals is achieved by using enterprise architecture as a way to create a common understanding about the business and IT in the future. But also the architecture role plays an important part in helping the product owner(s) to specify their requirements and give directions to possible solutions (in line with the enterprise architecture). Cohesion between teams and cohesion between teams and their surroundings, are the main aspects the architecture role has to focus on, by helping the teams getting more productive. Finally the architecture role focuses on Changeability by continuously evolving the architecture and adjusting it to the real world. Architecture creates its own learning cycle. Next to this the modularity of the architecture has to be taken care of, so software is easily adapted without too much interference with other elements in the architecture.

In the coming months we will write a series of blogs, about several aspects of architecture in the agile world. First of all we will write about experiences in the field. How things are done. What can be done better and which lessons are learned. Next to this we would like to present out view about the architecture role in an Agile environment. Which tasks should be done, who contributes to creating architecture. Also we would like to write some blogs, about tools and methodologies used to be able to fulfill this new role in the best way possible. Finally we would like to talk about the architecture itself. How can we make architecture agile? How do we modularize the application architecture, or in what way does virtualization, provisioning and automated deployment help? With all these blogs we intend to redefine the world of architecture in the agile world. Comments and opinions are most welcome, so the architecture and agile communities merge together with a way of thinking on architecture.