Skip to content

Feed aggregator

BA's on Agile Projects?

Leading Answers - Mike Griffiths - Sun, 01/01/2017 - 20:40
The role of the business Analyst (BA) on agile projects in some ways parallels the role of the project manager (PM). In that, some people believe these roles are not needed at all! The Scrum Guide, for instance, that outlines... Mike Griffiths
Categories: Blogs

New Role with RMC Learning Solutions

Leading Answers - Mike Griffiths - Sat, 12/31/2016 - 20:28
I have taken on an exciting new part-time role with RMC Learning Solutions as their Agile Practice Lead. I worked with RMC to create my PMI-ACP Exam Prep book and their ACP training offerings. So, I am really looking forward... Mike Griffiths
Categories: Blogs

Planning as a social event – scaling agile at LEGO

Henrik Kniberg's blog - Fri, 12/30/2016 - 14:59

The past couple of years I’ve been travelling back and forth to LEGO’s HQ in Billund Denmark, helping out with their agile journey. Super interesting! Learned more than we could ever fit in an article, but here’s an attempt to capture at least some of it, written together with LEGO colleague and co-instigator Eik Thyrsted Brandsgård. Enjoy!

Planning as a social event – scaling agile @ LEGO

Agile @ Lego

 

Categories: Blogs

The Cost Of Fear


We need reassurance. Therefore we plan. There are situations, mainly in our personal life, when we recognise that our plans are just wishful thinking. Sometimes we are so sadly skeptic about our bold plans that we cut ourselves from our dreams. Then comes the professional life. Here, on the opposite, we often push ourselves in an extreme state of denial and believe that our wishful thinking plan is the only acceptable reality. If a little inner voice tells us that universe may care little about what our view of acceptable reality is, we seek ways to obtain some extra-reassurance via extra-plans: we perform risk management, estimation of time to complete tasks … and other complex expert analysis on everything-that-could-happen-in-the-future. All these tasks we need to reinforce our self-reassurance about our ability to control the future, have a cost. I call it the cost of fear.The (Agile) Change: from Intention to ActionOrganisations today aim to change toward a more collaborative, customer-centric, flexible format. Leaders have a genuine intention to create an Agile organisation, where people thrive, are allowed to wrong, as long as they learn from their errors:experimentation will the new way. This is the dream, the quest, the purpose. Then, as in all stories the tension between the intention and the status quo steps in. Stories of change have the same pattern than all stories :).Let's look a little bit at what can bey the impact of the status quo on the aspiration fo change.Peter Senge says that true tension is born when the theory exposed (what I aspire for) is different of the theory in action (what I actually do). There is no problem with this tension; as long as it acknowledged, learning can occur and effective alignment between the exposed theory and the theory in action can be achieved. Peter Senge, in his book, The Fifth Discipline, who is for me the father of system thinking - says that tension is an opportunity for learning.If you're familiar with coaching terms, seeking alignment between intentions/speech and actions is called "congruence". So far, so good, and how can be the Nirvana of congruence be achieved?I believe that there is only one magic formula to address the gap: becoming aware of it. Is this easy?No! Why? Because we have a genuine state of denial that makes uns think that as long as we believe in what we say we'll do, means that whatever we will do is in harmony with what we say we'll do. 
Our first trap is trying to achieve change with tools of our status quo.One common example is "planning the change". We believe planning is "a professional attitude", when  it's only utility is to reassure us.  Farer we are of our comfort zone, more we need to be reassured. And here is the gap where the cost of fear sneaks in: the gap between the needs of the ecosystem (market, customers, teams, organisations) and the natural need of leaders to control their ecosystem.
Here are some of the sources that sum-up as important costs for organisations and that I call "the cost of fear" Continuous planning vs continuous delivery Planning as a reassuring activity that addresses fear of not controlling was already mentioned above. Over planning need stakeholders and teams to be involved and spend (sometimes) an impressive amount of time in planning meetings. While planning is happening, decision to deliver is deferred.While planning is on the agenda, value does not reach customers. The cost of fear is the cost of continous planning
Ongoing estimation and frozen development What about a team  more that 10 people focused on estimating backlog's User Stories for 6 weeks in a row? Meanwhile PMOs, Project Directors, CxO people and other coordinators spend at leas half of their time taking decisions on how the future will look like when the estimation will be done. No development or delivery happens before leaders are reassured with a number (estimation).The value of an approach like NoEstimates, domain where Vasco Duarte and Woody Zulli have had major contributions), lies also in reducing the delay to deliver.While estimation is ongoing, no value reaches customers. The cost of fear is the cost of ongoing estimation.
Risk Management vs Emerging Architecture
Locking our options in early decisions about architecture of our future product is another way we address our need of reassurance that the future will behave as we decide it.  Personally I still recover of  IT architecture committees I've been in years and years ago ;). The protocol is the following : a lot of talented experts meet to analyse all the risk of the future and address them with a list of operational actions and or adequate design. Usually these Risk Management committees end-up with a deferred decision as a new risk revealed in the just closed committee has to be addressed and discussed over in the next one. The only decision is to defer decision£.While analysing risks,  no solution is emerging and no value  reaches the customer.The cost of fear is the cost of focusing on risk management.

