Category Archives: Software development

Leading Image

First LeSS Conference – Ever

The first LeSS Conference – Ever
So the first ever LeSS conference was about to take place in Amsterdam. A few former colleagues were planning on going so I was immediately interested as well. The lineup was promising, Bas Vodde and Craig Larman would be present and Gojko Adzic was one of their guest speakers. My knowledge of LeSS was limited to what I had read online as I have not yet been in an organization using LeSS as a scaling framework. Well, you guessed right, I ended up going and in this blog I will share some of my personal highlights of this two-day-event.

Opening and setting
The body organization of LeSS is not a big commercial vehicle which rolls out events like this every few weeks. So things were new and the atmosphere was also newish and therefore relaxing. Cesario had the honor of opening the conference

Story of Less- Bas Vodde
The history of Less may be told during trainings, yet as I heard the story for the first time it was entertaining, recognizable but also refreshing. LeSS is still Scrum, but with a little extra. The focus on Feature teams is an important aspect and needs to be strong. Component teams are not ‘forbidden’, but they mustn’t form the majority. Another interesting point is continuing the Scrum mindset as a framework. The opposite as with RUP, which you have to tailor down, meaning don’t use everything except the parts fitting your own situation. In LeSS it is called “Build Your Method Up”. Bas can probably tell the Story of Less like no one else and the good thing was, he told the story like sitting around a bonfire (just a fire on a video this time). He only showed the slides of the actual story in a total of 20 seconds when he was finishing up. The story was mainly on the core essence and the history of LeSS and not like a mini-course.

Teams and assignments
One of the goals the event organization has was to establish new communities and to enhance the interaction between visitors. The leading mechanism they initiated was the forming of new team who should collaborate on genuine product to be shown at the end of day two. So the entire group of people were gently pushed to form teams by self-organizing. Every visitor had received one or more small buttons indicating a certain capability, e.g. developer, designer, LeSS expert. The goal was to create teams with all the capabilities covered. Yes indeed like a true cross functional team. So this was my team:



Less Conference 2016 My team

The method worked pretty well and it was indeed good for introductions to new people. The actual goal for the assignment wasn’t that clear so most teams lost quite a bit of time on discussions and a few teams dissolved entirely the next day. Yet, experimenting is also a foundation of LeSS so no harm there.

Owning versus Renting Your System – Craig Larman
The title sounds somewhat more relating to a car or house but it made quite an impact on me. When coaching and convincing people to adopt Scrum and to adhere to the rituals correctly you can really see the difference. Some teams start breathing Scrum and start coaching each other- yes and me – when things are not done properly. Stand ups are swift, the board is neat and people respect priority set by the Product Owner. Other teams, are never prepared for anything, forget Dailys when the Scrum Master is not around and follow the coach or Scrum Masters guidance a bit reluctant. The latter team is just Renting Scrum they don’t Own it, the first team does! Craig didn’t use this example, that’s just my reflection of the difference in my daily struggles.

Less Conference 2016 Craig Larman
The way to make people buy into an idea and letting them own it was the main thread in his talk. The Why (by Simon Sinek) is solid starter and he then used some more examples based on system theory to let people reach their own opinion and ideas about the way of working. In doing so people are coming up with a part of the solution and start owning it – bit by bit.

Memorable Quotes:

‘No more yak shaving’

‘Underpants gnome profit plan’

So..
The relaxing atmosphere and openness to experiment with the format was nice. Only downside was that it perhaps was a bit stretched and for me personally the last sessions of the second day lost some value. All in all it was very interesting and an excellent place to meet like minded people and increase your network and at the same time increase your knowledge!

Cheers,
– Sjors Meekels

Contributions & References

[1] Conference home: less-large-scale-scrum.com
[2] Program and slides less-large-scale-scrum.com/program.html
[3] Less: less.works
[4] Story of Yak shaving: sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html
[5] Origin of Underpants gnomes: www.youtube.com/watch?v=tO5sxLapAts
[6] Impact Mapping (Gojko Adzic): github.com/facilitation-games/revenue-stream-map

Filled Under: agile,scrum,software development Posted on: 5 September 2016

Leading Image

Scrum – Novice to Ninja

David Green combineert een academische achtergrond in Sociologie en Organisatiekunde met zijn ervaringen in het veld als engineer in het boek Scrum: Novice to Ninja. Het boek is gericht op organisaties die Web- en Mobiele applicaties maken en heeft de professional met relatief weinig ervaring in het gebruik van Scrum op het oog.

