Category / agile

by Frederik

Vergaderen

Vergaderen… het is standaard in een organisatie, en in de business wereld. Iedereen vergadert toch? En als je iemand iets wilt vragen, of je hebt iets nodig van een collega, dan plan je toch een vergadering?

meetingitis

An excessive propensity to hold unnecessary meetings.

Hoe vergroot je dan de effectiviteit en productiviteit van vergaderingen? Heb je telkens nood aan een vergadering? Hier bewuster over zijn, kan je al een grote stap vooruit helpen en de situatie verbeteren!

De effectiviteit en productiviteit van een vergadering verhoog je door

  • een goede voorbereiding
  • de vergadering faciliteren
  • een goede follow-up

Voorbereiding van de vergadering

4 P’s van een vergadering

Vooraleer een zaal te boeken en mensen uit te nodigen, denk na of de vergadering nodig is!

Een alternatief is op mensen toe stappen voor een conversatie wanneer die in de buurt zijn en die je kan/mag storen (eerst vragen natuurlijk)! Denk voor het plannen van een vergadering aan de 4 P’s (4 P’s als geheugensteuntje) – dit is voor een vergadering die je wilt organiseren.

  • Persons/Participants: wie zal er de vergadering organiseren/faciliteren/leiden en wie zijn de personen die actief kunnen bijdragen en die je vervolgens zal uitnodigen?
  • Purpose: wat is het doel van de vergadering? Zijn de beweegredenen of motivatie duidelijk die het bijeenbrengen van personen in een vergadering verantwoorden?
  • Process: welke facilitatie processen zal je toepassen voor de vergadering, in functie van het doel? Er bestaan verschillende facilitatie technieken, die je kan gebruiken in eender welke vergadering. Het is interessant om meer interactie en dynamiek te brengen in een vergadering, buiten de standaard presentaties (1 persoon bepaalt het verloop) of brainstorming (iedereen bepaalt het verloop).
  • Product: Wat is het “product”, de output van de vergadering? Wat willen we bereiken? Dit hangt uiteraard vast met het doel van de vergadering en bepaalt ook wat de output (“deliverable”) zal zijn.

Agenda van een vergadering

De agenda van een vergadering opmaken is deel van de voorbereiding. Maak een agenda die duidelijk en uitnodigend is!

Maak duidelijk:

  • Wie wat zal faciliteren
  • Wie notities zal nemen tijdens de vergadering (hoeft niet steeds de organisator te zijn!)
  • Wie een follow-up zal doen (kan per agendapunt)

Voor elk agendapunt kan je beschrijven:

  • De motivatie (noodzaak) om te bespreken
  • De verwachtte uitkomst
  • Wie verantwoordelijk is
  • Eventuele voorbereiding
  • Tijd verwacht te spenderen
  • Het proces

Bij “proces” is het nuttig om een onderscheid te maken tussen “bespreking” en “beslissing“. Wanneer het niet duidelijk is in een vergadering wat de verwachtte output is (en daarmee bijhorend proces om daar te raken), is dit vaak een oorzaak van frustratie:

  • Deelnemers die denken dat er een beslissing nodig is, raken geërgerd omdat de andere deelnemers enkel verwachten te “bespreken”.
  • Deelnemers die denken dat het enkel een bespreking betreft, raken geërgerd omdat de andere deelnemers op een beslissing aansturen.

Tip: indien je merkt dat de deelnemers niet op voorhand de agenda bekijken (m.a.w. blindelings de vergaderuitnodiging accepteren) kan je werken met een agenda die uitnodigt d.m.v. het stellen van vragen in de agenda. De vragen zijn een trigger om na denken over de verwachting van de vergadering en eventuele voorbereiding.

Een vergadering faciliteren