The Cost of fear, a systemic description
System have self-regulating actions called feed-back loops. The feed-back loops are rather reinforcing : system behaviour is reinforced by the feed-back loop- The Cold War period is an example of a system within a  a reinforcing loop - or balancing: system behaviour is regulated to stay in given boundaries.
I think the cost of fear is causing a reinforcing loop that leads to growing frustration of leaders and increasing organisation bureaucracy.
How to reduce the cost of fear?Well, my part of the answer is in the title of the paragraphs above, and to pit it in only one word it is : Experiment! Experiment has some magic powers for two reasons. One is that  triggers a mindset where we know we are allowed: to try, to be wrong.The second is that it puts organisations on a learning path, that addresses the systemic nature of an organisation. And by the way, true learning is fun,  true food that keeps our brain happy.
Principles that (may)  reduce the cost of fear
  • Deliver a prototype rather than plan,
  • Define a team capacity rather than estimate tasks 
  • Drive by emerging design (helpful reference in Alexandru Bolboaca's work)  rather than performing risk management.

The cost of Delay is included in the cost of fear, as we don't act until we are reassured.
Okay, this looks like reduce cost-of-fear just-to-try-principles cheat-sheet.  It's not enough. An additional question to answer is  "How to address the fear that generates these costs?". And this is the most tricky question. Fear is the strongest symptom that some basic needs are not met. Just telling leaders/managers/architects/teams/stakeholders/Decision makers/ that their action is not aligned with their intention ( of delivering true value to customers fast, collaboration, self-empowerment, test&learn) is simply not enough. Were you more brave when someone just told you "don't be afraid!"?Addressing the fear needs compassion, listening and observation.
Epilogue : The (mostly) hidden cost of fear
Peter Senge also says the 2most powerful motivation drivers are fear and aspirations. Aspiration leads to positive vision: "We want to achieve something" , fear to negative vision : "We want to avoid something".
Vision lead by fear trigger compliance behaviour : people do their job to be compliant to a vision issued by hierarchy its related rules and regulations. Vision lead by aspiration trigger commitment : people do their job because they want that vision, and they can empower themselves to change the rules and regulations accordingly. The 20th business "led-by-fear vision behaviour" was considered "professional". I believe that the only thriving organisation model is the "led-by-aspiration" one. I do hope the 21st century will consider "led-by-aspitration" behaviour to be nevertheless "professional".
Ultimately, what do you thing is the cost of a non thriving organisation?Related posts Manage like a PirateWhy I Am Not A Change AgentFrom Listening To Awareness
2Ways To Embrace a Vision : The DNA of enterprise culture

Helpful references
Usable Software Design 
The_Fifth_Discipline




Categories: Blogs

Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

Lean and Agile are great approaches to increase effectiveness in Product Development and in Project/Program Management. What could be the most important things to do, to improve the development of your products and services? If you are managing your portfolio of projects using the traditional way, probably you encountered several of the problems listed below. […]
Categories: Blogs

Consider Rolling Wave Roadmap and Backlog Planning

Johanna Rothman - Tue, 12/20/2016 - 19:57

Many agile teams attempt to plan for an entire quarter at a time.

Sometimes, that works quite well. You have deliverables, and everyone understands the order in which you need to deliver them. You use agile because you can receive feedback about the work as you proceed.

You might make small adjustments, and you manage to stay on track with the work. In fact, you often complete what you thought you could complete in a quarter. (Congratulations to you!)

I rarely meet teams like that.

Instead, I meet and work with teams who discover something in the first or second iteration that means the entire rest of the quarter is suspect. As they proceed through those first few features/deliverables, they, including the PO, realize they don’t know what they thought they knew. They discovered something important.

Sometimes, the managers in the organization realize they want this team to work on a different project sometime in the quarter. Or, they want the team to alternate features (in flow) or projects (in iterations) so the managers can re-assess the project portfolio. Or, something occurs outside the organization and the managers need different deliverables.

If you’re like me, you then view all the planning you did for the rest of the quarter as waste. I don’t want to spend time planning for work I’m not going to do. I might need to know something about where the product is headed, but I don’t want to write stories or refine backlogs or even estimate work I’m not going to do.

If you are like me, we have alternatives if we use rolling wave, deliverable-based planning with decreased specific plans.

In this one-quarter roadmap example, you can see how the teams completed the first iteration. That completion changes the color from pink to white. Notice how the last month of the quarter is grayed out. That’s what we think will happen, and we’re not sure.

We only have specific plans for two iterations. As the team completes this iteration, the PO and the team will refine/plan for what goes into the 3 iteration from here (the end of the second month). As the team completes work, the PO (and the PO Value team) can reassess what should go into the last part of this quarter and the final month.

If you work in flow, it’s the same idea if you keep your demos on a cadence.

What if you need a shorter planning horizon? Maybe you don’t need one-quarter plans. You can do the same thing with two-month plans or one-month plans.

This is exactly what happened with a team I’m working with. They tried to plan for a quarter at a time. And, often, it was the PO who needed to change things partway through the quarter. Or, the PO Value team realized they did not have a perfect crystal ball and needed to change the order of the features partway through the quarter.

They tried to move to two-month horizons, and that didn’t help. They moved to one-month horizons, and almost always change the contents for the last half of the second month. In the example above, notice how the Text Transfer work moved to farther out, and the secure login work moved closer in.

You might have the same kind of problem. If so, don’t plan details for the quarter. Plan details as far out as you can see, and that might be only one or two iterations in duration. Then, take the principles of what you want (next part of the engine, or next part of search, or whatever it is that you need) and plan the details just in time.

Rolling wave deliverable-based planning works for agile. In fact, you might think it’s the way agile should work.

If you lie this approach to roadmapping, please join my Practical Product Owner workshop. All the details are on that page.

Categories: Blogs

We’re Moving: Rally Blog Has a New Home on CA Highlight

Rally Agile Blog - Thu, 10/06/2016 - 17:24

You’ve probably heard by now that Rally Software has become part of the CA Technologies family. As a result we’re moving the agile blogs you know and love from here, to there: http://blogs.ca.com/tag/agile-management/.

Beginning in mid-October, the Rally blogs will no longer be available in their current locations.

We’ve already moved our most popular blog posts over to the CA Highlight blog. You'll find the same great agile management topics and content written by your favorite bloggers, with added links to interesting, related content. The technical (engineering, development, DevOps) blogs will live at CA Highlight as well.

So set a new bookmark to the CA Highlight blog or subscribe using the link at the bottom of the page. Then, browse the Agile Management and Technical Innovation categories to see posts you may have missed, and check out authors new to you from the CA family. See you there!

Rally
Categories: Companies

Integreer Kwaliteit met Lean Software Ontwikkeling

Ben Linders - Wed, 08/24/2016 - 13:26

Integreer kwaliteit Agile LeanAgile methoden zoals Scrum leggen de nadruk op functionaliteit. Klanten verwachten echter naast functionaliteit dat ook de kwaliteit van het product in orde is. Waar Agile voornamelijk aandacht geeft aan het software team en de interactie met de omgeving, kijkt Lean naar de gehele keten: van klantbehoefte tot waarde voor de klant. Een van de aspecten van Lean Software Ontwikkeling is het integreren van kwaliteit.

Lean Software Ontwikkeling combineert Agile en Lean met de volgende 7 principes:

  1. Verminder Verspillingen (Eliminate Waste)
  2. Integreer Kwaliteit (Build Quality In)
  3. Leer Voortdurend (Learn Constantly)
  4. Lever Snel (Deliver Fast)
  5. Betrek Iedereen (Engage Everyone)
  6. Verbeter Continue (Keep getting Better)
  7. Optimaliseer het Geheel (Optimize the whole)
Kwaliteit begint bij de klanten


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Mijn definitie van kwaliteit (zie Hoe zorg je met Scrum voor Kwaliteitsproducten en Diensten) is:

Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide.

Het zijn je klanten die bepalen wat kwaliteit is (en wat niet), en wat vereist is voor een goede kwaliteit. Pas als je weet wat je klanten nodig hebben kun je naar goed oplossingen zoeken om aan hun wensen te voldoen. Je integreert daarmee kwaliteit in het gehele ontwikkelproces. Het juiste product

Hoe kom je erachter wat de klant nodig heeft? Agile kent diverse practices waarin het team en de klanten (in de Scrum praat men over product owner ipv klant) intensief samenwerken om ervoor te zorgen dat het juiste product geleverd wordt. Voorbeelden daarvan zijn de planning game en de product demonstratie.

In de planning game gaat het erom dat de product eisen duidelijker worden. Wat willen klanten bereiken met het product, welke waarde moet het hun gaan bieden? Wat moet het product doen om die waarde te kunnen leveren? Maar ook de kwaliteitseisen: hoe snel moet het werken, en hoe betrouwbaar en stabiel moet het zijn? Het team benut zijn kennis en ervaring om te bepalen wat mogelijk is, en hoe het product op een Lean manier ontwikkelt kan worden.

In de product demonstratie laat je het product zien aan de klanten en vraag om je feedback. Is dit wat de klant wil? Is het goed genoeg? Maar ook: Is het snel genoeg, handig te gebruiken. Betrouwbaar en veilig? En, gegeven wat het product nu doet, wat is er nog meer nodig? Kwaliteit met Agile en Lean

Hoe gaat dat in de praktijk? Laten we kijken naar een medisch systeem wat specialisten gebruiken om onderzoek te doen met patiënten. De specialisten (klanten) willen een aantal mogelijkheden hebben om data en scans van een patiënt te bekijken. Ze willen beelden van eerdere scans kunnen oproepen, inzoomen, en vergelijken. Omdat ze dat vaak met de patiënt erbij doen moet dat snel gaan, en eenvoudig te bedienen zijn. De gegevens mogen niet fout zijn, de specialisten gebruiken ze om beslissingen te nemen waar het leven van de patiënt van af kan hangen.

In de discussies vooraf en in de planning game formuleren de product owner en het team de acceptatie criteria. Voor kwaliteitseisen moeten die criteria meetbaar zijn. Dus niet “snel genoeg” maar “in 90% van de gevallen reageert het systeem binnen 1 seconde”.

Samen met de product owner formuleren de teamleden user stories. De acceptatiecriteria in de user stories worden door het team gebruikt om af te spreken hoe ze de software gaan maken en verifiëren.

Bijvoorbeeld, voor een bepaalde user story doen ze een spike, ze maken een stukje sofware en een testcase die meet hoe snel de software is om te bepalen of wat de klant wil haalbaar is. Voor een andere user story wil het team pair programming gebruiken, het is een complexe functie waarmee de team leden nog geen ervaring hebben.

Er zijn ook stories waarbij test driven design volgens het team de beste aanpak is, en een enkele story waarbij de klant nog niet echt weet wat het product precies moet gaan doen om er op  een handige manier mee te kunnen werken, daar lijkt prototyping met Lean Startup het beste te passen.

De vereiste functionaliteit en kwaliteit is bepalend voor de aanpak. De product owner maakt duidelijk wat er nodig is en welke kwaliteit de klanten verwachten. Het team weet wat met een bepaalde manier van werken haalbaar is, en check in de planning game met de product owner. Te weinig kwaliteit is niet goed, maar teveel ook niet. Het gaat bij lean om het vinden van de juiste balans tussen tijd, geld en kwaliteit voor het leveren van functionaliteit.

In de demonstratie wordt de software getoond en gechecked of het voldoet. Daarbij telt zowel de functionaliteit als de kwaliteit. Het moet niet alleen werken, het moet ook snel genoeg zijn, betrouwbaar, bedienbaar, etc. Pas dan voldoet het product aan alle eisen en is het af.

De kracht zit in de samenwerking tussen het team en de product owner gedurende de ontwikkeling. Is er een gedeeld beeld wanneer, hoe en waarvoor klanten het product gebruiken? Wat betekent het product voor hun en welke waarde het kan toevoegen? Kan de product owner voldoende duidelijk maken wat nodig is, en checken de teamleden of ze het goed begrepen hebben? Leren ze van dingen die niet goed zijn gegaan? Integreer kwaliteit

Lean en Agile versterken elkaar als het gaat om de kwaliteit van de producten en diensten. Met agile en lean practices integreer je kwaliteit in de volledige productontwikkelingsketen.

kwaliteitsverbeteringIn de workshop software kwaliteitsverbetering leer je hoe je goede producten en diensten kunt leveren. Kwaliteitsverbetering helpt organisaties om beter te voldoen aan de behoeften van de gebruikers en aan de eisen van de opdrachtgevers.

Categories: Blogs

Continue Verbetering met Agile in Bits&Chips

Ben Linders - Wed, 08/24/2016 - 11:05

bitchipslogoMijn artikel Continue Verbetering met Agile is gepubliceerd in Bits&Chips nr 4. In dit artikel laat ik zien dat continue verbetering een integraal onderdeel is van de Agile-mindset en van de Agile-principes en -practices, en geef ik tips en advies voor verbeteren met agile:

Silver bullets bestaan niet in softwareontwikkeling. Effectieve softwareteams bepalen zelf hoe ze hun werk doen, passen zich continu aan en verbeteren zichzelf. Continue verbetering is ingebed in de Agile-mindset en -principes en helpt zo om de flexibiliteit in bedrijven te verhogen en meer waarde te leveren, betoogt Ben Linders.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Bits&Chips publiceert een magazine over ontwikkelingen in de high-tech industrie en organiseert de jaarlijkse smart systems conferenties (Software-Centric Systems Conference in 2016).

Eerder dit jaar publiceerde Bits&Chips een Engelstalige editie, met daarin mijn artikel Delivering quality software with Agile.

Categories: Blogs

Survey on Agile Manifesto 2.0

Ben Linders - Mon, 08/15/2016 - 17:59

Survey agile manifesto KamleshIs There a Need For Agile Manifesto 2.0? That’s the question that Kamlesh Ravlani, Agile / Lean Coach and Scrum Trainer, is asking the Agile community. He is running a Survey on Agile Manifesto 2.0, which he announced on LinkedIn Pulse.

Lately there is a lot of buzz in the Agile community around the need to update the Agile Manifesto. Many agilists have been vocal about it and some have floated their own versions of the manifesto. Let’s explore collectively as a community the need for changes in the Agile Manifesto.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Please support this survey by answering three questions (it only takes a couple of minutes).

Kamlesh will publicly share the findings from the survey:

Who can participate?
All practitioners, Agile coaches, trainers and thought leaders are invited to share their opinion.

How will this information be used?
I intend to share the results of this survey with community via recognized platform for example – Infoq, ScrumAlliance, etc.

I’ve responded to this survey and I’m hoping many of you will do the same :-).

