Author Archives: wslyvh

LeSS is more – Large-Scale Scrum

ING, the Agile Consortium and the nlscrum user group organized an evening last week with Bas Vodde on scaling Scrum with LeSS. Bas is, together with Craig Larman, the co-creator of LeSS, which was extracted from their experiences on adopting Scrum on a large-scale.

LeSS framework

Large-Scale Scrum framework

What is LeSS?

Large-Scale Scrum is basically a scaled-up version on Scrum for one team. It is not a new and improved version of Scrum, but rather adds a set of rules on applying it in a large-scale context. It consists of a set of principles, guides and provides two lightweight (agile) frameworks for scaling Scrum to more than one team working together on one product.

While we didn’t get into much detail on the differences, the idea behind it is that above approximately 8 teams additional structure is required. This structure is provided by creating requirement areas and area product owners to divide the backlog into major customer-centric concerns, while maintaining a single backlog and one single product.

LeSS vs. other frameworks

In his talk Bas emphasizes on the differences of LeSS compared to other frameworks that it provides only a minimalistic framework to decrease organizational complexity. It is based on the foundation of Scrum and only adds one additional ceremony, the Overall Retrospective. With the philosophy of “Build it Up – Don’t Tailor it Down” it encourages organizations to conduct experiments, try what works for them and frequently inspect and adapt.

The approach truly lives up to the Agile Manifesto (individuals and interactions over processes and tools) and the foundation of Scrum, but relies heavily on the responsibility of individuals. To ensure the right conversations occur on the right time, with the right people. And would therefore be more beneficial for teams and organizations who’re familiar and experienced with Agile.

What are your thoughts or experiences on Large-Scale Scrum (LeSS) vs. other Scaled Agile frameworks?

Spotify Engineering Culture

Spotify Agile culture

Although it’s been around for more than 1,5 year already the Spotify engineering video’s, from Henrik Kniberg, are still very inspiring and a must-watch for everyone who’s just slightly interested in Agile at company scale.

In Part 1, Henrik describes the teams evolving in loosely coupled, but tightly aligned autonomous squads and how they built their communities and culture within the organization.

In Part 2, Henrik highlights how the teams balance and continuously improve, both technical and their processes, ultimately creating a better product.

The great thing about these video’s is it describes their journey, which wasn’t always ideal, but showed their progress and how they evolved and protecting their Agile culture.

Teaching Agile through games

Agile is hot! And there are a number of ways to get familiar with the concepts of it. One of those is by playing games. Agile games are a fun and efficient way that allow participants on grasping the key concepts and find out how powerful Agile can be. While there are so many different games around one example I’d like to highlight is the LEGO city game. This game is covering every aspect of the Scrum process, it’s roles and ceremonies.

I recently had the chance to facilitate this game in collaboration towards another practice in our company.

Scrum LEGO city game

Scrum LEGO Game Intro
Image by Hakan Forss –

The LEGO game is covering every aspect of the Scrum methodology and focuses on 5 of the key principle of the Agile Manifesto.







The game was played as a follow-up on a basic Scrum theory session and providing a hands-on feel what Scrum is all about. With mixed levels of experience in the group, we’ve let them self-organize into two teams with one trainer as Product Owner for each team.

Our product vision was as follows;

Build a city with urban infrastructure for everyday living

  • Both teams work on the same city
  • LEGO are the main building elements
  • Product Owners will be the main decision makers
  • Everyone will be involved in the development process

While ideally after project chartering you’d want to build and estimate the backlog, we prepared ours upfront and did a separate session on estimations, due to time constraints. Our goal was to dive in to the sprint cycles as soon as possible.

The game

After a few minutes of planning our first sprint the teams were rushing in building their first parts of the city. Although a big stopwatch in front, the teams we’re surprised by the alarm and completing the first sprint already; Where is our city?!

This immediately highlighted the importance, or lack of, planning and communication at the start of the sprint. After a short round of review and retrospective the teams aligned their goals and improvements and headed off for the next round. These cycles are representing the Scrum ceremonies and can be repeated until the teams are high-performing, completed the backlog or just simply running out of LEGO blocks 🙂


