Skip to content

Feed aggregator

Book Review:: Agile Noir by Lancer Kind

 Agile Noir by Lancer Kind    and I'm envisioning a 1956 black and white film Kartar is the metaphor of his project.

First, allow me to layout some ground rules and a touch of the backstory...

I'm not a professional book reviewer, nor paid in anyway to read.  But if I could get that gig... I'd be a happy camper.  I've never written a book, but I've hacked out some code, a few articles, some of which might be considered book reviews.  I've worked in the Agile industry for more than a decade (but who's counting), and so - I may be a little close to the topic to have proper literary impartial bias.  In fact let me just go ahead and be explicit - I've done this, been there, got the t-shirt; I shit you not - this shit is for real!

Agile Noir by Lancer Kind
Now the ground rules...  I think this review will be written ... what's the word... while I'm reading, at the same time, without much delay in the reading - writing situ.... iteratively... oh I give up...

So don't be surprised - dear reader - if I just drop off in the middle...
                       ... maybe check back every week until I finish
March 22,
I've studied the cover... quite a nice graphic - to bad the whole novel isn't a graphic novel; oh - maybe it would be too bloody,  I could see Agile Noir becoming a Tarantino film.  As I sat looking at my book to-do stack... I skipped a few levels down the stack and pulled out Lancer Kind's 2016 Agile Noir.  I have read some of his previous comics titled Scrum Noir (vol 1, 2, 3).  So maybe I know what to expect - should be a fun romp in the fast lane with lots of inside the industry puns, innuendo and metaphors.

Well the damn dedication just reeks of an Agile Coach - Servant Leader (puke, barf.... moving on).

The High Cost of Schedule Slip
Now you may not find the situation Kartar finds himself in funny...  allow me to add some overtones of irony....  I'm going to go out on a racist limb and suggest that Kartar is an Indian.  That he is working in the heart of the Indian nation (Los Wages, NV), perhaps on a job for an Italian crime boss.  And none of these circumstances have anything to do with one of the world of science's biggest failures - Columbus's discover of the New World - which the thought was India, and named it's inhabitants there by creating the confusion we will have to deal with evermore.  Now Columbus was of course searching for a way to reduce the schedule required for shipping spices.

Kartar appears to be very emerged in planning and the art/science/pesdo-truth of planning and predicting the future of projects.  And he may be a master with the Gantt chart (which is footnoted on page 18).

This is all ringing just too true ... and I'm envisioning it in the style of a 1956 black and white film...

Kartar is the metaphor of his project... it seems that it's not quite on schedule... he's late to a just announced meeting with some superior and is driving at break neck speed on loose sand in the Vegas out skirts creating over bumps and ditches in his car with the accelerator pinned to the floor - because some people in a van might be trying to kill him.  Happens ALL - THE - TIME.

April 4th
Finished chapter 1.  That Bastard.  He killed off our hero Kartar.  oh - OPPS - SPOILERS!
I truly don't know if I should throw the book in the garbage bin or keep reading... going to bed.

April 6th
OK - that was quite the trick, Chapter 2, Rowing over a better Waterfall is a twist... but now it's getting interesting and our hero is back, yet I fear not quite in control of his project.

April 10th
The chapter Death by Documentation is just that... a death march, I almost quit.  The chapter is worth skipping if you have ever been on one of these classic projects - then you already know enough to thumb to page 89 and restart.  However if your not in IT or project management work of any type (Record Scratch: then how in the heck did you find my blog - and why are you reading this book?) you might enjoy the chapter as it will explain how all of your companies IT project fall behind schedule and never deliver what you want.  Read it - little bells of enlightenment will chime in your head.

The introduction of the IT Mechanic is quite fun.  He's almost a stalker... yeah, he's definitely a PM stalker.  This character is going to be fun.  He's reminding me of someone I've met... and someone from my youthful days of reading Carlos Castaneda.  The character's name is "J" could it stand for Jaun (as in don Jaun Matus)?  He's got an interesting calling card with no numbers or email addresses.  I'd recommend he try Moo - best printing house in the business.  J has some psyc skills and quite a few trick up his sleeves (he is living in the land of Penn & Teller after all).

I really enjoyed this chapter, but then almost any thing would be great after that death slog of documentation hell.