De facilitator is de “gardener” en “guard” van de vergadering; een facilitator hoef niet noodzakelijk inhoudelijk bezig te zijn. Een facilitator zorgt ervoor dat:

  • elke persoon gelijkwaardig kan deelnemen
  • zorgt voor ruimte en tijd voor elke agendapunt en houdt de timing per agendapunt in het oog
  • faciliteert het bijhorend proces per agendapunt (is het een bespreking/verduidelijking? hebben we een beslissing nodig? wat is het actiepunt? wie doet wat wanneer?)
  • faciliteert een evaluatie van de vergadering op het einde (en zorgt ervoor dat dit kan gebeuren, door hier tijd voor te voorzien, of paar minuten voor officiële einde van het vergadertijdsslot een evaluatie te faciliteren)

Facilitatie technieken

Ronde

In een vergadering, ga rond in een cirkel zodat elke deelnemer de kans krijgt op zijn/haar beurt te spreken.
Het faciliteren in een cirkel zorgt ervoor dat elke deelnemers als gelijkwaardig beschouwd wordt, en ondersteunt effectieve dialoog.

Als facilitator, kan je kiezen om elke ronde met een andere persoon te beginnen, om variatie te brengen in wie er als eerste en wie er als laatste spreekt.

Check in

In een check-in rondje krijgt iedereen de kans om kort te benoemen wat er leeft, om zo vollediger aanwezig te kunnen zijn. Dit helpt ook om gedachten te ordenen en met meer focus aan een vergadering te beginnen!

Check-in betekent dat je (heel) kort met de groep deelt wat er momenteel gebeurt met jezelf, hoe je aanwezig bent, daarbij jouw gedachten, gevoelens, afleidingen en noden kenbaar maakt.

Als facilitator, verplicht nooit iemand! Een deelnemer kan een check-in overslaan. Dit kan bij start van de vergadering gebeuren, of bij een 1 on 1 voorafgaandelijk.

Evaluatie

Zorg voor een korte evaluatie op het einde van elke vergadering. Het doel is om feedback te verzamelen hoe de vergadering verlopen is en punten voor verbetering te delen.

Korte evaluatie

  • fist-of-five”, elke deelnemer geeft gelijktijdig aan wat je vond van de vergadering (van 1: heel slecht, tot 1: heel goed) meer/minder
  • starten/stoppen/houden
  • positief/kritisch/suggestie voor verbeteringen

Langere evaluatie (voor een workshop, sessie, …)

Retrospectief formats om te evalueren:

  • Effectiviteit en format
  • Facilitatie en voorbereiding
  • Emotionele toon
  • Appreciaties en prestaties (Ik vond goed…)
  • Wilde ideeën en radicale suggesties (Wat indien…)

Facilitatie technieken

Bron voor facilitatie technieken (kleine en grote groepen)

Facilitatie technieken maken vergaderingen interactief en dynamisch, voorbeelden van technieken:

Kanban

Voor recurrente vergadering is een backlog en een kanban aangewezen, enerzijds om de lijst van items continue te prioriteren (backlog) en

anderzijds om een visueel overzicht te behouden (kanban).

Governance backlog

Gebruik naast de product backlog (werk te doen voor ontwikkeling van het product) ook een aparte backlog voor beslissingen (“governance”). Governance is het voortdurend beslissen over wat er nodig is om doelen te bereiken en binnen welke grenzen dat werk hoort plaats te vinden. Te bespreken, te beslissen items kan je op een governance backlog plaatsen.

Op organisatie niveau is het ook handig om organisatie brede items zichtbaar te houden op een (goverance) backlog.

by Frederik

Modern Agile

Why Modern Agile?

Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.

World famous organizations like Google, Amazon, AirBnB, Etsy and others are living proof of the power of these four principles. However, you don’t need to be a name brand company to leverage modern agile wisdom.

What is Modern Agile?

“Modern Agile is a community for people interested in uncovering better ways of getting awesome results. It leverages wisdom from many industries, is principle driven and framework free.”

— Joshua Kerievsky, CEO, Industrial Logic.

Modern agile is the result of courage, feedback, simplicity, communication, and respect for people.

4 guiding principles

Modern Agile has 4 guiding principles:

Make Users Awesome

Make Safety a Prerequisite

Experiment & Learn Rapidly

Deliver Value Continuously

 

These principles unfold (expand) in many practices! These are not only applicable to software development.

