Skip to content

Feed aggregator

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

Agile Movement's parallels to Lincoln's Gettysburg Address

What parallels are there between Lincoln's Gettysburg Address and the state of the Agile movement's union?

Lincoln was a primary figure at the dedication of Soldiers' National Cemetery, in Gettysburg. He did not wish to upstage the keynote speaker, Edward Everett, and so summarized in 2 minutes the principle of human equality as defined by the Declaration of Independence and the Civil War.  Do you remember, the keynote speech?  Few people do.


Lincoln's Gettysburg Address:
Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth. - - U.S. President Abraham Lincoln
I heard an NPR story about a person that give their grandkids twenty dollars to recite the Address.  It sounded like a wonderful way to engage kids in history and the founding reasons of the existence of this nation.  I'm assuming that it would take the children some time to memorize the short speech and in so doing they would have questions, about what the words meant.  How many of your colleagues know what unit of quantity a score represents?  Do you know what happened four-score and seven years before 1863?

The foundational document of this new nation is the Declaration of Independence - signed in the summer of 1776 by a group of wealth white men.  They are now described as our founding fathers, yet some were quite young at the time (Hamilton, 21; Jefferson, 33; Washington, 44).  These free thinking people (and some were women - they just didn't sign the document) were called radicals by their government and traders by their neighbors.


Does any of this sound like a fractal of the Agile Manifesto and the movement that was started back in the 1990s with lightweight frameworks for organizing software product creation.  The desire to increase the good aspects and there by overcome the poor habits (appreciative inquiry or extreme programming - is there a difference?).

Is there a revisionist movement some 15-20 years beyond the 2001 manifesto creation?  Yes, there appears to be a constant yearning for the next wave, the next wagon to hitch your cart onto.

Are there amendments that need to be added to the manifesto much like the Bill of Rights?  Or is that a fringe movement on the periphery?



Modern agile  defining four guiding principles:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

Alistair Cockburn observer his communication style in beginner and advanced classes, he said: "[I] found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things, and drew them in a diamond:"



Could the newest technique Mob Programming be anything more than an incremental addition to eXtreme Programming (XP)?  Some 30 years in the making.










See Also:

Reshaping our View of Agile Transformation - Jason Little

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 https://saat-network.ch/pas!
Categories: Blogs

An Introduction to Functors

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

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).

Constraints

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
Recap

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.

C#
int
Haskell, Purescript
Int
Generic Types

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

C#
Foo<T>
Haskell, Purescript
Foo t
Constraints

We know some things about various parts of these types.

C#
// Constraint on the "traditional" type parameter
Foo<T> where T : IBar
// Constraint on the container type itself
// Approximately:
IFoo<T>
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.

C#
// Doesn't exist, but might look something like:
T1<T2>
Haskell, Purescript
f t
Functors

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:

Structure

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 Array.prototype.map 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!

C#
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:

JavaScript
[1, 2, 3].map(x => x.toString()) // ["1", "2", "3"]
C#
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:

JavaScript
Promise.resolve(1)
// 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.

Example

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),
        maybeUser
    )
)(maybeJson);

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(
    map(extractId),
    map(getUserById),
    fromMaybe(upgradeUser, defaultUser)
)(maybeJson);

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.

Laws

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

Info Radiation vs Info Refrigeration - a metaphor

Is a metaphor a form of lightweight model?

"All models are wrong, some models are useful."
-- George Box
The metaphor of information radiation is quite well know to many in the software industry.  Did you ask why?  Maybe because much of our work is very hidden from view, until we run the program and the computer interprets the code to produce some desired outcome.  Even that outcome may be obscured from view, and we must produce reports upon the data that the program produced.  So in a world where smoke and mirrors are common, one antidote to the common problem of not knowing where one is along the path toward product completion, a visualization is a powerful tool.  

Generally speaking the information radiator has similar properties to the old fashion building heat radiator that used a steam media source to heat heavy iron and radiate the heat from the iron into the room.  It feels great to be standing next to a radiator when you've just come in from the cold.