Categories: Blogs

Feedback in Agile

Ben Linders - Wed, 08/10/2016 - 11:38

feedback agileAgile software ontwikkeling kent ingebouwde feedback. Iedere iteratie wordt afgesloten met een sprint review/demo en een agile retrospective, waarin feedback centraal staat. Ook tijdens de iteratie is er gelegenheid voor feedback. Een overzicht van de diverse manieren van feedback in agile en de voordelen die feedback oplevert. Product Demonstratie

De product demonstratie (sprint review in Scrum) is bedoeld om feedback te krijgen op het product. Een goede demo zorgt voor antwoorden op vragen zoals:

  • Doet het product wat het zou moeten doen?
  • Is het product bruikbaar?
  • Welke functionaliteit is verder nodig?
  • Wat kan er aan het product verbeterd worden?
Agile Retrospective


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

In de agile retrospective reflecteert het team op hun proces. In de retrospective geven teamleden feedback naar elkaar. Deze feedback geeft inzicht in de manier van werken en helpt om continu te verbeteren.

Een goede retrospective geeft inzicht in:

  • Wat ging er goed en wat heb je als team geleerd?
  • Welke problemen zijn er geweest, wat zou je willen veranderen?
  • Welke sterktes en kwaliteiten heeft het team?
  • Hoe kan het team zich verder ontwikkelen?