April 12th 
Sprinting is the right word for the next chapter... it's a dash by Usain Bolt.  In Sprinting with a Bollywood Autobot Kartar learns to write user stories and mix drinks of analysis, design, requirement, and development.  He attempts to negotiate on delivery with the owner and in the end crosses the third rail of the PMI tracks in a Lovers quarrel.  Oh - damn, that's not at all what happens.  But it's a lot of fun and went by really fast.  Don't know if we can sustain this pace for the rest of the book.

April 19th
Scrumming in a Waterfall - nice visual, great chapter.  I'm pulling for Kartar, he's doing all the right behaviors, making mistakes and learning each step of the way.  One day he's going to land this project in the success column of management's spreadsheet.  It appears that's how interested the big boss is in the project (affectionally called "Winner").  It's right when Kartar is about got the dirty little secret of Scrum figured out in this iteration that the Lovers, Sis & Lex show up and we cycle under the pressure of the waterfall, tumbling and gasping for air.  

How do you explain water to a fish?  I'm thinking that Kartar is learning all kinds of things in this iteration.  He's gotten lesson at the firing range, upgrade his tiny pistol to an arsenal that Fiona Glenanne (Burn Notice) would be proud of - maybe she'd invite Kartar to show her his car trunk.

But by the end of this chapter - we are back in the rabbit hole with Alice and late, we're late, for an important date.

April 23rd
I've come to understand something about "new new product development" in the software world... it requires great Product Vision and this chapter illustrates a wonderful secret of the process.  This is a wonderful view of the typical company move to the Agile mindset.  Place yourself in Kartar's view and you may believe you have the system figured out.  But is there something missing?  All the teams are scrumming and getting along, produce working software.  It's a happy time on the project.  I'm left wondering what could possibly happen next (hint its not near enough to the end of the book).

April 30th
The next two chapters are great... I couldn't put down the book, had to see Kartar's fate - could he ship the Winner, or would the PMI high priestess Lex & Sis reclaim their underling that has gone astray?  Yes (SPOILERS), of course he get's his team doing Scrum, and the the other's join in the game to ship working software... but what stresses might this cause within this Vegas eco-system?

Well, you may make a guess - but it might surprise you how this project to produce the mobile gambling game-boy turns out.  And if there is a hero... I'm sure it's not Kartar, but he doesn't disappoint.

Addendum ~=  Moral of the Story
The last two chapters, are really addendum, or afterward, for those of you who wish to go beyond the story and understand the underlying moral.

So at this departure point, allow me to confess.  I enjoined this task of reading Agile Noir to answer one personal question:  Would reading a fictional story of a character going through the mental transformation of becoming Agile, be as powerful as a two day workshop that results in a certification, and the beginning of a lifetime's journey to agility, and JOY in the workplace?

This is a difficult question to answer from my current perspective - I would love your (dear reader) answer - it may be much more realistic than my answer.  I believe (I want to believe - me and Muller) that this could be as powerful to a ready open minded person, as an introductory 2 day class.  So my answer to the primary question: YES!

Now one might want to know WHY?
I have an idea why this technique may be just as powerful - maybe better scalability, and in general better ROI.  Come back after this idea bakes a few days...

Table of Contents:
  1. The High Cost of Schedule Slip
  2. Rowing over a better Waterfall
  3. Death by Documentation
  4. The IT Mechanic
  5. Sprinting with a Bollywood Autobot
  6. Scrumming in a Waterfall
  7. Product Vision
  8. Sustainable Pace
  9. Liberation and Libations
  1. Agile Development is about having FUN!
  2. Why Let Your Framework Limit You?

See Also:
Scrum Noir - several volumes of graphic novel about scrum masters and the projects they encounter - also by Lancer Kind
I will have a Double Expresso - Amazon review of Scrum Noir.
Categories: Blogs

Targetprocess v.3.11.2: Undelete Projects and Users

TargetProcess - Edge of Chaos Blog - Tue, 05/02/2017 - 07:59
Restore deleted projects or users

You can now easily "undelete" Projects and Users from the "Deleted items" menu in Settings. Previously, it was not possible to restore deleted Projects and Users without using the API.


Please find more info in the guide.

Visual Reports Improved

We recently made some nice improvements to the Visual Reports Editor. Read about them at this dedicated blogpost.

We really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at

