According to the Wikipedia, a cowboy (and a cowgirl) is an animal herder who tends cattle on ranches in North America, traditionally on horseback, and often performs a multitude of other ranch-related tasks. They were quite famous in the 19th century and we can still find them in ranches.

original cowboy

Hollywood adapted the cowboy lifestyle to create some stereotypes, both positive and negative. But, in general, a cowboy was a guy with a gun killing people, either because they were bad guys or because they were defending a good cause.

Hollywood cowboy

As we’ve already said, there are still cowboys nowadays, either on ranches or in your development team. What is a cowboy in your development team? They use to share some common characteristics or behaviours:

  • They don’t like to pair program with anyone.
  • They have a silo of knowledge that they are not keen to share.
  • They make changes in Production boxes by hand.
  • They only participate in team meetings to patronise the rest of the team.
  • They write long emails (or slack messages). Again, patronising the team.
  • They don’t ask the team for consense before making decisions that can affect the team.
  • They are often “good” developers.

And we can continue with that list forever.

We can differentiate two types of development cowboys:

  • The Lucky Luke type: They are good guys, they don’t kill anybody but they can destroy a project. They don’t really know they are cowboys and within a good environment, they can change. A good example is Brent from the book The Phoenix project
  • The Billy The Kid type: They like to be cowboys and they think cowboys are great. They can kill people, teams and projects. They especially like to hurt the project so they can demonstrate they are brilliant and they can “heal” it. They don’t like teamwork and they will show it as often as they can. A good example can be the guy who is sitting next to you.

There a couple of characteristics that make cowboys appealing to some kind of managers (those managers that you don’t want to work with): they are often “good” developers and they make changes directly in the production boxes. Some managers like this kind of hacks to overcome some problem. Even though there is no rush, they want to get rid of that problem quickly, so there’s nothing better than someone that hacks something in the production box, or make a quick change in the code and copies the file directly to production, or whatever. The problem is that by solving that problem quickly they are creating N problems more, where N is usually a big number.

Is there any way to remove this bad behaviour? The main one for me is to avoid these people working alone. So setting a WIP in your project that forces people to pair program (instead of using pull requests, that you should avoid) seems very reasonable in this situation (and not just for this reason). The main problem you’ll have with this people is knowledge sharing, so adopting XP practices is very compelling.

And don’t forget that although we need to try to make people work well in our team, we have the possibility of fire people. We’re not talking here about culture fit (which we can discuss if is reason enough to fire someone), but about someone who is undermining your project and your team.


Pull requests are a common way to integrate your changes in another repository or branch in an Open Source project. They allow the receiver of the pull request to easily view and review the changes you made. Pull requests are great, especially when your team is not colocated, but also in different time zones. It seems that their popularity has extended to enterprise projects as well, even when the team is co-located. Is in this situation when I consider pull requests a bad smell of team dynamics.

Our story starts after the sprint planning. Every member of the team chooses a story to begin working on and creates a branch. After several days working in this branch (and maybe in other ones), he decides is a good time to create a pull request. The pull request can be something like this:

giant pull request

The poor team member that takes responsibility of merging the pull request spend the whole day reviewing the changes. You can imagine the quality of the review.

Another problem you can have with pull requests is that you can review easily the changes that the sender has made but, what if he missed making a change? Imagine that you are changing the actions of a controller to async methods and you miss a couple of them. When the reviewer reviews the pull request, she will see all the actions that you’ve changed (or added or removed) but it won’t be easy to spot those actions you missed to update.

So, what can you do to improve this situation?

The first option is to avoid the necessity of reviewing changes. Work in pairs when you develop a new story. I know that you can’t pair all the time but use this tool as much as you can. The results will be much better because pairing is much better than reviewing. Talking with your partner about design decisions, naming, etc. is much better than just reviewing some code with much less context.

If you can’t pair, at least review the code with its creator. Take a seat next to her, use your favourite remote pair programming tool or start a hangout/webex/whatever and go through the code. Ask for explanations of the decisions, test new approximations, discuss naming. But have a face to face conversation with her.

If for some inexplicable reason you can’t pair or review the code with its creator, use tiny pull requests. Obviously, this is a general advice, please define small and incremental stories that involve the less code possible. The code will be better and the life of the teammate that will review the pull request will be much happier.

I approve this pull request

On 1st and 2nd of December, the last edition of Conferencia Agile Spain was held in Vitoria. I was part of the oragnisation and both as a organiser and as attendee I think it was awesome (post with some of the internals will come soon). I held a workshop about Event Storming there, which went great. Chris Matts did the opening keynote and he attended my workshop too. In the middle of the workshop he approached to me and told me: “If you want, after the workshop I can explain you how can you join Event Storming and Real Options.” Of course! I said.

So, along with Silvia Calvet and another guy who I can’t remember his name (sorry about that mate!), Chris did a one hour master class about Risk Management and Business Analysis. For me it was the best session of the conference and it wasn’t in the agenda :-)

The summary of the master class could be: “Event Storming is a great tool when you know what do you need to do, but there’s a bunch of very important activities that you have to make before getting to this point.” And after the explanation (and with my limited experience in this part of the development of a product) I agree. Event Storming a great tool even for discovering hidden points in your domain and your solution, but its position is further down in the list of activities to do when releasing a product. It would be great to know Alberto Brandolini’s opinion about this point.

So, what Chris Matt’s think the process should be? Let me explain you with the example he used. Bear in mind that he did a basic summary of all of his experience, I’m sure there’s a lot more.