Cover Waardevolle Agile Retrospectives ManagementboekWaardevolle Agile Retrospectives is het 1e Nederlandstalige Agile boek voor het faciliteren van retrospectives. Met vele oefeningen, het “wat” en “waarom” van retrospectives, de business value en de voordelen die retrospectives brengen. Tevens practische tips en adviezen voor het introduceren en verbeteren van retrospectives. Aanbevolen voor agile coaches, Scrum masters, project managers, product managers en facilitators die al enige ervaring hebben met retrospectives. Andere feedback momenten

De demo en retrospective zijn de bekendste feedback momenten in Agile. Maar er zijn er nog meer. Tijdens de dagelijkse stand up kunnen team leden elkaar feedback geven. Bijvoorbeeld over hoe ze de samenwerking in het team ervaren en hoe een activiteit gegaan is. In de planning game geeft het team feedback op de user stories naar de product owner, samen stemmen ze de inhoud van de iteratie af. Wat levert feedback op

Feedback in agile helpt om te leren en continu te verbeteren. De voordelen die feedback in agile oplevert zijn:

  • Met frequente snelle feedback kun je eenvoudiger bijsturen
  • Concrete feedback die kort na een gebeurtenis gegeven wordt, maakt eenvoudiger om actie te ondernemen
  • Verbeteren in kleine stapjes is eenvoudiger, snelle feedback maakt het mogelijk.
  • Goede feedback verbeterd de relatie tussen mensen en helpt om effectiever samen te werken

