maandag 31 juli 2017

That Guy - This Guy - an agile retrospective method

This morning we tried something new during our biweekly retrospective. The method I used was based on "That Guy - This Guy", from the book "Fun Retrospectives, by Paulo Caroli and Taina Caetano, but with a twist.

Let me describe the method in some detail before explaining my expansion.
Before starting and welcoming the participants ( I think there were about 7 of us), I drew this illustration on the whiteboard.

I explained:
"Try to recall co-workers from past teams - NOT your current team. Picture in your mind two of them. 'That guy' was terrible. The instant you get the message that you will be in the same team again as he she, you start having nightmares, you start screaming about jumping from the roof or you decide to solicit at a competitor. Instead, 'This Guy' rocks. The instant you hear you will be in the same team again, you start thinking about throwing a party, and phantasize about a promotion."
"I request you to write notes about the qualities of such a person. As for 'That Guy', plz don't mention any names. Not even a hint. And what I said about Guys, also applies to Gals."
When everyone had written their sticky notes, they put them on the blackboard. We discussed them and grouped them.
All sticky items had, on my request, been put above the dotted line.

The second phase I appended as the original method, in my humble opinion, lacked action items. I presented two options to the group, and later realized there was a third.
1. Choose one of the properties listed under "That Guy" or under "This Guy", on which you want to work during the next sprint. Note it in your agenda for reference during our next retrospective in 2 weeks.
2. Choose one of the properties listed under "That Guy" or under "This Guy", on which you want to work during the next sprint, and stick it on the board, thus sharing it with the rest of the team.
The first option is very safe. Some participants preferred the first, safe option. The team deliberated about which of the two options, and finally choose the second option.

Afterwards, I realized there was a third option:
3. Choose a teammate, and let him/her indicate what (s)he sees as a weak point which you might like to work on. Note that this remark is intended as a gift, not as a criticism.
If you want to present the third option, you should realize that this may be sensitive. Teammates might feel a remark as criticism. It takes a lot of courage to choose this item. It may easily be (mis)used by team mates to finally throw out irritation which has built up in the team over weeks or months. If you are not confident about your skills as an agile coach to handle such a situation, simply don’t present the third option. The intention of the third option is to give your teammate a gift: give them your insight on what aspect of his behaviour your teammate might grow most or best.

donderdag 11 mei 2017

Agile voting

Of course you want consensus. But building consensus takes time, but sometimes consensus is hard to obtain. Sometimes you don’t have the time to talk on and on, or everybody is bored. Sometimes we need to vote.

Here is a one pager with ways to vote.

Three dots
Give every participant 3 dots. These dots may be post-its, or coins, but are usually made with a highlighter
Every participant distributes his/her dots among the options: one for three different options, all three dots for one option, as the voter sees fit.
The option with most dots is chosen (or top 2, or top-3)
You can vary the number of dots as you see fit.

Fist of five
Every participant is asked to raise his/her fist in the air.
Vote leader mentions option and counts from 5 to 0. On 0, every participant raises 1 to 5 fingers simultaneously.
Participants raise 1 to 5 fingers.
Note number of votes and continue with next option.

Roman vote
Everybody votes at the same time in the way on an option in the way that the roman emperors decided on the fate of a defeated gladiator in the arena: thumb up or thumb down. Keep track of the number of thumbs up/down and choose after all options have been voted on.

List all options.
Hand every participant as many cards from a set of planning poker cards as there are options. Thus, if there are 5 options, each participant gets the cards 0, ½, 1, 2 and 3.
Participants distribute their cards over the options, one card per option.
Item(s) with highest score(s) is(are) elected.

You can find references to the methods described above at the end of this post. Here are two new methods, which I intend to try out in the near future.

Put your money where your mouth is!
Prepare by making small bags with 1 x 50 cent, 2 x 20 cent and 1 x 10 cent
Hand one bag to each participant
Participants distribute their coins over the options, taking turns. Optionally, they may explain to their team mates why they vote as they do.
Option with most money is valued highest.

