Prioriteiten stellen bij product ontwikkeling met Kai Gilb

Daar waar Scrum Getting Things Done voor teams is, gaat het bij Value Requirements om What To Get Done. Hoe bepaal je de juiste prioriteiten, zodat je voor de stakeholders daadwerkelijk waarde creëert. Een methodiek die zeer geschikt is voor product owners en business analisten. Maar eigenlijk voor iedereen. Het moderne leven is een aan eenschakeling van het stellen van prioriteiten toch!?

ValueRequirements

Falende projecten

Een van de grootste factoren bij falende projecten, zelfs die Agile worden uitgevoerd, is het onvermogen de uitkomst van het project concreet en adequaat vast te leggen en te communiceren. Het is gebruikelijk om requirements te prioriteren op basis van waarde. Het onderbouwen van de daadwerkelijk waarde van nieuwe functionaliteit is echter lastig en wordt daarom vaak helemaal niet gedaan. Bij een groeiend aantal projecten lukt dit echter wel en deze presteren veel beter. Value Requirements is een van de methodieken om dit te bereiken.

Value Requirements

Bij de Value Requirements leer je methodisch de waarde van requirements vast te stellen en te categoriseren. Daarmee kan vervolgens worden gecommuniceerd met gebruikers, sponsoren en andere stakeholders over de echte gewenste uitkomsten van het project.

Alleen door product keuzes te relateren aan echte business waarde ben je in staat om telkens te kunnen bijsturen op basis van gerealiseerde resultaten.

Agile requirements worden opgesteld door:

  • De uitkomst te scheiden van design, architectuur en oplossingen en ze op het juiste niveau te plaatsen (business, stakeholder, product, sub-product, oplossing).
  • De product functies zuiver te formuleren, zonder design en waarde.

Maar vooral de product waarden zo te formuleren dat:

  • Ze representatief zijn voor de voor de uitkomsten die de gebruikers, sponsors en andere stakeholders als succesvol beschouwen.
  • Ze nuttig zijn voor product owners, engineers en architecten om mee te prioriteren.

Een vaardigheid die weinig mensen bezitten

Value Requirements stellen je in staat om een gewone tekst – of dit nu een PID is, een requirement specificatie is of een verzameling user stories – te herschrijven tot een set van concrete uitkomsten die het daadwerkelijke succes van het project beschrijven. Dit is een vaardigheid die weinig mensen bezitten en van onschatbare waarde bij projecten.

De grondlegger, Kai Gilb, binnenkort in NL

Kai Gilb zal op 29 en 30 april in Nederland zijn voor een value requirement training in samenwerking met Zilverline. Zilverline is een van de founding fathers van scrum/agile software development in Nederland en is ervan overtuigd dat de Value Requirements methodiek een belangrijke bijdrage zal leveren aan succesvolle product ontwikkeling.

Schrijf je hier in voor de training!

Simple event sourcing – users, authentication, authorization (part 6)

Previously we spend some time preparing the code to support multiple kinds of events and data, rather than just supporting blog posts. In this part we’ll add user accounts, together with the required authentication and authorization code. We’ll again use event sourcing and the memory image to keep track of all users and currently active sessions. But the biggest changes to the application are related to security, and authorization in particular. It turns out event sourcing allows for an additional layer of authorization which allows us to whitelist any change a particular user is allowed to make.
Continue reading Simple event sourcing – users, authentication, authorization (part 6)

How to use your happiness metric as a information radiator?

When I started recording the happiness of my team, I found it difficult to make this information transparent. I wanted to use it as a information radiator, so that everyone who looked at our Kanban or Scrum board could see (within 1 minute) how this particular team is doing, while on the other hand not all team members were confident enough to have their personal grade for all to see.
Continue reading How to use your happiness metric as a information radiator?

Flowmulator – A Kanban flow simulator

UPDATE: Now you can add workers to a column and see if it helps getting work done faster. Try experimenting with the numbers and get the best configuration!

While reading blogs about Agile games, I came across this link of Karl Scotland.
Because I always like combining programming with building something that gets across Agile principles (our Battleship game is also a good example) this seemed like a good new project for our Fridays at Zilverline HQ. Bob Forma and me started this and within a few days we came up with this (You can check the source code here)

Continue reading Flowmulator – A Kanban flow simulator

Simple event sourcing – refactoring and transactions (part 5)

In the previous part we added blog post comment functionality. In this part we’ll do some refactoring and change the memory image implementation to automatically retry domain logic on optimistic locking conflicts, giving us a simplified form of transactions. We’ll also change the event store to support multiple types of event streams in a single event store.

Continue reading Simple event sourcing – refactoring and transactions (part 5)

How to fill your happiness metric

Knowing how people think or feel about a certain subject can be very helpful in building trust, creating a team and to reveal impediments. Of course it can be very difficult to get team members to express their real opinions, especially when a team has just started. I think with patience and the right approach trust can (and will) be built and it will be easier to get real issues out in the open. The following practice can help you start this and make explicit what individual opinions in a team are.

I have used the following retrospective practice for several years now:

Continue reading How to fill your happiness metric

Simple Event Sourcing – conflict resolution (part 4)

After our deep dive into a Redis event store implementation we’re now getting back to actually adding functionality to the blogging application. Like the Getting started with Rails guide we’ll add the capability to add comments to blog posts. Adding this functionality is straightforward, but it will require us to look into resolving conflicts when multiple people make modifications to the same blog post or comment concurrently.

Continue reading Simple Event Sourcing – conflict resolution (part 4)

Simple event sourcing – Redis event store (part 3)

In the previous part we developed a fake event store for our blogging application. This event store just kept all events in-memory, making it unsuitable for production use. But it did allow us to adapt our application to using an event store, and let us work out the details of the event store interface without having to worry about an actual persistence mechanism.

In this part we’ll develop an event store implementation on top of Redis, a key-value store with support for additional data structures (such as lists and hashes), publish/subscribe, and transactions. If you’re more interested in adding new application functionality, you can safely skip this part and go to part 4 – conflict resolution.

Continue reading Simple event sourcing – Redis event store (part 3)

Simple event sourcing – consistency (part 2)

In the first part of this series we developed a simple blogging application that uses event sourcing to keep track of all changes made by the users. However, we did not yet write these events to durable storage. This means all data is lost when the application is restarted, which is clearly not acceptable. Saving and restoring events will be the responsibility of the event store, which we’ll start implementing in this part. But before we get to actually writing events to disk, we must first tackle the problem of maintaining data consistency when using event sourcing.

Continue reading Simple event sourcing – consistency (part 2)

Simple event sourcing – introduction (part 1)

This is the first part of a series on building an event sourced application. We’ll build a simple blogging application (inspired by the Ruby on RailsGetting Started” tutorial), so the domain should be familiar. This allows us to focus on implementing a memory image based architecture using event sourcing. Another goal is to show that this kind of architecture is not more complex (and arguably, simpler) than those implemented by traditional database centered applications. The example code is in Scala using the Play! web framework, but should be understandable enough if you come from a Java (or similar) background.
Continue reading Simple event sourcing – introduction (part 1)