Agile wordt je door agile te doen. Wil je met agile resultaten bereiken dan is goede feedback essentieel. De sprint review/demo en de agile retrospective zorgen voor continue product- en procesverbetering, waardoor teams efficiënt en effectief producten kunnen leveren.

Categories: Blogs

Gratis mini-workshop over Agile Retrospectives

Ben Linders - Wed, 08/10/2016 - 11:06

AgileHubNoordOp 21 september geef ik een gratis mini-workshop over agile retrospectives in Groningen. In deze mini-workshop gebruik ik oefeningen uit mijn succesvolle workshop Waardevolle Agile Retrospectives.

Retrospectives helpen je om agile effectief toe te passen continu te verbeteren. Je pakt ermee problemen aan en zorgt voor een goede werksfeer in je teams. Scrum masters en Agile coaches halen  meer uit teams met behulp van een toolbox met retrospective oefeningen.

In deze mini-workshop geeft Ben Linders, auteur van het boek Waardevolle Agile Retrospectives, een introductie van de “waarom” en “wat” van retrospectives. Je oefent verschillende manieren om retrospectives te doen en krijgt tips en adviezen voor het introduceren en verbeteren van retrospectives.

Deze mini-workshop wordt gegeven in samenwerking met AgileHubNoord, een onafhankelijke netwerkorganisatie die als doel heeft om Agile-professionals uit Noord-Nederland met elkaar te verbinden, kennis met elkaar te delen en om het Agile-gedachtegoed onder de aandacht te brengen.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Er zijn helaas geen plaatsen meer beschikbaar voor deze workshop (hij was in enkele dagen volledig “uitverkocht”), maar er is een wachtlijst. Als mensen zich afmelden word je automatisch aangemeld voor de meetup.