Who is Joshua Kerievsky?

Joshua is the founder and CEO of Industrial Logic, a pioneering Extreme Programming/Lean consultancy that radically improves the software development capabilities of organizations around the globe.

In the mid-1990s, Joshua was among a small community of “lightweight methods” practitioners experimenting with better ways of developing software. Since then, he’s helped thousands of people across hundreds of organizations learn better ways of making software, carefully reviewing and revising methods with the greatest impact and return on investment. Today, he leads an effort to modernize Agile by removing outdated practices and leveraging the best of what the software community and other industries have learned about achieving awesome results. Modern agile practitioners work to Make People Awesome, Make Safety A Prerequisite, Experiment & Learn Rapidly and Deliver Value Continuously.

Joshua is an international speaker and author of the best-selling, Jolt Cola-award-winning book, Refactoring to Patterns, numerous Agile eLearning courses, and popular articles like Anzeneering, Sufficient Design and Stop Using Story Points.

He’s active on Twitter, Snapchat and the emerging ModernAgile.org community.

Learn more about ‘Modern Agile’

–> videos by Joshua Kerievsky on YouTube

–> keynote talks by Joshua Kerievsky

–> Podcast with Joshua Kerievsky: http://agileuprising.libsyn.com/joshua-kerievsky-modern-agile

by Frederik

The Role of the Scrum Master

I’ve stumbled upon this list, and I like it – as it clarifies again a bit the role of the Scrum Master.

Source: https://age-of-product.com/70-scrum-master-theses/

  • Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario — just practices that have worked before in other organizations.
  • Successful practices of other organizations cannot simply be copied to your own. Every practice requires a particular context to work.
  • You need to determine for yourself what works for your organization — which is a process, not a destination.
  • The role of a scrum master is primarily one of leadership and coaching. It is not a management role.
  • A scrum master should recognize that different stages of a scrum team’s development require different approaches: some, teaching; some, coaching; and some, mentoring.
  • A scrum master should be familiar with the Shu-Ha-Ri concept of learning new techniques.
  • A scrum master’s principal objective should be to remove themselves from daily operations by enabling the scrum team to be self-organizing and self-managing.
  • Being a scrum master does not entail, and should never entail, enforcing processes.
  • Scrum is not designed for bean counters, although some metrics are helpful in understanding the health of a scrum team. Generally, insisting that the team achieve specific KPI (for example, commitments vs. velocity) does not help.
  • Scrum doesn’t elaborate on the process that enables a product owner to add valuable, usable, and feasible user stories to the product backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX methodologies may help, but in any case, a good scrum master will want the scrum team to be a part of this process (whether participating in user interviews or running experiments).
  • A scrum team’s communication with stakeholders should not be run through a gatekeeper (e.g., solely through the product owner) because this hurts transparency and negatively affects the team’s performance. Sprint reviews, conversely, are a good way to stay in close contact with stakeholders and to present the value delivered by the team during each previous sprint.
by Frederik

Done!

The most crucial sprint objective in Scrum is to deliver a DONE product increment – a piece of working software delivering value for the end-user. That is the goal today and always has been the goal.

In a context in which multiple Scrum teams work on the same product, it’s the goal – and only goal –  to deliver each (and every) sprint an integrated product increment – so no UNDONE work left at the end of the sprint.

How do you define DONE?

Scrum does not define what “done” means for a product – that’s to be determined by the development team.

Yet the goal is to get better and raise the bar to deliver a piece of valuable working software at the end of each sprint.

With the support of the Scrum Master, the development team improves their practices at a steady pace to be able to reach that goal.

The Scrum Guide says:

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.”

Unfortunately, we observe that many Scrum teams (or teams saying to practice Scrum) cannot deliver a done product increment at the end of each sprint. Some teams do not care and finish the work till done at the next sprint. In the world of software development, this means a piece of working software (end to end) ready to be used by a customer (end-user).

The output at the sprint has been called a potentially shippable product increment. Some teams interpreted this as “the product increment is ready to be shipped, but actually, there’s still some work to do to release it to the customer”. That’s not the point.