Prepare a sheet with 4 lanes consisting of up to 12 squares each. Make one marker for every option, mark it with a short one word name.
Hand every participant the cards 0, 1, 2, 3, and 5 from a set of planning poker cards.
Participants take turns to move the markers to the finish by playing one of their cards and moving the marker the number of indicated squares.
Voting ends at the end of the round in which the first item crosses the finish line.
Two or more items may cross the finish in the same round, furthest option wins.

References: - dot voting - fist of five – planning poker voting – roman voting

zaterdag 22 april 2017

The story of a feature

In their book “Fun retrospectives”, Paulo Caroli and Taina Caetano describe an activity “The story of a story”. Last Monday, we used this format to analyze why we had not finished any activity for the feature which we had assigned the highest priority during our planning session.

Different resources on the web distinguish different phases or steps that apply to a good retrospective. I like to group them as:

The activities we performed in our session are:
1. Scrummaster draws the timeline
2. Srummaster explains the technique to be used
3. Scrummaster announces of the scope (what happened during the sprint that influenced not completing these activities)
4. Participants write down post-its with relevant events
5. Participants stick their notes on the relevant place in the timeline
6. Participants explain their notes for the group.
7. Group discusses the notes
8. Group formulates lessons / improvement opportunities / action items

The steps 1-3 belong to the “set the stage” phase. Steps 4 and 5 collect the data, step 6 analyzes the data while step 7 and 8 represent the last two phases. As always, formulating action items was the hardest part of a retrospective.

Example of timeline:

The result was that we had a pretty clear picture of what went well and what went wrong.


maandag 5 december 2016

Scope of retrospective

Just as planning encompasses all aspects of the sprint, the retrospective covers everything that is part of the sprint.
Often people tend to look at what went well or what went wrong during sprint execution. Why did we get stuck so long at getting that new tool up and running on Jimmy’s pc? How could it happen that we only discovered that team Jay had moved their user story, on which we depend, near the end of the sprint? There is nothing wrong with questions like these. But we may be inclined to overlook that we may also want to evaluate what we may learn during refinement and planning. Even the way we hold our retrospectives may be part of the retrospective!

woensdag 24 augustus 2016

BPMN: End Event or End State?

When the guys of bizzdesigner taught one of my fellow consultants about process design, they taught him that every process should have exactly one Start Event and exactly one End Event. Personally I have always disagreed with this point of view. Having one End Event creates ugly, artificial diagrams. I discovered that diagrams were much clearer when End Events depict the possible end states.
This morning I was pleasantly surprised when I found that Bruce Silver in his book "BPMN method & style" advocates exactly the same thought. Judge for yourself, which diagram is clearer:
It may be a matter of taste, but I definitely find the first one more clearly. One reason is that "Order finished" is a bit abstract, while "Order failed""and "Order completed" are more informative
Another reason is that having the possible results clearly labeled, the different labels gives your reader a first check wether your process description is complete or not.
The 2nd representation may be more correct from a theoretical point of view. In the second diagram, we have an End Event which actually represents an End Event. In the first diagram, the End Event represents more an End State than an End Event. Still, the BPMN 2.0 explicitly states: "There MAY be multiple End Events within a single level of a Process.". So when possible, I prefer the representation which gives the highest amount of clarity.

Some loose thoughts on end events:
  1. In the above illustration, both diagrams have the end results on the right, which is good. It makes a diagram easier to glance over. Some people do not start reading at the start, but start reading with the result in mind.
  2. I often see End Events labeled as "End" or "End Event". Usually these labels are the result of sheer laziness, though occasionally they result from insufficient knowledge of the tool or lack of time. And to be honest: I am guilty of the latter. Do take the slight amount of time to label your Start Events and End Events properly. It will please your readers.
  3. The use of multiple End Events may be discouraged in some simulation tools, where the consumation of a token generated by a Start Event stops the entire instance. Any such implementation is i.m.h.o. against the BPMN intention: the process should run untill all tokens (the token from the start event may have been duplicated in a Parallel Gateway) have been consumed.

