Thursday, December 1, 2016

TDD: Start With A Failing Test

The question was asked:
In Test-Driven Development, what does it mean to start with a failing test? 

This is not a complicated question, so let me give the short answer:

  • Write a test that can't possibly succeed because you have not yet implemented the feature; but which would succeed if the part of the feature it's testing were written.
  • You want it to be a good test: clear, obvious, simple, discrete.
  • You want it to fail, so you see what the error message will look like -- whether it will provide enough information when someday it fails unexpectedly.
  • Then you write enough feature that the test passes works (but not the whole feature).

The idea is like a video game. You write a test, which is your first challenge. Then you beat that challenge and save your game (to version control) so you can come back. You layer on the challenges until you've beat the game (written the feature).

There is more to the TDD cycle, but this is enough to answer the one question.

BTW, the same "accumulation of phases that work" is the preferred approach to writing stories, which add to features... the whole world of test-driven is about thin, tested, integrated slices continually being built and integrated.

Monday, November 14, 2016

For those of you keeping track...

Sometimes I receive bizarre statistics in email. So:

Rank of world for is 14,111,324

It sounds like my blog has ranked this world the 14-millionth favorite, but I think it means the opposite.

I have plenty of margin here so that I can improve without running out of space. 


Wednesday, November 9, 2016

Support Each Other

if we all could put curiosity and interest in others over the warm self-righteous glow of disdaining and judging, then we could do all things.
As long as we go about magnifying the differences and heaping shame on people who see things differently, we will continue this path.
It’s a choice.
Maybe your vote isn't the most important choice you could make this month.

Wednesday, November 2, 2016

But In The Real World

An old story I’d almost forgotten resurfaced for me today.

A guy who spent his entire career in the same company, in the same state, mostly in the same building, mostly with the same bosses who were of the same management philosophy once corrected me when I was talking by saying “yes, but in the real world…”

It was the first time it became clear to me that “in the real world” could not only suggest that my views are naive, but that the speaker is from a very specific (and perhaps naive) context.

It didn't have to be. Sometimes I am naive, but not every time.

"In the real world" only meant that my experiences did not coincide with his, and therefore my sense of cause-and-effect seemed far different from the "laws of work" where he spent his time.

I must have looked like an alien to him, as he did to me.

The things I said about trust, team work, values, and practices sounded entirely unworkable because they didn't follow the rules of his control-based organization where everyone knows that people only do their work because they have no choice. All this "hippy crap" didn't make any sense.

Except that it always has made sense and worked in my experience.

Travel Broadens One

I've always been pretty mobile. I've been with a lot of really great consultancies even before the one that makes it possible for me to travel the world these days. All of my clients and all of my companies have always had things to teach me.

Some of the things I learned were pretty context-specific, and didn't carry from one real-world experience to the next. Some were more universal, but were moored to a point in time or a way of working that has since become quaint.

Some things I learned, the most important things, have weathered a lot of storms and changes in fashion. As far as I know, they may be universal. They're certainly well-represented in ancient wisdom and sacred texts. But I can't assume the universal reality of them either.

Being in a lot of organizations and helping to solve many technical and cultural issues has granted me a lot of relatively brief but intense exposure to a lot of companies and contexts.

Unlike my friend above, I didn't stay in any one of those contexts for decades. I don't know what it's like to have only a very deep exposure to a single culture. I don't know what it's like to have all your history, relationships, and experience tied so deeply to your neighbors and lived so deeply in your daily work. Our worlds are very different, indeed.

At one point, when we were in mid-transformation he enlightened me to his context, explaining that he avoided upset (no matter what) because "these people are your neighbors and you have to live with them."

I forgot that not everyone is mobile and not every community is temporary. I was (in this case) naive to his context.

How Tiny Our Perception

I've written about getting through to each other before, and how experience and mindset controls how we hear others' words and how we choose our own. Sadly, this is one of those moments where we would need to look each other in the eye if we were to come to any kind of certainty that we're communicating this important idea, but I'll try:

"There are more things in heaven and earth..."

All our “real worlds” are tiny one-person slices, and yet all these contradictory experiences are "real".

 If you live in the city, the country life seems the naive and unreal one. If you live in the country, you see city people as strange and out of touch.

But we're tiny and self-involved beings. We tend to measure tallness and shortness of trees by our own height. A "long time" is some proportion of our own lifespan; just ask a 5-year-old how long it is between birthdays or Christmases.

If my life is one person's slice out of the whole of existence and the whole of history, it is a very small measure of reality. It's impossibly thin.

So when one of us calls out "in the real world" we hear them as invalidating our experiences (oh, self-involved self!) but really it's just a curiosity space.

And then we find out that they have things to teach us, too.

Not So Easy

"In the real world" is a pretty arrogant thing to say, and frankly triggers me a bit.

I'd like to say I was past this, but I still have to process the upset and forgive the arrogance of the speaker and this listener.

After I process that all I can reorient, enter into curiosity, and start to communicate again.  But I have to take the time still.


Friday, September 30, 2016

Political Correctness and Truth

Yeah, I know that title is going to be a bit inflammatory, and everyone knows what they expect when they see it up there. But that's okay.

My topic is really about such things.

I want you to consider:

  • Saying hurtful things
  • Not being politically correct
  • Telling the truth
What I want you to consider is that these are three entirely orthogonal concepts. One can make statements which are any one of the above, without being the others.  