That’s why the Scrum Guide says:

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.”

A lesson from Scrum history

Jeff Sutherland and Ken Schwaber, – the creators of Scrum, have been updated the Scrum guide over time. It’s interesting to read how there was more detail about what done means and what to do with “undone” work in previous versions of the Scrum guide. In general, some artefacts and pieces have been left out to make the description of Scrum as a framework more simple, clear to understand, and lightweight.

From Scrum Guide, version 2009:

A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization.

You get the picture that “done” includes all the work necessary to have a piece of releasable, valuable software at the end of the sprint.

It continues:

“Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.”

Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.

Take care. The current Scrum Guide does not specify a “release sprint” as a practice. This is similar to the “hardening” sprint defined in – for example – the Scaled Agile Framework. The goal – and only goal is to create a done product increment at the end of each sprint. In Scrum, this is considered a bad practice. “Undone” work piles up and increases risks and delays.

The word “undone” is not mentioned anymore in the current version of the Scrum Guide.

A perfect definition of done

Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) do explicitly mention “undone” work – in larger organisations. There are often whole teams (e.g. an “operations” team, a “services” team) or whole departments (“operations” department) or people (“release manager”) existing which are to be considered part of “undone” work if this cannot be done as part of the sprint (and it often cannot be done within a sprint).

A perfect definition of “done” implies that each product increment is

  • valuable
  • immediately releasable to the end-user

And that should be the goal of perfection.

To be able to achieve this as a team, the effort is necessary to invest in:

  • software craftsmanship
  • automated testing
  • continuous integration
  • deployment automation

without sound technical practices, it’s pretty impossible to accomplish this on any scale (small or large).

Do not make a mistake. This is quite a challenge for many teams who (try to) practice Scrum.

According to the rules stipulated in the Scrum guide, all variants on Scrum who do not achieve the actual state of “done” product increments are not to be considered Scrum teams.

What does done means in software development?

I quote this from – Ken Schwaber – and any software development team should adhere to these (working in Scrum or not)

The result should include software that has:

  • Presence of valuable functionality for customers to use;
  • Absence of low value functionality that must be maintained and sustained regardless;
  • Quality code base to predictably maintain and sustain;
  • Quality code base to enhance without undue effort or risk;
  • Ability to catch defects early and no later than at release;
  • Predictability of schedules; and,
  • A Lack of surprises.

Which raises the question, what is quality software?

It has these characteristics:

  • I can readily understand the software and where & how things happen;
  • When I change or add to part of the software, there are no unintended or poorly designed dependencies;
  • I can read the code without looking for tricks or poorly defined and labeled variables or data;
  • I don’t need the person(s) that wrote the code to explain it to me;
  • There are a full set of (automated) tests to check that the function works as expected;
  • When I change something and add to the tests, I can check that the entire change and product continues to work;
  • How things work and hang together is transparent;
  • Standard, well-known design principles have been adhered to.

Source: Quality, Done Increment

Keep on improving!

by Frederik

Agile Transformation is a strategy, not a goal.

I came across an interesting article on InfoQ, it’s titled “Transforming from Projects to Products“. If you want deeper understanding on topics, InfoQ offers descent and great articles. So I’d like you (someone in any position who plans or is part of an “agile transformation” to read this).

Excerpts of the article:

The general understanding and perception of “Agile” or “agile”

” ‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.”

In fact, each company or organisations should be concerned to become more agile (as defined in the dictionary), this is a matter of sound principles and ‘common sense‘ (for example: eliminate waste and become more effective in what you do – certainly in software development / product delivery there are many ways to achieve this).

If an agile transformation is not an end-goal, what is the goal?

Organisations shouldn’t embark on a mission to become agile, without understanding what it takes in terms of cultural and organisational changes – and most importantly: figure out what they want to achieve – why do you need a change?

Questions to be asked:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process?

As you notice these questions which concern the whole organisation. Any initiative for improvement should be looked at globally – at an organisational (systems) level – in order to avoid local optimisations.

  • What are the major areas of improvement?
  • Transform from projects to products, including:
    • Stop managing, and start leading
    • Shift from “output” (deliverables), to focus on “outcomes”
  • Embrace the idea there is (and will be) uncertainty, instead of fighting it.

“Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.”

  • Reward people based on contribution to a common goal, instead of individual performance

Changing from:
“What will I do today?” to “What can I do to help the team towards our goal today?”
can make a huge difference to behaviour.

Common understanding why we want to change as an organisation

“Your business should be saying:

  • Where do we need to improve?
  • and how will we measure success?

Agile transformation may be a means of reaching that goal.

“If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow.  By empowering teams to make decisions for themselves you can create an environment of continuous improvement.”

Read the full article at InfoQ.

and recall:

https://www.pinterest.com/pin/2674081007173724/

Image source: https://quickscrum.com/Images/article_detail/Whyagiletransformationisdifficult-1.png
by Frederik

The Agile landscape – should we care?

Yes, “agile” is an umbrella term, the word was chosen by the signatories of the agile manifesto. Who-ever would be referring to the agile method, doesn’t understand what agile refers to.

The existence of many agile methods, frameworks and approaches (no, Scrum is not the only agile method) for single teams and multiple teams illustrates the continuous journey of exploring and uncovering new and better ways of developing products. And that’s a good thing, isn’t it? It would be worrying if the whole world would agree for a single method or way of working.

Illustrations as the one below show the diversity of methods in the whole “agile” landscape.

agile-landscape

Some thoughts…

Continue reading →

by Frederik

Agile Manifesto Values add-on for large enterprises

We are uncovering better ways of working in large enterprises by doing it and helping others do it.

We value:

Delighting Customers First over Shareholder Returns First

Focusing on Delighting Customers First leads to Shareholder Returns

Enterprise-Wide Agility over Agile for Software Development only

Optimise for flow, learning and feedback along the whole value stream

Empowered Product Teams over Command & Control Role based Work Passing

Long live teams with high Alignment, Autonomy and Safety aligned to value stream

Achieving Big through Small over Achieving Big through Big

Small teams, hypothesis-driven investment, optimise for flow, for better outcomes faster

 

That is. We used to value to things on the right, we now value the things on the left more.

 

Source: https://medium.com/@jonathansmart1/agile-manifesto-values-add-on-for-large-enterprises-f3fdc1abcd65#.wtautdxcw

 

by Frederik

Evolution of the Agile Manifesto

Team vision and discipline 
over individuals and interactions (or processes and tools)

Validated learning 
over working software (or comprehensive documentation)

Customer discovery 
over customer collaboration (or contract negotiation)

Initiating change 
over responding to change (or following a plan)

 

Source: http://www.startuplessonslearned.com/2010/05/thank-you.html

by Frederik

Work Expo – Management 3.0

How to visualise a purpose? How to share a vision? How to tell your story? Often, organisations have a vision and a mission statement (for their organisation, product, team), but words don’t convey the message. What you should do is show, don’t tell!

Sharing a vision
Sharing a vision

Create an exposition of the work you’re doing (in your team, in your department, or even individually). When you can create an excellent exposition about your work, you have likely found and visualised your purpose (Management 3.0 Work Expo).

Continue reading →
by Frederik

Celebration grid – Management 3.0

“Insanity is doing something over and over again and expecting a different result.”

Insanity is doing something over and over again and expecting a different result. If you evaluate objectively what you’re doing – over and over again – and you’re not satisfied with the output – why would you keep repeating it? Humans are creatures of habit and routine. If you’d like to change something in your routine, you should focus on small and incremental changes. How does this work in groups of people? At home… , at work? We would like to improve our behavior and practices, but the daily routine often prevents us.

Continue reading →

by Frederik

Personal maps – Management 3.0

Are you all professional at work? No chit chat, no small talk, not sharing personal stuff? Well, you’re not the only one. In most projects and environments I’ve worked, there’s not much sharing of personal things, and the most “coffee talk” I hear is about work-related topics. Then again, I asked how my colleague’s weekend was, and if anything special happened?

Frankly, do you know your colleagues, your teammates?

Continue reading →