What is the refrigeration process - what's required to cool some air?  Currently we use the 200 year old Carnot cycle to produce the cooling effect that your summers are known for.  I doubt that my home of Dallas Texas would be the Mecca of IT if not for Mr. Nicolas Carnot and his research into what would become air-conditions environments.  A comfortable 70 degrees indoors while the Texas sun is 95 in the shade.

Pressure-Volume diagram of Carnot cycle
I will leave the internal working of the AC unit to your study (I did it back in college - fascinating stuff).

When we put information is some systems we encode or compress it in such a way that the storage is efficient.  Think of a data base, significant work is done upon the data to store it.

When we pull it out of those systems we also must now do work to make the data into information, and then do more work to make the information understandable by the people that have little knowledge of where the data came from, the purpose of storing the data and the context from which that data/info may have resulted.  Someone will interpret that context, information and purpose and try to convey all this in a summary of the meaning behind larger data sets that the important people reviewing the information have time for.  This expansion of the information and subsequent summarization or generalization takes energy from the system as a whole.

pondering the connections - AC to info refrigeration metaphor....  what do you see in this metaphor?

is there a useful model to play with?


Categories: Blogs

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 phases....in 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).



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
  10. Agile Development is about having FUN!
  11. 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

The Objective of Time-Boxing

NetObjectives - Sun, 04/23/2017 - 14:22
This blog continues my series on Going Beyond Practices to Achieve Objectives   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 generic Agile) or “sprints” (Scrum). The deliverables of each...