One may easily say offensive things which are entirely politically correct. It's a common event on the internet to see people shaming others in the name of Political Correctness (which should be all about being fair and kind to others, but outrage is virtue these days). Some of the shaming statements could be true, and some could not be true. 

One can certainly state truths in kind ways, full of compassion and empathy. Even ugly truths can be delivered in considerate ways. 

One can say things that are true and not PC, but they don't have to be said in a way that is deliberately hurtful. 

I'm only bringing this up because I keep seeing a growth in people saying hurtful things and claiming that they're true because they're not PC. 

And I see growth in people saying hurtful things because they are PC. And because they're PC, claiming the power of truth.

Offensiveness is not evidence of correctness.

I'm very concerned to see people look for others' hurt feelings as confirmation of the rightness of their position. Being cruel is a far cry from being right.

And of course, "telling the truth" is a ticklish thing in the best of times. Truth is more present in mathematical formulae than in human interaction.  What I think is true is subject to so many biases and conflicting theories and personal imperfections.  

And yet, I hear things being said about groups or demographics or whole populations that are hurtful, are not politically correct, and are far from certainty or truth.

I suppose I would like everything I say or hear to be authentically what the speaker believes, while being as kind and empathetic as possible, and not worry about how it plays in PC.

But if one doesn't have certainty in their virtues of kindness and curiosity as "true north" values, then I see value in at least observing and considering Political Correctness in public discourse.

This post is 
  • intended as non-hurtful (let me know if it's so)
  • pretty safe, in a PC kind of way
  • authentic,  and "true" as far as I can tell


    Heretics of Agile at DSM Agile 2016

    At the end of dsmAgile, we had a session full of "lean coffee" style meetings in a big noisy room with an open bar (so it wasn't so much coffee people were sipping as much as wine or highballs).

    I was one of the selected/volunteered Lean Coffee hosts, so I was given a table and asked to choose a theme. I chose the theme of "Unconventional Agility" (a throwback to the talk Brandon Carlson and I gave at Agile2016).

    I'm so sad that I didn't keep a full roster of guests at my table. Here is the roster-in-progress (incomplete until we say otherwise).

    • Melissa Perri
    • Aaron Hoffman
    • Keith Dahlby

    I apologize to all for this, but let's just say that it was a little conference-speaker-heavy, and there was tremendous intelligence (emotional and intellectual), kindness, and passion at this table.  I believe some of my cohorts tried to record the discussions and if they provide me with the recordings I'll try to get a transcript posted here.

    The topics we gathered, dot-voted, and discussed were:

    • No User Stories
    • Drop The PO
    • Putting a Brain on Your Process
    These were chosen partly for their partly for their controversy, partly for the way they resonated with our personal experiences, and partly out of pure whimsy. 

    My notes are very sketchy (literally written on one side of a 3x5 card) but presented here in hopes that we can start some interesting conversations about them.

    No User Stories

    • Prevalence of BS stories
    • Features rather than stories/tasks
    • Digestible US == Task? "As a user I want this button."
    • Developer stories suck.
    • Is an abused tool a bad too? 
    • Would "jobs to be done" be better? 
    • Process over people sucks
    • Process is du jour.

    Drop the PO

    • Customer pipeline better
    • Needs to be collaborative/empathic
    • Experience too crucial
    • Where is the experimentation?
    • PO needed to generate gestalt stories from multiple inputs?
    • How to manage the vision? Charter? 
    • PO-WX need design (I have no idea what I meant by this one-liner)

    Putting a Brain on Your Process

    • Site visits
    • "Nah, Cubes R Us"
    • Call Center people
    • Persona -- less good
    • Dangerous to solve Other People's Problems (OPP)
    • Shared Ownership
    I've now come to realize that I'm a rather poor note-taker when I'm deep in discussion, so anything we can do to flesh these out is appreciated.  I'm perfectly okay with the task of splitting these heretical ideas into individual blogs and editing them according to the memories (electronic and otherwise) of the participants so that I can do these ideas justice.

    Wednesday, September 28, 2016

    14 Challenges For Agile Adoption

    I stumbled across a document describing the government's approach to agile software development.
    I didn't read it really closely, because I was just looking for some of these bullet lists at the time. 
    However, I think that they may have nailed it with the 14 Challenges.
    GAO identified 14 challenges with adapting and applying Agile in the federal environment:
    • Teams had difficulty collaborating closely.
    • Procurement practices may not support Agile projects.
    • Teams had difficulty transitioning to self-directed work.
    • Customers did not trust iterative solutions.
    • Staff had difficulty committing to more timely and frequent input.
    • Teams had difficulty managing iterative requirements.
    • Agencies had trouble committing staff.
    • Compliance reviews were difficult to execute within an iteration time frame.
    • Timely adoption of new tools was difficult.
    • Federal reporting practices do not align with Agile.
    • Technical environments were difficult to establish and maintain.
    • Traditional artifact reviews do not align with Agile.
    • Agile guidance was not clear.
    • Traditional status tracking does not align with Agile.
    The problem seems to be largely one of unlearning the way that software was done in the days before agile. People got used to working alone, being told what to do, being held individually accountable for work items, working with customers in a continuous way, not having big design up front.

    Way down in the list were challenges with technical environments and new tools.  Two items out of 14.

    The rest is cultural.

    What lesson did you take from this?