De workshop workshop Waardevolle Agile Retrospectives geef ik zowel via open inschrijving als in-house, aangepast aan de specifieke wensen van jou bedrijf en situatie. Neem contact met mij op!

Categories: Blogs

Chapter on Visual Management added to What Drives Quality

Ben Linders - Wed, 08/10/2016 - 09:30

What Drive Quality coverA new chapter which explores how visual management can be used to improve quality of software products has been added to my second book What Drives Quality.

One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to develop and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. You can apply visual management to make potential quality issues visible early and prioritize solving them. The examples that I provide explain clearly why quality matters and how visualization can be used to establish, maintain and even increase the quality of software products.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

What drives quality provides insight into the factors that drive the quality software products and services. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.

The book What Drives Quality is available for a reduced price on Leanpub as long as it’s under development. If you buy the book now you will automatically get all chapters that are added in the future for free. So don’t wait too long, get your copy now!

Categories: Blogs

Why do you want to become agile?

Ben Linders - Mon, 08/08/2016 - 13:16

Why becoming agileBecoming agile can help to achieve organizational goals. But setting agile as a goal for an organization does not work. The goal for a software organization should be to achieve results by delivering valuable products and services, not to become agile. Hence my question: do you know why do you want to become agile?
Yes, seriously, why would you do agile? There are lot’s of good reasons (and also some less good ones), but what’s your reason to become agile? What do you expect from agile?

Agile transformations seriously impact organizations (they should!). It’s a reorganization of people, work, and authorities. Employees are asked to think about the way they want to do their work, and to take responsibility. Managers have to give room to their employees. There must be a good reason to do all of this. You should know the reason why you want to become agile, and let everyone involved know.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

It is important to know why you want to increase the agility of your organization and what you expect to achieve with agile. To know why would you want to work in an agile way, why you want your culture to become agile.

Again, agile is not an goal or state that needs to be reached. It’s important that every manager and employee knows why the organization starts an agile journey and what is expected from agile. Reasons to become agile

If I ask people in organizations that I work with why they want to become agile they often look surprised at first. Of course they want agile! Everybody is doing agile, so it must be good. Agile is supposed to make them faster, cheaper and better. So let’s do it. If it only was that easy … every organization should be truly agile by now.

Does knowing the reason matter? Yes, it does! If you know the reason why you want to become agile, chances of success increase significantly. If people know why they have to chance, if they see the purpose, they are more willing to do it.

Some of the reasons that I have heard in organizations on why they want to become agile are:

  • Deliver the right products and services
  • Be able to deliver faster
  • Increase customer satisfaction and win new customers
  • Create innovative products with motivated employees
  • Reduce the cost of development and management
  • Improve the quality of goods and services
  • Effective cooperation between development and management
  • (your reason here)

My advice to companies is to think about why they want to become agile. Pick one reason, and one only. State very clearly in one sentence what your main objective to become agile. What would make your agile transformation successful. Going for one goal is hard enough. Also, the reason you choose impacts the way that agile will be applied (it should!), so choose your reason carefully. What is your goal with agile?

Do you want to deliver products with good quality? Or be able to better meet the needs of your customers? Lower your costs? Increase the motivation of your employees? Whatever your reason is to become agile, contact me, and I’ll help you to get results :-).

Categories: Blogs