Het boek Scrum: Novice to Ninja is tevens het eerste boek wat David Green publiceert. Hij schrijft echter al geruime tijd online artikelen en is een ervaren software engineer. In zijn boek staat de introductie van Scrum centraal en bedient hij de onervaren professional die met Scrum aan de slag wil.

Het verschil met andere boeken die Scrum beschrijven is de specifieke focus op het ontwikkelen van Web en Mobiele applicaties. In hoofdstuk 1 legt Green uit waarom juist deze domeinen zich met uitstek lenen voor de inzet van Scrum. Zo zijn aanpassingen ter ondersteuning van nieuwe browsers of mobiele devices vaak erg urgent. Ook gewenste communicatie-uitingen vragen vaak om ad-hoc werkzaamheden.

De rode draad van het boek is de introductie van Scrum in het fictieve bedrijf WithKittens.com. In hoofdstuk 2 introduceert Green het bedrijf met haar belangrijkste betrokkenen in deze Agile transitie. Vanuit de ogen van bijvoorbeeld een productmanager, een designer of een engineer, laat hij zien wat de huidige motivaties en verwachtingen zijn. Deze persona’s zijn goed gekozen en geven een realistische doorsnede van veel voorkomende teamrollen in organisaties.

Het theoretische kader van Scrum is de boodschap van de hoofdstukken 3, 4 en 5. De beschrijving volgt een logische volgorde van de gedefinieerde rollen, rituelen en gehanteerde artefacten. Wat de beschrijving luchtig houdt, is de speelse manier waarmee het framework in de dagelijkse praktijk wordt gepositioneerd. Concrete dagbeschrijvingen in hoofdstuk 3 geven een informeel en praktisch overzicht van de activiteiten in het leven van een Scrum-practitioner.

In de hoofdstukken 6, 7 en 8 gaat het fictieve bedrijf concreet met Scrum aan de slag en komen de onzekerheden en pijnpunten bij de toepassing aan de orde. Met korte dialogen tussen teamleden en praktische voorbeelden laat Green zien hoe het Scrum spel gespeeld wordt.

Hoofdstuk 9 richt zich op het finetunen en omzeilen van veelvoorkomende problemen. De titel van het hoofdstuk doet vermoeden dat de oplossingen voornamelijk gericht zijn op Web en Mobiele teams. Echter de suggesties en tips zijn in ieder domein van waarde. Welk team is niet gebaat bij ge-timeboxte rituelen of een minimum aan interrupties na de start van een sprint?

Zoals in Scrum retrospectives gebruikelijk is, zo blikt ook Green in hoofdstuk 10 terug. De persona’s, waarmee we eerder kennis hebben gemaakt, kijken terug op hun ervaringen met het gebruik van Scrum. Zij reflecteren op hun eerste reserveringen en geven aan wat zij hebben geleerd. Het meest interessant zijn de overblijvende frustraties en de wijzen hoe de verschillende persona’s hiermee omgaan. Deze zullen voor ervaren Scrum practitioners bekend voorkomen en voor de beginnende professionals een waarschuwing zijn.



Hoofdstuk indeling:
1. Introductie van Scrum
2. Ontmoet het Team
3. Scrum Rollen
4. Scrum Rituelen
5. Scrum Artefacten
6. Het Scrum Contract
7. De levenscyclus van een Story
8. Werken met Scrum
9. Scrum voor Web en Mobile Team
10. Aanpassen aan Scrum

Green hanteert een ruime interpretatie van de officiële Scrum Guides en geeft er zijn eigen twist aan.
Een tekenend voorbeeld is het verschil in terminologie en zijn beschrijving van de Demo’s de Sprint Review in hoofdstuk 4. Is dat erg? Nee, zeker niet. Het geeft de lezer gewoonweg inzicht in de ervaringen en ideeën van de auteur. Het boek is hierdoor wel minder geschikt voor diegenen die zich willen voorbereiden op certificering als Scrum Master.

Conclusie: Scrum – Novice to Ninja is in toegankelijk Engels geschreven en geschikt voor iedereen met weinig ervaring met Scrum en zodoende een prima startpunt. De voorbeelden die de auteur projecteert op de medewerkers van WithKittens.com zijn uit de praktijk gegrepen en heb ik zelf bijna zonder uitzondering ervaren. Met 10 beknopte hoofdstukken in 160 bladzijden is het een prima boek om rustig in een weekend door te nemen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl. Aangezien het betreffende boek in het Engels is, is een Engelse recensie wellicht passender. Bij voldoende tijd zal ik hem alsnog vertalen.