After completing a few sprints, we ended the session with a open discussion on what the teams experienced and learned. This always results in some great insights and ideas which can be brought back to a professional working environment.

Scrum LEGO Game 2 Scrum LEGO Game 1

Feel free to share your experiences with Scrum or Agile Games.

An introduction to Agile Software Development

Within software development there are a lot of different methodologies that can be utilized to achieve the goal and planned results. Although all methodologies have their own benefits, Agile is one of the methodologies that emerged over the past years, with a still increasing popularity. So what is Agile and how did it became so popular?

History of Agile development

Project management was typically approached by beginning and finishing one part of a project as linear processes before moving on to the next. Sequential phases in which you should only move to the next once its preceding phase is reviewed and verified. With long leading times throughout for the entire process this often led to projects running over time, budget or no longer relevant to the business. Instead of the traditional approach only the idea or the vision of the expected goal was presented and the project started immediately.  This latter approach became known as the agile development methodology. It required more effective communication between all working teams in a project but would yield more cost efficient results. In 2001 the ‘Agile manifesto’ was written to outline and set guidelines for the principles of Agile.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

What is Agile software development?

Whereas traditional methodologies require detailed requirements and Big Designs Up Front (BDUF), Agile does not have a clearly defined end product. By close collaboration and communication Agile focusses on adapting to change in a constantly evolving landscape. Delivering incremental business value to the product on short time-boxed cycle times. Each increment adds functional bits to the product which gives opportunity to inspect the current state and gather early feedback. These feedback loops give insights on the projects challenges or opportunities and allows involved stakeholders to adapt to new ideas or information.  These ideas can be used as input for the next increment or towards the final product.

Key Benefits Of Agile

  • Development starts early, immediately adding business value
  • High return on investment (ROI) by adding value with each increment
  • Frequent and predictable delivery of each increment
  • Early feedback loops
  • Opportunity to constantly refine, prioritize and change the product backlog
  • Transparency throughout the project lifecycle
  • High stakeholder and team engagement by close collaboration

Based on own experience adopting Agile practices I’ve seen projects turning around from years delay to delivery on time. By incorporating the ability to change, close collaboration and short feedback loops this also led to a much higher client and customer satisfaction.

Fixing WCF IOrganizationService client/host MaxClockSkew security issues

Recently I stumbled upon an issue where WCF clients started to experience connectivity issues with our WCF service calls to CRM, with MaxClockSkew timings.

MessageSecurityException: The security timestamp is invalid because its creation time ('xx') is in the future. Current time is 'xx' and allowed clock skew is '00:05:00'. An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: An error occurred when verifying security for the message.

The problem here was that the clocks between the clients and the service were out of Sync, with approx. 10-15 minutes.
The default however, for the receiver to accept message with a send-time is just up to 5 minutes later or earlier.
Messages that do not pass the send-time test get rejected immediately. So this had to be fixed by allowing a larger timeframe between the two parties communicating, by setting;

  • LocalClientSettings.MaxClockSkew
  • LocalServiceSettings.MaxClockSkew

Since we were creating the service proxy programmaticely (for Dynamics CRM), without any configuration from file, we had to fix this from code;

var serviceProxy = new OrganizationServiceProxy(organizationUri, null, credentials, null);
serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior());

// Find the Security binding element and set the MaxClockSkew 
var customBinding = new CustomBinding(serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Binding);
var security = customBinding.Elements.Find<TransportSecurityBindingElement>();
security.LocalClientSettings.MaxClockSkew = TimeSpan.FromMinutes(60);
security.LocalServiceSettings.MaxClockSkew = TimeSpan.FromMinutes(60);
serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Binding = customBinding;

var organizationService = (IOrganizationService)serviceProxy;

Which comes down to creating a new Custom binding, based on the existing binding. Find the security element to update the MaxClockSkew and inject the new binding to be used by the endpoint.

Note that if you have multiple endpoints, this needs to be applied for each of them.