Books by Ben Linders on Leanpub

Ben Linders - Mon, 08/08/2016 - 11:07

Books Ben Linders LeanpubAll of the books that I have published on Leanpub are now available in a bundle: Books by Ben Linders. You get a 30% discount when you buy my books with this bundle.

Currently this bundle contains three books:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

My book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!

My book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.

My 2nd and 3rd book are being written incrementally. Currently they are only sold via Leanpub. When you buy the book on Leanpub you will automatically receive new chapters when they become available, free of charge.

All books that I will publish in the future on leanpub will be added to this bundle.

Categories: Blogs

Masterclasses at Agile Tour Kaunas

Ben Linders - Mon, 08/01/2016 - 18:49

agiletour2016kaunas I’m giving two masterclasses at Agile Tour Kaunas on October 11 and 12 on Retrospectives and on Agile and Lean. Tickets for these agile workshops can be bought on the Agile Tour Lithuania courses webpage.

The two masterclasses are:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

This is the first time that I’m giving my workshops in Lithuania. I’m grateful to Agile Lithuania for inviting me to their country.

The early bird price (till September 1st) for my masterclasses is 319 Eur (VAT not applicable). Regular price: is 379 Eur.

As an adviser, coach and trainer I helps organizations by deploying effective software development and management practices. I provide workshops and training sessions, public and private sessions. Here’s a list of my upcoming public sessions.

Categories: Blogs

A Summary of More Fearless Change in 15 Tweets

Ben Linders - Fri, 07/29/2016 - 11:58

More Fearless Change book coverThe book More Fearless Change by Mary Lynn Manns and Linda Rising provides ideas for driving change in organizations, using the format of patterns. This book is an new and extended version of their successful book Fearless Change.

I did an interview with Mary Lynn and Linda about how people are viewing change in organizations, the purpose of patterns and the benefits that organizations can get from using them, the new patterns that are described in More Fearless Change and the insights were added to the existing patterns, and their expectations about what the future will bring us in organizational change. You can read it on InfoQ: Q&A on the Book More Fearless Change. 15 Quotes from More Fearless Change


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Here’s a set of 15 quotes from the new patterns that have been added in More Fearless Change. I’m tweeting these quotes with #fearlesschange: No matter how great your new idea is and how well prepared you are, you are bound to meet some level of resistance Inspire people throughout the change initiative with a sense of optimism rather than fear When you feel discouraged, look for the bright spots among the challenges that surround you Displaying a warm smile and a willingness to be nice even when negativity surrounds you can go a long way To make progress toward your goal, state precisely what you will do as you take the next baby step To encourage adoption of a new idea, experiment with removing obstacles that might be standing in the way Change the environment in a way that will encourage people to adopt the new idea When you have a chance to introduce someone to your idea, you don’t want to stumble around for the right words to say Persuasion tactics must consider what people are logically thinking as well as what they are feeling By focusing on the future, individuals may be more motivated to let go of the past Your change initiative is a series of baby steps As you prepare to move forward, occasionally look for a quick and easy win that will have visible impact Stay in touch with your supporters—never assume that news of your progress is known across the organization Rumors need to be debunked before they take root and create significant concerns and anxieties during the change You can’t spend time and energy addressing every bit of resistance you meet Patterns can help you to drive change

If you want to truly change organizations, don’t try to plan it up front and don’t look for recipes. That won’t work (literally!). Patterns provide a useful format to convey ideas and to apply those ideas in a specific situation to do sustainable change.

Mary Lynn Manns and Linda Rising did a great job in this updated and extended version of Fearless Change. The experiences that they added to the existing patterns help you to get a deeper understanding, and the new patterns that they describe in this book are very valuable.

The patterns described in More Fearless Change help you to recognize situations and to come up with solutions for dealing with them. If you are dealing with change in organizations (and who isn’t nowadays) then I highly recommend to read this book and keep it close to you, as it will be useful at many times!

Categories: Blogs

Books with Agile Practices and Tips

Ben Linders - Thu, 07/28/2016 - 09:54

Agile Practices and Tips Books BundleA new bundle of books with agile practices and tips has been released on Leanpub. Buy these books with a 40% discount!

The bundle includes six great books from eleven authors, helping you to make your agile journey easier to travel, more successful, and fun!

  • With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.
  • A Toolbox for the Agile Coach:  96 Visualization Examples showing how great teams visualize their work.
  • The tools and techniques provided in the Forming Agile Teams workbook offer an alternative-proven way to add more structure, transparency and visibility to the work that you do when Forming Agile Teams, by combining visual explanations with techniques and tips to support Scrum Masters crucial role within the organization.
  • The Scrum Master Workbook Part 1 provides 15 weeks of accelerated learning. It teaches you ways to deal with conflict, bugs, interruptions, meetings and many more topics.
  • Patterns of Agile Journeys shares stories and patterns to help you recognize situations you may find yourself in on your own journey. Use the tips in this book to reinforce or counteract the patterns you see.
  • The book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Together these books provide many useful tips and practices for your agile journey. Buy them for $40,77 (regular price is $67,95).