Cheers,
– Sjors Meekels

Note in English

This book review is in Dutch and is also published on www.managementboek.nl. The book is in English so it would make sense to write an English review. Again, when I do have some spare time I will make a translation

Filled Under: agile,book review,scrum,software development Posted on: 17 July 2016

Leading Image

Dilbert saves the Agile day

It is amazing to see some of the comics made by Scott Adams are already more than a decade old and are still spot-on. Today I will use 4 of them and connect them with real live challenges that are happening in our daily routines creating software.

‘One Dilbert says more than a thousand words.’

1. Chairs and pants
Dilbert - Chairs and PantsDILBERT © 2013 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Silver bullets don’t exist. The same holds true for best – or good – practices embraced in Agile software development. Be aware if you are in a transforming organization and senior management pushes Agile forward to solve all kinds of problems. A few examples in which Agile or Scrum will not make your existing problems go away:
– The engineering workforce is not equipped for new projects and techniques.
– Management is not involved in your most relevant projects and is not managing or leading.
– There is no clear view on the product vision and roadmap or priorities.

Yes, often Agile working processes can help in solving these problems. Agile itself however, is not the solution to all existing problems.

2. Success of Agile just doesn’t depend on good engineers alone
Dilbert - Give me all FeaturesDILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

For organizations to become successful in their Agile adoption, it is good to perceive the roles of business representatives and Product Owners carefully. In my opinion the most underestimated role in Agile & Scrum is that of the Product Owner. Early adopters often appointed an experienced user or analyst as the Product Owner and focused most attention on the Development Team. Sometimes this pattern can still be seen today. In a few cases it worked fine. However, often the skills needed to be a good Product Owner are much harder to find than with a quick look around. The impact a good Product Owner has on the team’s productivity and in the end the value delivered for the organization is huge. So invest in training and coaching newbies or hiring experienced Product Owners.



3. Being Agile versus Doing Agile
Dilbert - Training Agile ProgrammingDILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

A lot of organizations have been in an Agile transformation for some years now. Probably a large part of those organizations claim they “Are Agile”. I guess it is more a question of perception than exact definition. In adopting a lot of Agile practices and converting existing teams into Scrum teams – or Kanban – it is easy to make that statement. But a genuine Agile organization is never ready, never stops learning and never stops adjusting. Do these organizations keep challenging their teams and product managers? Do they adapt their tools and engineering skills to new features and insights? Or have they adopted some practices and do they now keep using these for the next couple of years? A true answer might give the first sparkle to being Agile.

4. One more Agile myth
Dilbert - Agile Programming SpeedDILBERT © 2005 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

It is funny how some misinterpretations continue to happen. More productive teams may indeed be one of the results of a good Agile implementation. However, this does not imply that making the transition will get you there right away. No, transitioning to Agile means hard work and dedication. As in all transitions it is about two steps forward and one step back. There is not a general blueprint suitable for all organizations. So come up with a plan, skilled people and a lot of positive energy to start your company’s transformation.

5. Bermuda triangle of Agile
Bermuda TriangleThe last cartoon is not an original Dilbert comic but originated from Luca Minudel in 2011: https://www.flickr.com/photos/lucaminudel/6059269914/

Not all experienced project managers or hiring executives truly grasp the notion of Agile. Don’t let them fool you. One-way or the other, you cannot fix all attributes within an Agile project. At least part of the project needs to have a flexible angel, in either time, costs or preferably features. Yes, quality is in most projects not variable. For part of the features that are well understood and technically straightforward, it is okay to go for a fixed setup. Don’t get Bermudad all the way!

Sometimes I wonder if it would be possible to replace expensive managerial courses with just a good selection of these comics and start some honest reflection…..

[edit 2019] See Dilbert still struggles with Agile for new challenges and insights.
Or dive into the evolutiong of DevOps in DevOps: understanding the evolution.

Cheers,
– Sjors Meekels

Filled Under: agile,kanban,software development Posted on: 10 July 2016

Leading Image

Agile Project Management with Kanban

In zijn boek ‘Agile Project Management with Kanban’ deelt Eric Brechner zijn ervaringen met de introductie en het gebruik van Kanban bij het Microsoft Xbox platform. Hij borduurt voort op de groeiende populariteit van Kanban sinds 2010. Zijn doelgroep bestaat uit professionals van alle disciplines in software engineering met interesse voor praktische toepassing. Lezen en daarna zelf doen is zijn credo.

