Agile Archives - DaedTech

Sep
12

Pair Programming Benefits: The Business Rationale

Category: The Life of a Programmer Tags: Agile, Software Process, Stackify | 13 Comments

Editorial note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there, have a look at their Retrace product that consolidates all of your production monitoring needs into one tool.

During the course of my work as a consultant, I wind up working with many companies adopting agile practices, most commonly following Scrum. Some of these practices they embrace easily, such as continuous integration. Others cause some consternation. But perhaps no practice furrows more brows in management than pair programming. Whatever pair programming benefits they can imagine, they always harbor a predictable objection.

Why would I pay two people to do one job?

Of course, they may not state it quite this bluntly (though many do). They may talk more generally in terms of waste and inefficiency. Or perhaps they offer tepid objections related to logistical concerns. Doesn’t each requirement need one and only one owner? But in almost all cases, it amounts to the same essential source of discomfort.

I believe this has its roots in early management theories, such as scientific management. These gave rise to the notion of workplaces as complex systems, wherein managers deployed workers as resources intended to perform tasks repetitively and efficiently. Classic management theory wants individual workers at full utilization. Give them a task, have them specialize in it, and let them realize efficiency through that specialty.

Knowledge Work as a Wrinkle

Historically, this made sense. And it made particular sense for manufacturing operations with global focus. These organizations took advantage of hyper-specialty to realize economies of scale, which they parlayed into a competitive advantage.

But fast forward to 2017 and think of workers writing software instead of assembling cars. Software developers do something called knowledge work, which has a much different efficiency profile than manual labor. While you wouldn’t reasonably pay two people to pair up operating one shovel to dig a ditch, you might pay them to pair up and solve a mental puzzle.

So while the atavistic aversion to pairing makes sense given our history, we should move past that in modern software development.

To convince reticent managers to at least hear me out, I ask them to engage in a thought exercise. Do they hire software developers based on how many words per minute they can type? What about how many lines of code per hour they can crank out? Neither of these things?

These questions have obvious answers. After I hear those answers, I ask them to concede that software development involves more thinking than typing. Once they concede that point, the entrenched idea of attacking a problem with two people as wasteful becomes a little less entrenched. And that’s a start.

Apr
27

By Erik Dietrich

Disrupting Agile and the Process Industry

Category: The Life of a Programmer Tags: Agile, Entrepreneurship | 2 Comments

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.

Jan
15

By Erik Dietrich

How to Turn Requirements into User Stories

Category: The Life of a Programmer Tags: Agile, User Story | 6 Comments

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.

If the value proposition is weak or nonexistent, you may deprioritize or eliminate this story altogether.
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.

Jul
8

By Erik Dietrich

The Case for the NDepend Dashboard Feature

Category: .NET Tags: Agile, NDepend |

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.

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.

Nov
24

By Erik Dietrich

Agile for Introverts: Re-Imagined Programmer Collaboration

Category: The Life of a Programmer Tags: Agile, Software Management, Software Process | 4 Comments

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

DaedTech