donderdag 14 juli 2016

Life long learning

One of the regular topics on this irregular blog is learning. For virtually every professional, but especially those with a link to IT, lifelong learning is a MUST. And with MUST I mean AAN=An Absolute Necessity.

1) AAN
Let me give you an example of what may happen when you don't spend time learning. It comes from the practice of our oldest daughter, Margreet, who is doing het master in education. She was asked to evaluate the introduction and coaching of new teachers at a confederation of schools. The management of the confederation organized individual coaching, but also offered a training course given by a 1-person institute. This training course received very bad reviews. Part of the required evaluation was finding out why.

During the evaluation, one of teh findings was that the person giving the course knew a number of (fairly known) models, which the young teachers all had learned at school. Now that may have been a signal that both school curriculum and training course offered the most modern insights, but alas that was not the case. The training course might still have been valuable if it had been aimed at the application of theoretical knowledge in everyday practice, but it didnt even offer that. My personal conclusion is that the trainer had failed to keep learning. She had not learned from modern insights, and she had not learned from the reactions of her students.

2) Learning and exercise
Having stated again the necessity again, here are two fairly modern insights in learning. The first is a finding by van Dongen et al, titled "Physical exercise performed four hours after learning improves memorey retention and increases hippocampal pattern simularity during retrieval".

As the title already says, the reserachers found that you remember your learning better if you do physical exercise some four hours after the learning session.
The question which immmediately popped up in my thoughts was: how can I implement this in my 40 hour workday? This is al nice and fine when I have a training day: in the evening I go and do a session of jogging. But how can I do that when I have worked all day and have an evening training? No easy solution here.

3) Cinnamon
Cinnamon, especially Ceylon Cinnamon, might enhance learning ability. Kallipada Pahanand and Floyd A. Davix found that cinnamon consumption by mice enhanced their learning ability. They tested this with mice, not humans, which seems to offer a nice area of research. Note that Chinese cinnamon contains small quantities of a liver toxic, so search for Ceylon cinnamon if you want to use yourself as a human guinea pig.

zaterdag 11 juni 2016


Why do we do business process modelling (BPM)? What is Business Process design? Why do we gather requirements? How does BPM relate to requirements gathering? How does BPM relate to agile environments? What is the role of requirements in agile development? These are the questions I have been asking myself over the pas few months, and I intend to do a series of posts on these questions on this blog.

Let’s start with the question:
What is business process modelling (BPM)? Why do we do it?

What is Business Process Modelling?
Let’s start with three definitions:
(Business) Process design is the activity of determining the workflow, equipment needs, and implementation requirements for a particular process. Process design typically uses a number of tools including flowcharting, process simulation software, and scale models.

What is a business process?
A business process is a set of logically related business activities that combine to deliver something of value (e.g. products, goods, services or information) to a

Business process modeling (BPM) in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed or improved

These three definitions, divers as they are, do cover most or all of the aspects of BPM. A business process is a set of related activities that combine to deliver something of value.

Business Process Modelling is the art of describing processes in such a way that all stakeholders understand the entire process. It is not uncommon that, when a process is being modeled for the first time, some participants understand the process for the first time.

Now why do we do it?
(1) Historically, organization charts were drawn, and responsibilities were assigned to the managers of the various departments.
For example, a factory could be described by the following chart:

During the 20th century, people increasingly became aware that this distribution of responsibilities had its limits, as some processes spanned one or more departments. For example, when a company switches to Just-In-Time delivery, the first step might be to sell a product. When the product is sold, Production might be ordered to produce the product, which in turn asks the Purchase department to buy the necessary resources.

But there are more benefits to BPM than spanning departments.
Let’s have a look at an imaginary business process. In a large software firm, customers can hire consultants. It is the task of the account manager to find the right consultant for a temporary job at a customer.

