Skip to content

Feed aggregator

Thinking About PMO Productivity

Johanna Rothman - Fri, 01/27/2017 - 16:15

In Manage Your Project Portfolio, I’m agnostic about who manages the project portfolio. I prefer that the managers responsible for the strategy make the project portfolio decisions. And, I recognize that the PMO often makes those decisions.

I am doing a series of webinars with TransparentChoice. The first one is live. See How many “points” does your PMO score? We spoke about how you might know if you need a project portfolio and the major measure of successful decisions:

It doesn’t matter how many projects you start. It matters how many you finish.

Hope you enjoy it!

Categories: Blogs

Agile DNA Webinar

Leading Answers - Mike Griffiths - Thu, 01/26/2017 - 01:05
This post is a follow-up to my Agile DNA webinar I hosted a couple of weeks ago. This was my first webinar for RMC and we had a great attendance with over 2,000 people registering for the event. The recording... Mike Griffiths
Categories: Blogs

What’s Minimum: Thinking About Minimum Viable Experiments

Johanna Rothman - Mon, 01/23/2017 - 19:12

When I talk about Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. They can’t possibly release anything without doing a ton of work.

I ask them questions, to see if they are talking about a Minimum Indispensable Feature Set or a Minimum Adoptable Feature Set instead of an MVE or an MVP. Often, they are.

Yes, it’s possible you need a number of stories to create an entire feature set before you release it to your entire customer base. And, that’s not an MVP or an MVE.

Do you know about Eric Ries’ Build-Measure-Learn loop? Or the Cynefin idea of small, safe-to-fail experiments? Here’s the thinking behind both of those ideas:

  • You have ideas you could implement in your product. If you are like my clients, you have more ideas than you could implement ever. This is a good thing!
  • You Build an idea for one product.
  • You Measure the result with data.
  • You Learn from that data to generate/reduce/change your ideas.
  • Do it again until you’ve learned enough.

When I think about the Build-Measure-Learn loop and apply it to the idea of a Minimum Viable Experiment, I often discover these possibilities:

  1. We have an MVE now. We need to define how to measure it and use the data.
  2. We don’t have to do much to collect some data.
  3. We can ask this question: What do we want to know and why? What is the benefit of gathering that data?

Here’s an example of how this affected a recent client. They have an embedded system. They thought that if the embedded part booted faster, they could find more applications for the system. In embedded software, speed is often a factor.

They chose one client, who had systems now. The Product Manager visited the client and asked about other vertical applications within the organization. Did they have a need for something like this system?

Yes, they did. They were concerned about speed, not just boot speed, but application processing speed.

The Product Manager asked if they were willing to be part of an MVE. He explained that the team would watch how they implemented and used the embedded system. Yes, they would all sign non-disclosures. The client also had to know that the team might not actually implement for real what the experiment was.

The customer agreed. The team implemented four very small performance enhancements—only through the happy paths, no alternative/error paths—and visited the customer to see what would happen. It took the team three days to do this.

The team visited for one day to watch how the client’s engineers used the product.

They were astounded. Boot speed was irrelevant. One specific path through the processing was highly relevant. The other three were irrelevant for this specific customer.

This particular MVE was a little on the expensive side. It took a team-week to develop, measure, and learn. There was some paperwork that both sides had to manage. If you have a different kind of product, it might take you less time.

And, look how inexpensive that week was. That week taught the team what one vertical product line needed and didn’t need. They managed to avoid all those “necessary” features. This client didn’t need them. It turned out a different kind of vertical needed two of them, and no one appears to need the remaining one.

The Product Manager was able to prune many of the ideas in the backlog for this vertical market. The Product Owner knew and (knew why) which features were more important and how to write stories and rank them.

That’s one example of an MVE. Your experiments will probably look different. What’s key here is this question: What is the smallest thing you can measure that will provide you value so you can make a decision for the product?

Categories: Blogs

“When Will This Software Project Ever Be Done?”

Leading Answers - Mike Griffiths - Tue, 01/17/2017 - 21:00
Does this question sound familiar? If you get asked it regularly then you may be part of the mainstream transformation from software projects to products. It’s coming and it's going to turn many roles, certifications and in some cases entire... Mike Griffiths
Categories: Blogs

Agile Teams, Measures and KPIs

When you dig into this topic, you find tons of discussions and debates about what metrics and KPIs to use when “running” Agile and if they are helpful or misleading. This post wants to explain when and what KPIs can be used, to lead your team towards relentless improvement. As a Scrum Master, Coach, Agile […]
Categories: Blogs

Rethinking Component Teams for Flow

Johanna Rothman - Tue, 01/10/2017 - 23:58

A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.

One of the (very sharp) fellows in the audience asked this question:

As you grow, don’t you need component teams?

I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams. And, then they have a little problem. They can’t find enough UX/UI people. Or, they can’t find enough database people. Or, enough writers. Or some other necessary role for the “next” team. They have a team without necessary expertise.

If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.

Some organizations attempt to work around the scarce-expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.