Voor sommigen zal de naam Eric Brechner bekend klinken, dat klopt. Eric Brechner is de auteur van het in 2007 verschenen boek ‘Hard Code’: een bundeling van interne columns over de softwareontwikkeling binnen Microsoft verschenen onder het pseudoniem I.M. Wright. Nu is hij terug met ‘Agile Project Management with Kanban’ en publiceert hij onder eigen naam. In zijn nieuwe boek staat het gebruik van Kanban bij zijn teams van Xbox bij Microsoft centraal.

Zonder er om heen te draaien wijst Brechner er in de inleiding op dat het boek bedoeld is voor professionals die geïnteresseerd zijn in een praktische toepassing van Kanban. Ben je op zoek naar meer achtergrondinformatie over de theorie en fundamentele uitgangspunten van Kanban, dan zijn er betere alternatieven.

  1. Brechner gebruikt het eerste hoofdstuk om het gebruik van Kanban in een organisatie te introduceren. Het is met name gericht op het overtuigen van management en bevat naast de argumentatie tevens een voorbeeldmemo ter ondersteuning.

  2. In het tweede hoofdstuk neem hij de lezer in 5 stappen mee in het opzetten van Kanban. Hij geeft voldoende informatie en handvatten om direct zelf aan de slag te gaan. Elegant kort is zijn vergelijking tussen Kanban-Scrum-Waterval en de wijze waarop deze technieken chaos beperken in stap 3 van het stappenplan. De uitleg over het gebruik van limieten aan Work in Progress en de werkwijze van het Kanbanbord is helder.

  3. De volgende hoofdstukken behandelen specifieke onderwerpen gericht op verschillende organisatorische kenmerken. Hoofdstuk 3 richt zijn pijlen op het halen van deadlines – een terugkerende uitdaging in softwareontwikkeling – en het informeren van management omtrent planning en de inzet van schattingstechnieken.

  4. Hoofdstuk 4 geeft een korte beschrijving van de introductie van Kanban bij een team dat de Waterval-methode gebruikt. Zonder grote verassingen neemt hij mogelijke weerstanden weg en focust hij zich met name op de voordelen van de transitie van Waterval naar Kanban.

  5. De inhoud van het volgende hoofdstuk roept bij Scrum-professionals een aantal vragen en vermoedelijk enige weerstand op, namelijk het vervangen van Scrum door Kanban. De voordelen van Kanban ten opzichte van Scrum zijn vrij summier beschreven. Brechner waardeert Scrum zeker, hij waardeert Kanban nog meer. Tekenend is zijn statement dat ‘Kanban de volgende evolutie van Scrum is’. Dit is natuurlijk, niet geheel onterecht, voer voor discussies met Scrum-aanhangers.

  6. Hoofdstuk 6 is redelijk technisch ingestoken en geeft een beknopte beschrijving van de inzet van verschillende branching, versioning en deployment strategieën. De interessante link met Kanban zijn de aanpassingen die hij inzet op het Kanbanbord en de gehanteerde flows.

  7. Het opschalen van Kanban naar grotere organisaties, zoals Microsoft, vraagt om extra aanpassingen. Aan dit onderwerp besteedt hoofdstuk 7 aandacht. Brechner tackelt bekende problemen bij opschalen zoals communicatie en afhankelijkheden tussen teams. De verschillende manieren om volgordelijkheden tussen teamactiviteiten inzichtelijk te maken zijn naast leerzaam, ook zeker in andere Agile-frameworks toepasbaar.

  8. Hoofdstuk 8 is geschreven door James Waletzky, een ervaren software engineer die voorheen werkzaam was in de Xbox teams. Hij beschrijft de integratie van het werken aan bugs met de doorontwikkeling van een product. Deze twee aspecten staan vaak op gespannen voet, vandaar de extra aandacht in een apart hoofdstuk. Voor diegenen die in productdevelopment werkzaam zijn, zijn de ‘troubleshooting’ voorbeelden zeer herkenbaar.

  9. Het laatste hoofdstuk, behandelt uitbreiding van Kanban met andere methodes en technieken zoals Lean, Theory of Constraints of Critical Chain. Dit hoofdstuk is met name bedoeld voor meer ervaren teams die de basisflow in de vingers hebben en zoeken naar verdere optimalisaties.