Imagine that you want to produce something that helps you to make tea (a teabag, basically). First of all you need to study the needs of your users? Why they need a teabag? To make and drink some tea? Or maybe to change the colour of their curry?


Let’s say we want to drink some tea. What are the needs we want to fulfil? Could be a bunch of them like:

  • because the user wants to be warm
  • because the user is thirsty
  • because it’s a social activity
  • because it’s a habit

Those needs can be different for different users. We need to study which segments of users we have because maybe we want to focus in one of them:

  • commuters
  • friends
  • old ladies

And finally we have to study which business value we want to get from our product:

  • money
  • engagement

Needs, business value and segments

As you can see we’re not inventing any data here. We’re just collecting what our users want. We’re not relying on someone having a magic idea.

With this data we can construct a matrix. In one axis we can put the different segments we have, in another one we can put the different business value and in the different cells we can put how many insights we have for that pair. With that information we can see where we need more data.

So we now have lots of data and we want to develop the next killing feature of our app. How can we know which one we have to choose?

For each insight we have we need to specify which Business Value (PO), Need (UX researcher) and Segment (UX researcher and data analyst) that insight is for. With that, we can start doing a design brief. That means that we’re going to explore which options do we have, how the application will be and with the help of different types of testing decide if the epic worths the effor. This is obviously an iterative process. If the epic worths the effor when now start to explore it in more details. And here is where EventStorming comes to action. It can be a great tool to transition from this epic we want to implement, to the different stories we need to implement.


Chris explained another way to go from the epic to the stories. For him, the inventor along with Dan North of the Given-When-Then, it’s quite natural to specify the stories in this format and he developed a technique that I really liked a lot.

Imagine that your developing an Imdb for music and you want to provide a feature for the segment fans where you can see the places that are important for a music star. Let’s then start with the most important outcome for you

Then displays the map
and my location
and the music star sites

What have the user to do to achieve this outcomes?

When I'm near a music star site

Which are the context of this action?

Given I'm a fan of a music star
and I'm GPS enabled
and there are sites for that music star

And there you are! You have your Given-When-Then backward developed. Two important addendums to this technique:

  • The context in a Given-When-Then can be mocked. That will be important when you want to develop a quick prototype of the feature.
  • The Given of your first Given-When-Then can be the Then of your previous feature. In this example, we can end up writing something like

    Given blah blah blah When blah blah blah Then I’m a fan of a music star

And that is super cool and I think in some way links with the EventStorming idea, when that can be a domain event and we can think from that which are the options we have to produce that event.

Maybe for you this is something quite trivial and known, but for me was something exciting to discover. There is a well known process that helps us to discover what is the most valuable feature to deliver. I think that’s quite related to the work that Fatma and Nazli explained ThoughtWorks is doing in some projects. I will put the link tho their talk here.

This conversation with Chris was eye-opening for me. It opened a door into a world I didn’t know about it and that I find fascinating. To get deeper in this idea, I attended the workshop about Design Sprints from Silvia Calvet and Gastón Valle and I found it amazing. I really want to do this kind of things as soon as I can and study more about this.

Pattern matching is a powerful and amazing characteristic of F#. Actually, is so amazing that Microsoft is starting to port it to C#.

There are different kinds of pattern matching. In this post we’re going to take a look at a partial classification active pattern that takes an argument and returns a value.

As its name denotes, is a pattern that partially classificates what you match with it. That means that doesn’t try to define all possible options but just one. This is quite convenient when using an active pattern to define a business rule of your domain, because you can split the different cases in different partial active patterns making your code much more readable.

You will identify a partial active pattern because the definition looks something like this:

let (|WithRemainder|_|) divisor divident =
    // active pattern code
You can see between brackets the name of the classification followed by the wilcard name (_), the two of them between . Just after that you can see the two arguments that the function will take.

This kind of active pattern has to return an Option value. In our case, we are going to return the remainder, if any. So our active pattern will look like:

let (|WithRemainder|_|) divisor dividend =
    let remainder = dividend % divisor
    if remainder <> 0 then Some remainder else None

How we use it? Well, the first time you see this active pattern applied can seem a bit difficult to understand (at least it was for me! :P), but is not that difficult:

match 10 with
| WithRemainder 3 r -> printfn "The remainder is %d" r
| _ -> printfn "No remainder"

The difficult part here is to see that the value in the match sentence is passed as the last argument of the active pattern. For example, in our case 3 is the divisor (first argument), 10 is the dividend (second argument) and r is what the pattern returns inside the Option type, in this case the remainder (is not the Option type, is the value itself). Once you understand that, there will be no secrets for you to create and use this kind of active pattern!

When you have some unit tests developed using NUnit 2.x your FAKE script looks like something like this:

Target "RunUnitTests" (fun _ ->
    !! (testDir + "/*.Tests.dll")
    |> NUnit (fun p ->
          {p with ToolPath = "packages/NUnit.Runners/tools/"}) )

But NUnit3 works slightly different. Instead of having a single NUnit.Runners package, that package references some other packages (runner, extensions, etc). One of those packages is NUnit.ConsoleRunner that has the exe inside the tools folder.

But changing the ToolPath in the FAKE task is not enough. You should use the new NUnit3 action, which is inside the Fake.Testing module. So, we need to open the module and change the task definition:

let nunitRunnerPath = "packages/NUnit.ConsoleRunner/tools/nunit3-console.exe"

Target "RunUnitTests" (fun _ ->
    !! (testDir + "/*.Tests.dll")
    |> NUnit3 (fun p ->
        {p with ToolPath = nunitRunnerPath}) )

And hopefully when you run the FAKE script you’ll have something like this:

NUnit3 Results