DaedTech

Stories about Software

By

Disrupting Agile and the Process Industry

Tonight I give you post number 5 of Developer Hegemony week.  If you’d like a free paperback copy of the book, remember to sign up for the Thunderclap.IT campaign so that we can get to the sharing threshold — we’re now three quarters of the way there, but I still need your help.  It only takes a second.  About 25 more share signups, and I’ll do the raffle!

Whenever I hear the word disruption in the context of industry, my mind does something weird.  It immediately transforms it into someone saying, “hashtag disruption” and then doing jazz hands.  So you can only imagine my mental model (and, honestly, mild hypocrisy) for a title about disrupting agile.  But please bear with me.

I once wrote a post about the nuts and bolts of buzzword fatigue.  And, clearly disruption and agile both quality as buzzwords.  Disruption as a concept originated in Silicon valley’s lexicon.  From there, it wormed its way out into general, uncool industry like a rogue wave of fanny packs.  By now, people talking expansively about disruption have probably never disrupted anything more than an Applebee’s by coming in for dinner 3 minutes before closing.  Jazz hands.

Read More

By

How to Turn Requirements into User Stories

Editorial Note: I originally wrote this post for the SmartBear blog.  

Let me ask you something.  When you read the title of this post, did you envision it laying out some onerous process for converting gigantic Word documents full of requirements into “user stories” in JIRA?  If so, I’ll set your mind at ease right now.  It’s not that.

Indeed, I am not talking about the mechanics of taking the square peg of “traditional, waterfall-style requirements document” and jamming it into the round hole of some ALM suite’s agile workflow.  Instead, I’m talking about the more labor intensive practice of taking a document like that and using it to generate actual, agile-style user stories.  There is absolutely a difference, and not even a subtle one.  Putting, “1.4.2.3 System shall cause cursor to blink twice after user types A key” into Jira and calling it a “user story” does not make it one.

Anatomy of a User Story

It bears asking, then, “since you say that’s not a user story, what is a user story?”  The most common way one sees it defined is via a mad lib.  “As a ______ I want to ________ so that _________.”  The definer then creates an example, such as, “As a personal banking customer, I want to know my account balance so that I don’t overdraft with my next withdrawal.”

To get a bit more philosophical, the user story has three components: persona, action, and value proposition.  The person is the “who” and it typically involves a description of a user or “actor” in the broader context of the system.  Some groups will actually define personas, give them names and characteristics, and then use the names, instead.  “Dave is a 35 year old stock broker with a checking and savings account, who…”  The user story is then, “As Dave, I want to know my account balance so that I don’t overdraft at my next withdrawal.”

The action is the way in which the user interacts with the system.  It is not framed in terms of minutiae and sequential, detailed actions.  Rather, it is framed in terms of goals that can be accomplished in a sitting.  There is a certain amount of art and subjectivity to what is an appropriate goal, but you’ll get the hang of it with practice.

And finally, there is the value proposition of the user story.  In my experience, this is the part that is both most frequently omitted and most important.  (It is also the part that is hardest to grok for people used to waterfall/contract-style requirements).  The value proposition explains why the person in question wants to do the thing in question.  And including it is particularly urgent for two reasons.

  1. If the value proposition is weak or nonexistent, you may deprioritize or eliminate this story altogether.
  2. If you hit a roadblock during a implementation of the action, you can immediately start thinking of other, more technically feasible ways to achieve the value proposition.

Read More

By

The Case for the NDepend Dashboard Feature

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original post here, at the site.  While you’re there, check out NDepend — it’s my go-to tool for the codebase assessments that I do as part of my consulting practice.

If you hang around agile circles long enough, you’re quite likely to hear the terms “big, visible chart” and “information radiator.”  I think both of these loosely originate from the general management concept that, to demonstrably improve something, you must first measure and track it.  A “big, visible chart” is information that an individual or team displays in, well, big and visible fashion.  An information radiator is more or less the same concept (I’m sure it’s possible for someone who is an 8th degree agile black belt to sharp-shoot this, but I think you’d be hard pressed to argue that this isn’t the gist).

Big, Visible Information Radiators