The process consists of a number of steps:
  • The account manager receives a request from a customer for a consultant.
  • The account manager reads the request and elicits the required skills from the request.
  • The account manager is responsible for matching the required skills with the skills of the available consultants. This matching results in 0, 1 or more consultants.
  • The account manager selects a consultant from the list
  • The account manager writes an offer
  • The account manager sends the offer to the customer
  • The account manager introduces the consultant to the customer.
  • After the customer decides to hire the consultant, he returns the signed contract. 
  • The account manager receives it,
  • The consultant start his job.
Why do we do it?
(2) Process modelling is a powerful tool. It gives all stakeholders a view of what happens by whom. Note that roles are applied, not departments, because roles are much more stable than departments. The flowchart listed above is an excellent tool to ask further questions, such as:
  • What do we do if there are no consultants available with all the required skills?
  • What happens when the customer wants to interview several consultants?
  • What do we do if the customer does not return a signed contract?
  • Does the account manager ever has to adapt his offer?
What-if questions like the above are a great way to complete our understanding of what happens. Usually, this results in extra branches. In the following diagram, if he finds 0 matches, he re-evaluates the required skills. Perhaps not all skills are as b=necessary as he thought? Perhaps he misread something? He may also contact the customer for any clarifications as part of this sub-process.

(3) A third benefit is that describing a business process makes it possible to analyze what is happening. How many offers do the account managers write? How many hours do they spend on writing? How many are granted? What process takes most time?

Optimizing a process is an important step before we start automating tasks. For example, it may turn out that a low percentage of the offers we send get accepted, because the offers do not match the customers expectation.
By changing the sequence of the process steps, we can increase our hit rate:

In the above diagram, the consultant is first introduced to the customer, and only if the interview is successful, the account manager writes an offer. An added advantage is that, if during the interview extra conditions are demanded, such as a free first week, the account manager can write them into the offer right away instead of writing a second version later.

So far we have seen three advantages of BPM:
  1. Crossing department borders
  2. Giving all participants an overview of ‘what are we talking about?’
  3. Tool for optimizing a process
And let me stress again that we should optimize a process before we start to develop software to automate sub-processes.

(4) A 4th advantage is that a good business model is a tool to pinpoint problems. We already saw an example in the previous step, where the offers had a low hit rate. The cause of the problem was that the offer was written before all information was complete, it is, before the interview. During the interview, additional information and condition for the interview could surface.

(5) A 5th advantage is that we can simply pinpoint which sub-processes or which activities we want to develop software for.

In our example, we might color the sub-processes:
In the above diagram, the sub-processes “match skills” and “write offer” will be the target of a drive to improve process execution by software development. In other environments, many more sub-processes can be automated. Think, for example, of a web bookstore where both the purchase of books and the sales of books, as well as the payments involved, are automated, with only the shipping and complaint handling remaining as manual operational processes.

(6) A 6th benefit of BPM is as a tool to gather the requirements for an information system. In the example above, for the “match skills” application, the model will lead us to ask questions like:
  • Do we still want the account manager to extract the required skills from the process? (=do we have the right scope?)
  • Are the skills a fixed list, a free list, or a combination of both?
  • How do we gather the skills of all consultants? Do we have already a registration of them? Or should this be a new data collection?
  • Should the “match skills” sub-process take into account if a consultant is available now or in the near future?
  • What exactly is the output of this process step? Just a list, or is there more? What is on this list? Name, skills, availability, current jobs?
  • Should the system support free text search on the resumes of the consultants?
  • And so on

(7) A last benefit of BPM is making sure that we are automating the right processes and elicit the right requirements ( We do this mainly by restructuring and optimizing the process first and automating it later. But the definition of the process steps also helps to define the right requirements. If we know there are two flows entering a process step, we know that we likely have 2 types of input, and will want to specify the information in these flows. It may turn out that we need information which is collected three process steps earlier, and we may want to adapt some of the previous or training process steps.

In the description above, I have deliberately skipped some concepts, such as the distinction between process analysis and process design. Another concept I have skipped is that of detailing processes in sub-processes, process boundaries, iterative analysis, and so on.
In subsequent posts I intend to write more about questions like: How does BPM relate to requirements gathering? How does BPM relate to agile environments? What is the role of requirements in agile development?