[[ 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
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 of principles and practices as well. However, there has been little discussion of the laws of software development and insufficient...

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

Design Your Competition's Support Department

You are presented with a common business problem.  One technique that has always helped me to define the problem space is to invert the problem, take it to an extreme to explore the continuum of your domain.  Let's imagine that we want to redesign our software support department at MegaSoft Corporation.  Applying our inversion principle we will leave our MegaSoft support as is, and instead we will design the competitors support group. It's going to stink, people are going to hate to even call them, their people will be arrogant techies with no human compassion - they will actually hire with those skills required.  Let's pause and give this company a name...  TechHard sounds great.

Who's time is most valuable?  At TechHard the support engineers time is very valuable, so we will have process that time how long a support tech. is on the call with a customer so that our process gurus can optimize for the use of this most valuable resource.  A typical call from a director or VP in our internal support operation should be logged by an administrative receptionist (maybe even automated system) and then the support techs time can be queued up with return call tickets.  We will return the VPs call when it is convenient for our tech.  The tech can validate that the VP is authorized to access the system, and will confirm that they are still experiencing the problem by walking through a standard checklist.  Being efficiently minded the tech may skip over some simple question like power plug, on/off, reset/reboot, logout/in again if they feel the user is competent.


Answering the basic question of who's time is most valuable via the design of the competition's process is enlightening.  Which is it?  The support person's time - or the customer's time.

How are support systems designed?  Has anyone ever heard of a company that used Design Thinking or High-Tech Anthropology to create a customer centered support group?

Is this Conway's Law at work - are we truly designing the support function of our products/services - or are we just reacting?

Give me an example of great design for support:  Nest Thermostat and Fire Alarm Installation
Have you installed a Nest product?  Their installation and configuration process is well designed.  I don't know about their support department - but my expectations are set very high, if I have a problem.


History will repeat
In the 1980s universities started teaching about design for manufacturing (robots would make the parts).

Are you designing your business departments for it's function?

Speaking of support tools - your going to want a great issue tracking system.  Why not look to a market leader that has all the features your people can put on a check list?  Let's buy Jira - or should we look at the competition's product?



See Also:

Cable Internet provider Frontier's support group struggles with the corporate infrastructure that can not resolve customer problems.







Categories: Blogs

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

NetObjectives - Fri, 04/21/2017 - 19:11
If you find this topic interesting, check out our webinar Blending Kanban and Scrum Or What to do When Neither Kanban or Scrum Is Optimal 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

Waggle Dance -or- Standup Meeting

Bees do a dance that bee keeper refer to as the Waggle dance...

It is with great pleasure that you can watch and using the power of science have this dance translated into English.

Bee Dance (Waggle Dance) by Bienentanz GmbH
What does this have to do with Scrum?  The power of a metaphor was well known to the creators of Extreme Programming (XP) - so much so, that it is one of only 12 "rules" that those really smart people decided to enshrine into their process.  It is also the most likely rule to not be mentioned in any survey of software development practices.  Unless you happen to be chatting with Eric Evens, and he may agree that he's captured the underlying principle in Domain-Driven Design, the Ubiquitous Language pattern.


Have you ever observed a great scrum team using a classic tool of many innovative company environments - the physical visual management board (Scrum Task Board). The generic behavior for a small group of people (say around 7 plus/minus 2) is for the group to discover that a form of dance where the speaker moves to the board and manipulates objects on the board as they speak gives everyone else the context of what story they are working upon and what task they are telling us they have completed. Then they exit stage left - so to speak. And the next dancer approaches from stage right, to repeat the dance segment. Generally speaking one circuit of this group is a complete dance for the day. The team is then in sync with all there team mates, and may have negotiated last minute changes to their daily plan, as the dance proceeded. In my observation of this dance great teams complete this ritual in about 15 minutes. They appear to need to perform this dance early in the morning to have productive days. And groups that practice this dance ritual well, out perform groups that are much larger and groups that don't dance.


So going all honey bee meta for a moment...  Let's use our meta-cognition ability to think about the patterns.  We love to pattern recognize - our brain is well designed for that (one of the primary reasons a physical visualization of work is so much more productive as a accelerator of happiness than virtualization of the same work items).

When do we use great metaphors - in design great NEW experiences for people that are reluctant to change.  And to communicate the desired behaviors, the exciting new benefits to adopting something new.  I'm thinking of the 1984 introduction of the Graphical User Interface by the Apple pirate team that produced the GUI, the Mouse, the Pointer, the DropDown Menu, etc.

Can you see a pattern in this... a pattern that relates to people changing systems, behaviors, disrupting the status quo?  It is resonating in my neurons, I'm having a heck of a time translating these neuron firing waves of intuitions, into the motor cortex to make my stupid fingers pound out the purposefully retarding movements on a QWERTY keyboard to communicate with you over Space-Time.  If only we could dance!

See Also:

The Waggle Dance of the Honeybee by Georgia Tech College of Computing
How can honeybees communicate the locations of new food sources? Austrian biologist, Karl Von Frisch, devised an experiment to find out! By pairing the direction of the sun with the flow of gravity, honeybees are able to explain the distant locations of food by dancing. "The Waggle Dance of the Honeybee" details the design of Von Frisch's famous experiment and explains the precise grammar of the honeybees dance language with high quality visualizations.
This video is a design documentary, developed by scientists at Georgia Tech's College of Computing in order to better understand and share with others, the complex behaviors that can arise in social insects. Their goal at the Multi-Agent Robotics and Systems (MARS) Laboratory is to harness new computer vision techniques to accelerate biologists' research in animal behavior. This behavioral research is then used, in turn, to design better systems of autonomous robots.


I was just reminded of @davidakoontz's wonderful metaphor for the daily #Scrum: waggle dance :) pic.twitter.com/h3c1B49mkC

— Tobias Mayer (@tobiasmayer) April 7, 2017


Categories: Blogs

Agile Portugal, Lisbon, Portugal, 2-3 June 2017

Scrum Expert - Thu, 04/20/2017 - 10:30
Agile Portugal is a two-day international conference that gathers practitioners from the Agile software development and Scrum project management community with invited international leading experts...

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

Agile Coach Camp Denmark, Dragor, Denmark, May 18-20 2017

Scrum Expert - Thu, 04/20/2017 - 09:00
Agile Coach Camp Denmark is a three-day event that serves as an unconference for Agile coaches of Denmark and other countries. The Agile Coach Camp Denmark is a free, not-for-profit, practitioner-run...

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

Scrum Knowledge Sharing

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