As perhaps the most ubiquitous example imaginable, consider the factory sign that proudly displays, “____ days since the last accident,” where, hopefully, the blank contains a large number.  A sign like this is far from a feel-good vanity metric; it actually alters behavior.  Imagine a factory where lots of accidents happen.  Line managers can call meetings and harp on the importance of safety, but probably to limited effect.  After all, the prospect of a floor incident is abstract, particularly for someone to whom it hasn’t ever happened.

But if you start putting a number on it, the concept becomes less abstract.  “Currently we have an incident every day, but we want to try to make it happen only once per month, and we’re going to keep track.”  Now, each incident means that the entire factory fails each and every day, and it does so visibly.  Incidents go from “someone else’s problem that you hear about anecdotally from time to time” to “the thing that’s making us fail visibly.”  And then you’ll find that doing nothing but making the number very visible will serve actually to alter behavior — people will be more careful so as not to be responsible for tanking the team’s metrics.

0 Days Since Last Accident

In the world of agile, the earliest and most common bit of information to see was the team’s card wall: which features were in progress, which were being tested, which were complete, and who was working on what.  This served double duty of creating public visibility/accountability and providing an answer to the project manager’s “whatcha doin?” without interruptions or mind-numbing status meetings.  But times and technologies progressed, resulting in other information being visible to the team at all times.

These days, it’s common to see a big television or monitor located near a team and displaying the status of the team’s code on the build machine.  Jenkins is a tool very commonly used to do this, and it will show you projects with red for failing and green for all good.  If you want to get creative, you can use home automation tech to have red or green lamps turn on and off.  For the team, this is a way of exposing broken builds as a deficiency and incenting team members to keep it in a consistently passing state.

Read More

By

Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More

By

Musing on Agile’s Built In Caveat Emptor

First things first.  I’d like to thank the folks who submitted “Ask Erik” questions (I’m thinking I might need to come up with a title that’s not as lame — iterate all the things!)  I’m pleased with the results so far, and early returns on my hypothesis look good.  Interestingly, I received more than one question related to my take on capital-A Agile as a movement.  I plan on answering these questions directly, but I have opined on this subject a bit in the past:

Reading the questions I received and letting them kick around in my head a bit as I was jogging earlier today, I started to think obliquely about the topic and how it’s approached and regarded in the industry.  What’s going to follow is fairly raw riffing on this topic, and please forgive me if I seem a little loopy.  It’s about 1:30 AM, I just got back from a concert, and, given that I’ll be off the grid for a couple of weeks starting September 5th, I didn’t want to let a Friday lapse sans post.

1 Agilius

So, story time.  What would you think if I laid the following narrative on you?

17 well known, well respected elders from different villages came to realize that the prevailing methods for tending and cultivating crops were not sufficient to feed the growing populations of their villages.  These elders had some ideas, both mystical and practical, for how to solve that problem.  They’d gained much knowledge on their own and needed to spread the word.

They decided to convene a summit, but the odds were stacked against them.  Each village had its own ways of doing things and cultural preferences, and the elders were each accustomed to those around deferring to them.  Initially, they could not even agree on a location for the summit!  How were they ever going to agree on providing food for the known world?

Against all odds, however, they made progress.  They retreated into the mountains and toiled for 2 days and 2 nights, expecting little to come out of the gathering, but when the sun rose on the 3rd morning, not only had they made strides — they’d all agreed, as if by Divine Providence.  What emerged from this gathering were stone tablets containing the 4 Core Values and the 12 Principles of food cultivation.

Over the years, the Word spread far and wide.  What started as 17 quickly became dozens, and eventually hundreds, thousands, and hundreds of thousands.  Great centers of learning and cultural exchange emerged, devotees made annual pilgrimages to important sites, and the new methods for food cultivation spread far and wide.  And, lo, it was good.  There was much rejoicing.

In case this doesn’t ring a bell with you off the cuff, it’s basically the history of the Agile Manifesto.  And, before you bristle, read that history that I linked.  It says epistle in there to describe one of the communications between signatories, for goodness sake — if that doesn’t invite religious comparisons, I don’t know what does.  Try googling that word and finding a reference in the top 10 that doesn’t prominently mention the Bible.

Guru

This post isn’t actually about comparing capital-A Agile to religion.  This is well trod ground, and a well placed google search will let you tread it to your heart’s content.  But if you temporarily accept the premise as axiomatic, there’s an interesting plank to the agile canon that’s generally missing from religion, at least in my experience with it.  What I’m talking about is self-reference in a way that isn’t begging the question.   Read More