There’s also the Agile Retrospectives Books Bundle with six great books that will make your agile retrospectives rock, and the Valuable Agile Retrospectives – All Languages Bundle which contains all language editions of my successful book Getting Value out of Agile Retrospectives.

Categories: Blogs

Manifesto voor Agile Veranderen

Ben Linders - Tue, 07/26/2016 - 10:47

Manifesto Agile Veranderen Ben LindersHet manifesto voor agile veranderen helpt organisaties om hun agility te verhogen. Het zorgt voor blijvende verbetering van de resultaten, tevreden klanten, en blije medewerkers. Dit eerste artikel over Agile Veranderen beschijft de uitgangspunten en waarden met behulp van het manifesto voor agile veranderen.

Agile software ontwikkeling is gebaseerd op het Manifesto voor Agile Software Ontwikkeling. Dit manifesto bevat vier waarden en twaalf principes. Het manifesto voor agile veranderen is op een zelfde manier opgebouwd. Het beschrijft mijn visie en werkwijze in organisatieverandering, samengevat in vier waarden. Mijn verander “waarden”


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Dit zijn de waarden van mijn Manifesto voor Agile Veranderen:

  • Betrekken van professionals en ruimte geven voor ideeën over standaardisatie en voorschrijven van werkprocessen
  • Stapsgewijze evolutionaire verbetering van binnen uit over top down opleggen van veranderingen.
  • Resultaatgericht en intensief samenwerken over directieve doelen met “command & control” management.
  • Prioritiseren en flexibel inspelen op kansen over budgetteren en veranderplannen uitvoeren.

De waarden aan de rechterkant van bovenstaande statements zijn en blijven belangrijk, maar ik geef graag meer aandacht aan de waarden aan de linkerkant. Daarom geef ik bijvoorbeeld de voorkeur aan het in kaart brengen van de bestaande werkprocessen met de medewerkers en samen werken aan verbetering mbv retrospectives in plaats van organisatiebreede uitrol van Scrum met standaard trainingen. En werk ik liever met een veranderbacklog waarin de prioriteiten eenvoudig aan te passen zijn dan met een plan. Ook veranderen veranderd

Anders dan het Agile Manifesto wat al 15 jaar hetzelfde is verwacht ik dat dit manifesto wel zal veranderen. De eerste evolutie is al te zien als je het vergelijkt met het verander manifesto van veranderproject, een samenwerkingsverband van enkele jaren geleden. Bijvoorbeeld woorden als “verbinden” zijn verder uitgewerkt in “resultaatgericht en intensief samenwerken” en het manifesto voor agile veranderen benoemd de rol van de professional en een bottom up aanpak voor verandering.

In de nabije toekomst zal ik diverse artikelen publiceren waarin ik dieper in ga op de waarden van dit manifesto. Ik geef daarin o.a. voorbeelden van betrekken van professionals in verandertrajecten, top-down versus bottom up veranderen, evolutionaire versus revolutionaire verandering en resultaatgericht veranderen.

Categories: Blogs

All languages bundle for Valuable Agile Retrospectives

Ben Linders - Thu, 07/07/2016 - 16:00

Valuable agile retrospectives - all languages bundleThe successful book Getting Value out of Agile Retrospectives has been translated in many languages. The leanpub bundle Valuable Agile Retrospectives – All Languages contains all language editions, you can get 9 books for the reduced price of $24,99 (excluding VAT).

People from all over the world approach us for translating our book into their native language. We love to work together with local agile communities and agile practitioners to make our book available in their local language.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

The normal price for the 9 books is $89,91, together these books are now available for the price of $24,99, a discount of more that 70%. When you buy the bundle you will get all translations that are released in the future for free. With this bundle you will always have the latest version of our book in every language.

Our mission is to help many teams all around the world to get more value out of agile retrospectives.

At this moment out book is available in these languages on leanpub:
[Nederlands]  [Español]  [Francais]  [Japanese]  [Italiano]  [Chinese]  [русский]  [Polish]

You can buy all local language editions of Getting Value out of Agile Retrospectives at Amazon.com (and all other Amazon shops), LeanpubiTunesSmashwordsLuluBarnes & NobleKoboScribd, Oyster and Blio. Paperback editions can be bought in my webshop and on bol.com and Managementbook.nl.

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.