When you do that, you flow work through a not-complete team. You’re still flowing work, but the team itself can’t do the work.

You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has 12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)

When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person. Or, you’re waiting for an expert. (See CoD Due to Multitasking and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)

What can you do?

  1. Flow work through the experts. Instead of flowing work through teams that don’t have all the expertise,  flow work through the experts (not the teams).
  2. Never let experts work alone. With any luck, you have people in the team working with the experts. In Theory of Constraints terms, this is exploiting the constraint. It doesn’t matter what other work you do. If your team requires this expertise, you need to know about it and exploit it (in TOC sense of exploitation).
  3. Visualize the flow of work. Consider a kanban board such as the one below that shows all the work in progress and how you might see what is waiting for whom. I would also measure the Cost of Delay so you can see what the delay due to experts is.
  4. Rearrange backlog ranking, so you have fewer teams waiting for the scarcity.

Here’s the problem. When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.

Visualizing the work helps.

Flowing the work through the constrained people will show you your real capacity.

Needing component teams is a sign someone is still thinking in resource efficiency, not flow efficiency. And, I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.

If you can’t hire, you have several choices:

  • Have the people with the scarce expertise consciously train others to be ready for them, when those scarce-expertise people become available. Even I can learn some capability in the UI. I will never be a UI expert, but I can learn enough to prepare the code or the tests or the experiments or whatever. (I’m using UI as an example.)
  • Change the backlogs and possibly reorganize as a program. Now, instead of all the teams competing for the scarce expertise, you understand where in the program you want to use that scarce expertise. Program management can help you rationalize the value of the entire backlog for that program.
  • Rethink your capacity and what you want the organization to deliver when. Maybe it’s time for smaller features, more experiments, more MVPs before you invest a ton of time in work you might not need.

I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.

Categories: Blogs

The Business Analyst and the Product Owner

Leading Answers - Mike Griffiths - Mon, 01/09/2017 - 23:59
In my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of... Mike Griffiths
Categories: Blogs

[2nd Part] Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

In my previous post I explained some of the foundemantals steps for implementing an Agile and Lean Portfolio Management. Want to know how actually strategy drives execution of company Big Initiatives, through Agile and Lean?! In my previous post I wrote why Agile/Lean Values and Principles are the most critical point to start with, also […]
Categories: Blogs

Connecting with Humans

Johanna Rothman - Thu, 01/05/2017 - 17:59

I just read Zappos is struggling with Holacracy because humans aren’t designed to operate like software. I’m not surprised. That’s because we are humans who work with other human people. I want to talk with people when I want to talk with them, not when some protocol tells me I must.

It’s the same problem when managers talk about “resources” and “FTEs” (full-time equivalents). I don’t know about you. I work with resourceful humans. I work with people, regardless of how much time they work at work.

If the person I need isn’t there, I have some choices:

  • I can cc the “other” person(s) and create a ton of email
  • I can ask multiple people and run the risk of multiple people doing the same work (and adding to waste)
  • I can do it myself—or try to—and not finish other work I have that’s more important.

There are other options, but those are the options I see most often.

We each have unique skills and capabilities. I am not fond of experts working alone. And, I want to know with whom I can build trust, and who will build trust with me.

We build relationships with humans. (Okay, I do yell at my computer, but that’s a one-sided relationship.) We build relationships because we talk with each other:

  • Just before and just after meetings. This is the “how are the kids? how was the wedding? how was the weekend?” kind of conversation.
  • When we work with each other and explain what we mean.
  • When we extend trust and we provide deliverables to build trust.

When we talk with each other, we build relationships. We build trust. (Some of us prefer to talk with one person at a time, and some of us like to speak with more. But we talk together.) That discussion and trust-building allows us to work together.

This relationship-building is one of the problems of geographically distributed teams not feeling like teams. The feelings might be missing in a collocated team, too. Standups work because they are about micro-commitments to each other. (Not to the work, to each other as humans.)

I’m a Spock-kind of person, I admit. I work to build human relationships with colleagues. I work at these relationships because the results are worth it to me. Some of you might start with the people first, and you will build relationships because you like people. I’m okay with that

Categories: Blogs

Continuous Planning Article Posted

Johanna Rothman - Tue, 01/03/2017 - 16:44

I have a new article up on projectmanagement.com, Continuous Agile Program Planning: Think Big, Plan Small. It’s about how to use rolling wave planning especially for an agile program.

If you are a Product Owner or you are responsible for planning what when, and want to learn how to do this, join my PPO Workshop, starting next week.

Categories: Blogs

Lessons for the New Year

Johanna Rothman - Tue, 01/03/2017 - 16:32

I don’t know if you retrospect on a regular basis. I do. (I know, you are so surprised!)

Andy Kaufman asked me to share my biggest learning for his podcast. Take a listen to The Most Important Lesson You Learned Last Year. I’m pleased and proud to be in such good company. Thanks, Andy!

Categories: Blogs

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

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

Scrum Knowledge Sharing

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