Per hoofdstuk zijn praktische checklist toegevoegd en bij een aantal hoofdstukken zijn interessante vraag-antwoord voorbeelden opgenomen. Met name de voorbeelden bereiden de lezer voor op vragen van mogelijke klanten, managers of teamgenoten. Nuttig om te weten is dat de rekenvoorbeelden en het genoemde memo online beschikbaar zijn. Hiermee heeft de lezer direct één op één de voorbeelden uit het boek te pakken.

Brechner’s achtergrond als engineer verklaart wellicht het veelvuldig gebruik van checklists, tips, formules en voorbeelden. Hoewel de gebruikte formules en voorbeelden niet complex zijn, lees je dit boek waarschijnlijk niet in één adem uit. Dat hoeft ook niet. De gekozen opzet, met hoofdstukken gericht op specifieke situaties, geeft de lezer de mogelijkheid snel door te bladeren naar de voor hem of haar relevante onderdelen.

Heb je behoefte aan een praktische leidraad in Kanban of ben je nieuwsgierig naar het ontwikkelproces bij een top gaming platform & multinational zoals Microsoft – dan ben je met Agile Project Management with Kanban aan het juiste adres.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl. Aangezien het betreffende boek in het Engels is, is een Engelse recensie wellicht passender. Bij voldoende tijd zal ik hem alsnog vertalen.

Cheers,
– Sjors Meekels

Note in English

This book review is in Dutch and is also published on www.managementboek.nl. The book is in English so it would make sense to write an English review. Again, when I do have some spare time I will make a translation

Filled Under: agile,book review,kanban,scrum,software development Posted on: 21 June 2016

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.

Conclusion

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.

Cheers,
– Sjors Meekels

Contributions & References

[1] Prince2: http://prince2.wiki
[2] Mythical Man Month, F.P. Brooks: www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary
[3] Agile Project Mngmnt for Dummies, M.C. Layton: Agile-Project-Management-For-Dummies
[4] Simplicity: agile-principle-simplicity-the-art-of-maximising-the-work-not-done
[5] JBGE Just Barely Good Enough, Scot Ambler: agilemodeling.com/essays/barelyGoodEnough.html
[6] Changeability: en.wikipedia.org/wiki/ISO/IEC_9126
[7] Agile Manifesto: www.agilemanifesto.org
[8] ScrumGuides: scrumguides.org
[9] Failing Agile- InfoQ: www.infoq.com/articles/agile-fails-enterprise

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

Leading Image

Scrum wegwijzer – Gunther Verheyen

In 20 jaar tijd heeft Scrum zich bewezen en gevestigd als het de-facto standaard framework in het vakgebied van softwareontwikkeling. Ondanks dit grote succes bevinden veel organisaties zich nog volop in de Agile transitie. De ervaren professional in het veld heeft een blijvende behoefte aan een goed beknopt overzicht van het populaire framework. Voor beide doelgroepen is het boek Scrum wegwijzer – Een kompas voor de bewuste reiziger een handig hulpmiddel in hun reis door de wereld van Scrum.

In 2013 schreef Gunther Verheyen al het Engelstalige boekje Scrum Pocket Guide. Nu, drie jaar later, heeft hij een opgepoetste Nederlandse vertaling hiervan uitgebracht onder de titel Scrum Wegwijzer – Een kompas voor de bewuste reiziger. Verheyen zelf is momenteel werkzaam bij Scrum.org en bekend in Nederland en daarbuiten in het Agile werkveld als trainer, auteur en consultant.

In een kleine 90 bladzijden neemt hij de lezer in vier heldere hoofdstukken mee vanuit de oorsprong van Scrum naar de regels van het Framework zelf, gevolgd door de toepassing ervan. Het boek sluit af met een korte beschouwing over de toekomst van Scrum.

Hoofdstuk indeling:
1. Het Agile Paradigma
2. Scrum
3. Technieken versus regels
4. De toekomst van Scrum

De start van het Agile denken en de noodzaak om af te stappen van oude denkbeelden in de aansturing van kenniswerkers dient als basis voor hoofdstuk 1. Zonder af te dwalen schetst Verheyen de belangrijkste problemen en uitdagingen bij het invoeren van een Agile werkwijze. Met name de statements dat Agility geen eindtoestand is en een transitie niet is te plannen, zijn prikkelend.

In hoofdstuk 2 positioneert de auteur Scrum als een spel wat gespeeld wordt met als doel optimale controle te houden over software-ontwikkeling in turbulente omstandigheden. Net als bij andere spellen gelden regels waaraan alle deelnemers zich dienen te houden. Hoewel er niet veel regels zijn, vereist Scrum een grote discipline van de spelers. De opbrengst van deze regels en discipline is een ongekend potentieel aan motivatie, zelfsturing en probleemoplossend vermogen binnen de Scrum teams.