Fixed Bugs
  • Fixed incorrect effort calculation in Burn Down charts when a Feature is removed
  • Added support for decimal values in custom fields on the Timesheet
  • Fixed: Contributors could not create Releases for Projects that they were not a member of
  • Fixed an exception that would occur when Test Plans and Test Cases on the same Board had different tags
  • Deleted Users will now have a strikeout through their name if someone tries to @mention them in comments
  • Processes are now sorted alphabetically in the Quick Add menu
  • Fixed an exception ('Oops...Something's wrong') that would occur when adding an 'Effort' custom unit to cards in a Person/State view
  • Fixed an inability to delete a Process that is used by deleted Projects
Categories: Companies

With Agile, No Warnings Needed

Johanna Rothman - Mon, 05/01/2017 - 21:20

Have you ever worked on a project where the management and/or sponsors felt it necessary to provide you warnings: “This release better do this or have that. Otherwise, you’re toast.”

I have, once. That’s when I started to use release criteria and check with the sponsors/management to make sure they agreed.

I happen to like release criteria. Even better is when you use agile on your projects. You might get feedback before the release. Here’s what a client did on a recent project:

  • They had release criteria and the sponsors agreed to the criteria.
  • They released internally every two weeks and asked people to come to the demos.
  • They asked the product managers and product owners to review the finished work and to make sure the managers/sponsors liked where the roadmap was going.
  • The team worked in ways that promoted technical excellence, so they could (relatively) easily change the code base when people changed their minds.

The project didn’t fulfill all the wishes that managers and sponsors wanted. Those folks wanted the proverbial 15 pounds of project into a 5 pound bag. On the other hand, the team is on the verge of delivering a terrific product. (They have one more week to finish.) They are all proud of their effort and the way they’ve worked.

This morning, the project manager emailed me. “I’m so angry I could spit,” she said. “One of our sponsors, who couldn’t be bothered to see any demos just told me that if he doesn’t like it, he’s going to send us back to the drawing board. Do you have time for a quick call so I don’t get myself fired?”

This is a culture clash between the agile project’s transparency and request for frequent feedback vs. the controlling desires of management.

We spoke. She realized it was a difference in expectations and culture that will take a while to go away. There are probably reasons for it, and that doesn’t make it any easier for the team.

These kinds of situations are why I recommend new agile teams have a servant leader. I don’t care if you call that person an agile project manager or some other term, but the person’s role is to run interference between the two cultures.

The worst part? With the project’s transparency and interim delivery of value, no one needed to warn anyone about anything. The data this guy was looking for was in the demos, in the meeting minutes and was easily accessible.

I don’t know why people think they need to provide dire warnings. It’s not clear what effect they want to create. Dire warnings make even less sense when the team uses agile and provides interim value and demos.

If you’re using agile approaches, and you see this happening, decide what you want from this relationship. If you think you’ll have to work with this person again and again, it might make sense to have a conversation and see what they really want. What are their concerns? What are their pressures? Can you help them with information at other times instead of a week before the end of the project?

Don’t be surprised if you see this kind of a culture clash in your organization as teams start their transformation. Managers have a lot to do with culture (you might say they are the holders of the culture) and we’re asking them to use different measurements and act differently. A huge change. (Yes, after the agile project book, I’m writing an agile management book. I know, you’re not surprised.)

Categories: Blogs

Scrum Day Germany, Filderstadt, Germany, May 30-31 2017

Scrum Expert - Mon, 05/01/2017 - 10:00
Scrum Day Germany is a two-day conference about Scrum and Agile project management that propose an international line-up of Agile experts. It provides a multi-track sessions and full day workshops....

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Agile Development Conference, Las Vegas, USA, June 4–9 2017

Scrum Expert - Mon, 05/01/2017 - 09:15
The Agile Development Conference West is an event focused on agile methods, technologies, tools, and leadership principles from thought leaders that takes place in Las Vegas. You will find at this...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Unconf, Kracow, Poland, June 2-3 2017

Scrum Expert - Mon, 05/01/2017 - 09:00
Unconf — the unexpected conference is a two-day event dedicated to the Agile and Scrum. It is provided in a nontypical way that provides both open space discussions and workshops. Talks will be in...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Some Laws of Software Development

NetObjectives - Sun, 04/30/2017 - 13:28
This blog continues my series on Going Beyond Practices to Achieve Objectives.  There is a significant difference between a law and a principle.  In Values, Practices and Principles Are Not Enough we defined them as: Principle – a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning Law – (natural laws) a statement of fact,...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Agile Coach Camp Canada, Cornwall, Canada, June 9-11 2017

Scrum Expert - Fri, 04/28/2017 - 10:00
Agile Coach Camp Canada is a three-day conference that creates opportunities for the Agile coaches community to share successes, learning, questions and unresolved dilemmas. All this happens in an...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Agile Open Canada, Vancouver, Canada, May 11-12 2017

Scrum Expert - Fri, 04/28/2017 - 09:00
Agile Open Canada is a two-day conference that creates opportunities for the Agile practitioners and enthusiasts of Canada to share successes, learning, questions and unresolved dilemmas. All this...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Synergic Reading Lessons

Wondering what other books I should read concurrently with the philosophy of this book, Other Minds, on the mind of our alien ancestors. In chapter one Peter is already mashing up Ismael and Darwin, so I feel it appropriate to do a bit of mix-in myself. I'm thinking Seven Brief Lessons on Physics will add spice. To bad I recycled How to Create a Mind at Half Price Books.

I've also got to read Coaching Agile Teams by Lyssa Adkins for work's book club. And I may mix-in a bit of LEGO Serious Play, because I cannot get serious about coaching - seems like a play activity to me.

Maybe I will devise a quadrant model of these books. A Venn diagram of their overlapping topics.

Squid Communicate With a Secret, Skin-Powered Alphabet

Categories: Blogs

New PMI-ACP Workbook

Leading Answers - Mike Griffiths - Thu, 04/27/2017 - 23:00
I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics. My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on... Mike Griffiths
Categories: Blogs

Tapping the Base of the Talent Triangle for Hidden PDUs

Leading Answers - Mike Griffiths - Thu, 04/27/2017 - 22:40
When it comes to renewing your PMI credentials it can sometimes be a challenge to find the full complement of Professional Development Units (PDUs) you need. Now the PMI Talent Triangle has been introduced, PMP credential holders need 8 PDUs... Mike Griffiths
Categories: Blogs

Announcing the PAS Workshop: Double Your Professional Impact in 8 Weeks

Scrum Breakfast - Wed, 04/26/2017 - 12:12
I have created a video about my new workshop on the Personal Agility System: Double your professional impact in 8 weeks.

The online workshop starts next week. You can learn all about it here, and you'll find a special 2 for 1 offer towards the end...

You can sign up and get full information at!
Categories: Blogs

An Introduction to Functors

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/25/2017 - 18:18

In a previous article, we talked about Semigroups and Monoids, which are abstractions that let us combine values of the same type together. In this post, we’ll take a look at Functors, which allow us to operate on values inside containers without having to know any of the implementation details of the containers themselves.

NOTE: This article is based on an Axosoft Dev Talk titled Practical Category Theory: Functors. Watch that video or keep reading!

Before we embark on our journey, we should probably take a quick trip through higher-kinded types!

Higher-Kinded Types

When we program in a language like C# or Java, we often run into “concrete” types like int, string, and bool. The neat thing about concrete types is that we always know all the operations that we can perform on them (ints can be added, bools can be negated, and so on).

One step up on the abstraction ladder are “generic” types, like List<T>. A fancy term for generic types is “parametric polymorphism:” “parametric” because we’re working with a type parameter, and “polymorphism” because the parameter in question can have multiple (“poly-“) shapes (“-morphism”). So, we know what operations we can perform on the List itself (iterate over all its elements, Add an item, etc.), but we know absolutely nothing about the type represented by T. This gives us a lot more power of abstraction because we can write methods that manipulate these generic structures and have them guarantee to work no matter what type we eventually fill in for the type parameter.

In Haskell and Purescript, we’d write List<T> as List t: the name of the generic type (List) comes first, and the name of the type parameter (t) comes next, separated by a space. Haskell and Purescript know that t isn’t the name of a concrete type (like if we had written Int or String) because it starts with a lowercase letter.

We can go one step further and write a type like IEnumerable<T>, where our container type isn’t a concrete type but is only an interface. Now, we know only a little bit about the container type itself (specifically, that it has elements over which we can iterate), and we still know nothing about T. The number of operations we can perform on a value of type IEnumerable<T> is even smaller than those for List<T>. This limitation is actually a good thing because now we can pass in a Stack or a Queue to a method that takes an IEnumerable, for example, and the method will work as expected.

Usually, this is where we would have to stop because most languages don’t let us go any more abstract. However, Haskell and Purescript don’t have this restriction and support so-called “higher-kinded” types, where we can make both the internal type and the container type fully generic. If C# had syntactical support for this, it might look something like T1<T2>. T1 could be IEnumerable, Queue, etc., while T2 could be int, string, etc. Haskell and Purescript, however, do support this concept of higher-kinded types and use this syntax: f t (where f is the container type and t is the type parameter). Because f is lowercase, we know that it’s generic as well as t, and so can be any type that requires exactly one type parameter. For example, the following types would fulfill f:

  • List, which holds zero or more values of the same type.
  • Queue, which also holds zero or more values of the same type, but doesn’t allow random access.
  • Maybe (A.K.A. Option or Optional), which can contain either one value or be empty.
  • Promise, which eventually produces a value.
  • A Redux store, which we can think of being parameterized by the type of the state it contains.

Whereas the following cannot be used for f:

  • Map, because that requires two type parameters, one for the key and one for the value.
  • string, because that doesn’t have any type parameters (another way of saying that is that the type string is already fully concrete).
  • Tuple, because that also requires two or more type parameters (depending on the number of elements it contains).
  • A Redux reducer, which requires two type parameters, one for the message and one for the state.
Fun Fact!

In Haskell or Purescript, the higher-kinded type parameter (f in f t) is usually named f or m, while the type parameter it takes (t in f t) is usually named a (or b or c if more than one is needed).


Granted, we really can’t do very much with a value of type f t because we intentionally don’t know very much at all about it. However, we can put constraints on our type parameters. In C#:

class Foo<T> where T : SomeConstraint

Now, T can’t be just anything but instead has some restrictions on what can be plugged in for it. After we’ve put one or more constraints on T, we now know more about what we can do with it. For example, if T is constrained to be an instance of IComparable, that means Foo will only accept types that support the CompareTo method, like int or char (but not, say, List<string>). In Haskell or Purescript, this type can be written SomeConstraint t => Foo t, which means that type t must support the operations in SomeConstraint.

In Haskell and Purescript, we can also place constraints on our higher-kinded type parameters, like so: SomeConstraint f => f t. Now, we know that f supports whatever operations are included in SomeConstraint, and we can plug in any type that supports them. This is approximately analogous to the idea behind IEnumerable<T>, where the container type is abstract and so we can choose a specific type, like List or Queue, to make the type concrete. (We might write that example in Haskell and Purescript as IEnumerable f => f t.) We can also use more than one constraint on a single parameter or place constraints on more than one parameter at a time, like so:

(SomeConstraint f, SomeOtherConstraint f, AnotherConstraint t, YetAnotherConstraint t) => f t

What all this allows us to do is to have a system of specifying the structures of values, which will come in handy when we get to Functors below. Higher-kinded types allow us to focus on values that have general structure, and we can narrow the possibilities down with constraints.

Phew, that’s a lot to digest. Here’s a summary of how the different concepts (roughly) translate between C# and Haskell and Purescript.

Concrete Types

We know everything there is to know about these types.

Haskell, Purescript
Generic Types

We know everything there is to know about part of these types.

Haskell, Purescript
Foo t

We know some things about various parts of these types.

// Constraint on the "traditional" type parameter
Foo<T> where T : IBar
// Constraint on the container type itself
// Approximately:
Haskell, Purescript
-- Constraint on the "traditional" type parameter
IBar t => Foo t
-- Constraint on the container type
IFoo f => f t
Higher-Kinded Types

We only know about the very general shape of these types, but we can place constraints on them in order to do useful things with them.

// Doesn't exist, but might look something like:
Haskell, Purescript
f t

Lo and behold, we’ve made it to Functors!

We’ve been making statements about the “structures” of types without a clear definition, so here goes:


Rules about how you can use a type (i.e. the operations that can be performed on it). In an object-oriented (OO) language, this might be represented by interfaces; in a functional language, this might be represented by modules or typeclasses.

IEnumerable<T>, for example, has a different structure from IComparable<T>, because IEnumerables can be iterated over, sorted, etc., while IComparables can be compared.

Functor is a specific structure that supports exactly one operation: map. map allows us to operate on value(s) inside a Functor (which we can think of as a container of some sort) without knowing (or caring) how the Functor is implemented. Each Functor has its own rules for how map works, but this general theme of manipulating contained values is the same.

You’ve already used map if you’ve ever used in JavaScript or LINQ’s IEnumerable.Select in C#, for example. You didn’t have to know how the container (the Array or specific IEnumerable) was implemented, since its implementation of map took care of that for you. All you needed to do was provide a function that takes an element of the list and returns something else, and the container handled the rest.

Without further ado, let’s take a look at map‘s type signature!

public interface IFunctor {
    // There's no second parameter, because this method is on the `IFunctor` we want to map over
    IFunctor<TResult> Map<TResult>(Func<T, TResult> fn);
Haskell, Purescript
-- Here, we explicitly write the Functor to map over as the second parameter, because Haskell is functional rather than object-oriented
map :: Functor f => (a -> b) -> f a -> f b

map takes a function and a Functor and returns the Functor after the function has been applied to its element(s). The type of the element(s) inside the Functor is allowed to change.

So, Functors are really, really simple. Their only special “skill” is that they allow you to apply a function to what’s inside them.

What Can (and Can’t) Be a Functor?

So far, we’ve only seen List‘s implementation of Functor, but what else could be a Functor?

Queue can, because it can allow a function to be applied to all its elements. Maybe can also be a Functor: if there is no value, then an empty Maybe is returned; otherwise, a Maybe with its value modified by the provided function is returned. Promise can implement map by allowing you to modify the value that the Promise will eventually resolve to (e.g. somePromise.then(x => x + 1)).

So what can’t be a Functor? Well, a Redux store probably can’t. While it certainly allows its state to be modified, being a Functor would mean that the type of the state could change, since any function we use with map with must be allowed to change the type of the elements inside the Functor. We usually don’t want the type of our Redux state to change over time, so a Redux store isn’t a valid Functor.

Let’s see some quick examples of Functors in use. Here’s what it looks like to map over a list in JavaScript, C#, and Haskell and Purescript:

[1, 2, 3].map(x => x.toString()) // ["1", "2", "3"]
new[] { 1, 2, 3 }.Select(x => x.ToString()).ToList() // new[] { "1", "2", "3" }
Haskell, Purescript
map show [1, 2, 3] -- ["1", "2", "3"]

Note that in the above example, the List started out as a List<int> but was converted to a List<string>. This is another important property of map that we’ll get to below.

And here’s what it looks like to map over JavaScript’s Promise type instead:

// Think of `then` as `map`
.then(x => x.toString()) // resolves to "2"

In both cases, we’re handing map a function and each Functor is doing the rest for us in its own specific way.

As we can see, the concept of a Functor is intentionally very general, and this idea of very general abstractions is what makes category theory so powerful.


To summarize: Functors allow us to treat “what to do” and “how to do it” as separate concerns. After a map implementation is written for a type, it can be used the same way with any function (as long as its parameters are the correct types, of course).

Now for a real-world example! Let’s pretend that we have a Maybe type of some sort in JavaScript, along with a corresponding fromMaybe function that takes a modifying function, a default value, and the Maybe to map over. If the Maybe contains a value, fromMaybe will return a modified version of that value; if, however, the Maybe does not contain a value, fromMaybe will return the default value that it was passed.

As an example, we might traditionally work with possibly nonexistent values like so:

const result = thingThatMightFail();
return result.value
    ? result.value + otherValue
    : 0;

The issue with this approach, however, is that we can forget to check that result is null or undefined (‘cannot read property of undefined,’ anyone?). If, however, we use some sort of Maybe object, we might be able to rewrite the above using fromMaybe as follows:

const result = thingThatReturnsAMaybe();
return fromMaybe(
    v => v + otherValue, // Function to apply if we have a value
    0, // Default value
    result // Maybe object

Now, if we forget to use fromMaybe on our result, we’ll catch it when we try to actually use this value. Granted, this isn’t as useful in JavaScript as it is in a statically-typed language like C# where we’d be able to catch such errors at compile-time, but using Maybe like this everywhere we’d use null or undefined still allows us to reason about our code and know what can return a value that might not exist (instead of just hoping that we remembered to check for null or undefined everywhere we use a potentially nonexistent value).

If we want to run multiple operations in sequence on a value that might not exist, we might think to do it like this:

const json = someAjaxRequest();

let result = defaultUser;
if (json) {
    const id = extractId(json);
    const user = getUserById(id);
    result = upgradeUser(user);

However, with Maybe, we can write it differently:

Note: R.pipe is a function from the Ramda.js library that “composes” functions: it takes several functions and chains them together to create a new function (for more details, see the docs).

Also, for clarity, psuedo Flow function type annotations are included.

const maybeJson: Maybe<JSON> = someAjaxRequest(); // someAjaxRequest: () => Maybe<JSON>

const result: User = R.pipe(
    (maybeJson: Maybe<JSON>) => map((extractId: (JSON) => Id), maybeJson),
    (maybeId:   Maybe<Id>)   => map((getUserById: (Id) => User), id),
    (maybeUser: Maybe<User>) => fromMaybe(
        (upgradeUser: (User) => User),
        (defaultUser: User),

And here’s the same example, but this time we’ll remove unnecessary Flow type annotations and take advantage of a technique called currying in order to see what the same code might look like in a real-world situation:

const maybeJson: Maybe<JSON> = someAjaxRequest();

const result: User = R.pipe(
    fromMaybe(upgradeUser, defaultUser)

So, let’s see what we gain from using Functors. As opposed to in the first, ‘traditional’ example, we didn’t have to manually handle the case where no value was returned. The Maybe Functor itself was able to decide how to do so, and all we needed to worry about was giving map the functions that we’d like to perform if a value does happen to exist. We can use any functions we want for each step in the pipeline, as long as they have the correct types (namely, the return type of each one must be the type of the next one’s parameter).

Functors are incredibly common in practice, and a good rule-of-thumb is to ask yourself whenever you begin to write a function that operates on a data structure if the function could be made general enough to operate on a Functor instead. For example, Haskell/Purescript functions like replace and zip could be defined to work with lists specifically, but they’re instead implemented to only require that their parameters are Functors; as such, they work on many different structures for free! They don’t need to know anything about how each of those Functors works on the inside because map handles the details for them.


Finally, Functors have two associated “laws” to ensure that the Functor will behave as one would expect. Don’t worry, you won’t go to jail if you get these laws wrong (although it is certainly an unpleasant surprise when a Functor is “unlawful”).

Law #1: Identity

Mapping the identity function over a Functor has no effect.

Fancy pseudo-Haskell way to say it:

map id = id

This one’s pretty self-explanatory: if your function doesn’t actually do anything to the element(s) inside the Functor, then it would certainly be surprising if you got back a different result than what you passed in.

JavaScript Example
map(x => x, [1, 2, 3]) // [1, 2, 3]
Law 2: Composition

Multiple maps in a row can be composed into one without any changes in the overall behavior.

Fancy pseudo-Haskell way to say it ((.) is the function composition operator):

map f . map g = map (f . g)
JavaScript Example

We could write our earlier JSON-manipulation example like so if we combine the two-in-a-row maps into a single map, with the new function to use being the composition of the two steps in our pipeline.

R.pipe(map(extractId), map(getUserById))(json) // map(R.pipe(extractId, getUserById), json)
Go forth and map!

And that’s it for Functors! They’re very simple structures that give us a lot of power. Just like Semigroups and Monoids, they’re used very commonly because they’re so simple to reason about. And, because they’re so general they allow us to write functions once and use them on all sorts of different data structures, guaranteed!

Categories: Companies

Does the Scrum Master Role Ever Go Away?

Scrum Masters coach, mentor, guide, and enable their teams to develop great products. For a new team in an organization that is also new to Scrum, this can be a challenging and time-consuming job.

At first, a Scrum Master may spend time educating the team about the Scrum framework itself. The Scrum Master may have to convince the team that, yes, something potentially shippable can be developed in less than three months. The Scrum Master may mentor the team on new practices, such as test-driven development or continuous integration. And the Scrum Master of a new team will spend time helping the new product owner learn how to do that job.

It can take a lot of work to do this. But, it does get easier.

The Scrum Master Role Gets Easier Over Time

Over time, the team improves. And the skills team members acquire from their first steps with agile help them learn, evaluate and adopt new practices.

It is perhaps comparable to learning a new language. At first we learn through memorization. Later, when we know enough to begin conversing in the new language, we can also learn through context: One word in a sentence is new to you, but the other words provide enough context that you can discern the meaning of the new word.

After seeing some early benefits of Scrum, teams don’t need as much convincing to try new agile practices. And, over time, the Scrum Master gradually removes organization impediments to agility. Perhaps an early battle was with the facilities group to move people so that the agile team could sit together. But once fought and won, that battle does not need to be fought again.

This argues strongly that the job of the Scrum Master does get easier over time. In general, it will take less time to be a good Scrum Master a year into a team’s agile journey than it did at the start.

Why the Job Gets Easier

The Scrum Master role gets easier in part because team members begin to take on parts of the job.

After a while, team members need less coaching. They learn how to facilitate some of their own meetings. Team members work more closely and directly with the product owner, so the Scrum Master is no longer needed to resolve communication roadblocks and resolve issues. There are fewer organizational impediments to agility. Those that remain can be particularly difficult to resolve, but there are fewer of them.

And so, the Scrum Master job starts to take less time as the team and organization become better at Scrum.

But Does The Role Ever Go Away Entirely?

But does the effort required to be a ScrumMaster ever go all the way to zero?

Not in my experience.

Even the best Scrum team continues to benefit from the coaching, guiding and mentoring provided by a good Scrum Master. With that being said, some high-performing teams might find they do not need a ScrumMaster full time anymore. They might, for example, opt to have a technical team member also function as the Scrum Master.

But my experience is that even the best teams benefit from having a Scrum Master.

What’s Your Experience?

What have you found to be true about the Scrum Master role over time? Do you agree it takes less time as the Scrum Master and team become more experienced? Have you worked on a team that had so fully absorbed the role of Scrum Master themselves that they did not benefit from a designated, even part-time Scrum Master?

Categories: Blogs

The Product Owner Podcast

Scrum Expert - Mon, 04/24/2017 - 17:14
The goal of the Product Owner Podcast is to share stories from real product owners working in Agile teams. It proposes tips, tricks and lessons learned from experience. Listening to these interviews,...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

The Objective of Time-Boxing

NetObjectives - Sun, 04/23/2017 - 14:22
This blog continues my series on Going Beyond Practices to Achieve Objectives. A webinar on Blending Kanban and Scrum is also available.   Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. In Agile, these time boxes are known as “iterations” (XP and...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Values, Practices and Principles Are Not Enough

NetObjectives - Sun, 04/23/2017 - 14:12
This blog continues my series on Going Beyond Practices to Achieve Objectives. A webinar on Blending Kanban and Scrum is also available. Agile has been around for over 2 decades now. Most every method talks about values, principles and practices. The Agile Manifesto, for example, is comprised of 4 values and 12 principles. XP, Scrum, Kanban, SAFe, LeSS and Nexus have added a considerable number...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Question Isn’t ”Scrum Vs Kanban?” or Even “Scrum and Kanban?” But Rather “What Works?”

NetObjectives - Fri, 04/21/2017 - 19:11
This blog continues my series on Going Beyond Practices to Achieve Objectives. A webinar on Blending Kanban and Scrum is also available. Executive Summary We should not be debating whether Scrum or Kanban is better.  Both have practices and principles to offer.  Each has a different mindset towards learning, however.  But instead of just blending them, we should look to a mindset that embraces...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Dialogue on Prerequisites for Collaboration

IDEO-University 'From Ideas to Action' Lesson 1.

Join the dialogue on G+ Agile+ group.

Dialogue on Collaboration on Facebook (PDF)

Collaboration starts with who we are and our story - not the technology or the data
"The Future of Work Is Social Collaboration from Inside Out, where people connect around the why of work from who they really are as individuals in community.
They collaborate in generative conversations and co-create what’s next, i.e. their unique Contribution of value to society – what we might call Social Good.
They collaborate by taking the time to appreciate and align each other’s unique, hard wired, natural strengths, creating new levels of authentic and trusting relationships to take the Social Journey."Jeremy Scrivens Director at The Emotional Economy at Work

What does dialogue mean... what does it contribute to collaboration? Here's what the inventor of the internet Al Gore had to say about this:

Audie Cornish speaks with former Vice President Al Gore about the new edition of his book, The Assault On Reason.

Well, others have noted a free press is the immune system 
of representative democracy. And as I wrote 10 years ago, American democracy is in grave danger from the changes in the environment in which ideas either live and spread or wither and die. I think that the trends that I wrote about 10 years ago have continued and worsened, and the hoped-for remedies that can come from online discourse have been slow to mature. I remain optimistic that ultimately free speech and a free press where individuals have access to the dialogue will have a self-correcting quality. -- Al Gore
Excerpt from NPR interview with Al Gore by Audie Cornish March 14, 2017. Heard on All Things Considered.

See Also:

Mob Programming by Woody Zuill

If Your Team Agrees on Everything, Working Together Is Pointless by Liane Davey - HBR

[View the story "Dialogue on Prerequisites for Collaboration" on Storify]
Categories: Blogs

Scrum Knowledge Sharing

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