Nuttig en voor veel lezers wellicht een eyeopener, zijn de voorbeelden in hoofdstuk 3 van de verplichte regels ten opzichte van mogelijk inzetbare technieken. Juist de ruimte die teams hierin zelf kunnen nemen, biedt inzicht in de kracht en aanpasbaarheid van Scrum. Geregeld trappen meer ervaren professionals in de valkuil dat ze denken dat zaken ‘worden voorgeschreven’ vanuit Scrum. Enkel en alleen omdat ze bepaalde technieken in meerdere projecten hebben toegepast. Verheyen laat haarfijn zien waar de grenzen van de regels en de vrijheden zich in het spel bevinden.

Aan het eind van hoofdstuk 3 zijn enkele paragrafen gewijd aan het uitschalen van Scrum naar een groter verband, naar bijvoorbeeld meerdere teams of producten. Opvallend is dat bekende scaling frameworks als DAD, SAFe en LeSS ontbreken en zelfs Nexus, een initiatief vanuit Scrum.org, geen plek heeft gekregen. Wellicht is dit een bewuste keuze van de auteur. Een keus die in ieder geval zorgt dat de focus goed gericht blijft op Scrum.

In het laatste hoofdstuk geeft hij een korte verwachting van de ontwikkeling die Scrum de komende jaren in organisaties gaat maken. Stroomopwaarts, zoals hij het noemt, heeft Scrum de potentie om developmentteams te overstijgen en ook toepassing te vinden in management, productontwikkeling en zelfs in hele organisaties.



Het boek is vlot geschreven en laat zo nu en dan de raakvlakken zien met andere Agile frameworks. De kracht van het boek is echter gelegen in de sterke focus op de spelregels van Scrum. Door de beknopte schrijfstijl en het feit dat het boek Nederlandstalig is, is het zeer toegankelijk voor zowel de beginnende Scrum-enthousiasts als de meer ervaren professional of manager die zijn parate kennis wil opfrissen. Een boekwerk wat zich prima in een avond laat uitlezen en inzichten geeft om er daarna concreet mee aan de slag te gaan!

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl. Aangezien het betreffende boek in het Nederlands is, is een Engelse recensie niet direct passend. Bij voldoende tijd zal ik hem alsnog vertalen.

[edit 2019] Gunthers tweede editie is verschenen in het Engels, de Engelse review hiervan kun je hier vinden.

Cheers,
– Sjors Meekels

Note in English

This book review is in Dutch and is also published on www.managementboek.nl. Due to the fact that the book is in Dutch it did not make a lot of sense to write an English review. However an earlier version was released in 2013 and that was indeed in English. It was called Scrum – A Pocket Guide and is still available as well. If time permits I will also translate my review…..

[edit 2019] Gunthers’s next edition is in English and I gave it an English review, you can find it here.

Filled Under: agile,book review,scrum,software development Posted on: 22 May 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…

Cheers,
– Sjors Meekels

Contributions & References

[1] AgilePM: http://www.apmg-international.com/en/qualifications/agile-pm/agile-pm.aspx
[2] Prince2 Agile: https://www.axelos.com/best-practice-solutions/prince2/prince2-agile
[3] Definition Principle: http://dictionary.cambridge.org/dictionary/english/principle
[4] Prince2: https://www.prince2.com
[5] Prince2: https://en.wikipedia.org/wiki/PRINCE2
[6] Agile Manifesto: http://www.agilemanifesto.org
[7] ScrumGuides: http://scrumguides.org/

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.

Conclusion

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.

Cheers,
– Sjors Meekels

Contributions & References

[1] Leading image: 3d-systems-project-ara-high-speed
[2] Origin of 10X: 10x Software Development – Origins of 10X
[3] Clean code: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship
[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.

Management
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.



Agile
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.

Combined
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.

Cheers,
– Sjors Meekels

Contributions & References

[1] Heading image: by Evan-Amos (Own work), via Wikimedia Commons.
[2] The illustrious Vic20: https://en.wikipedia.org/wiki/Commodore_VIC-20.
[3] Nice collection of programming assignments: https://www.reddit.com/r/programmingbydoing.
[4] Information about Clean: http://clean.cs.ru.nl/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.

Fail and letting fail

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

Learn from anybody

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