Starting the New Year with Less

I would like to make a more concerted effort to post a bit more. Not necessarily huge, rambling tomes of articles, but short and meaningful drips of things I learn, experience, and encounter along my professional path.

So, first things first! I am starting the new year with an old technology purge. This is actually taking longer than I’d thought because of all the unidentifiable cords, power adapters, and other detritus that’s piled up in my office over the years. The three things I did manage to accomplish yesterday were to:

  1. Admit my old Windows Home Server adds no value and put it on the “take to e-cycling” shelf in the garage. I pulled all photos from it, out them up in my personal OneDrive, and pulled the plug.
  2. Gather together all my old cords, mice with wires, some mice without wires, 4G thumb drives, and other do-dads. Those still need to be sorted so I can put most of that pile on the “take to e-cycling” pile, too.
  3. Pull all my old books I will no longer receive value in owning from my shelves. Put them in a box and was pretty stunned at how much it weighs. I guess I’ll donate these to Goodwill or something, but below is a picture of my first real book purge.

Book Purge

I hope this is a good start to the year.

What can you purge from your life that would make things feel lighter for you?

Attributes of a great development team member

My boss’s boss recently asked me, “If an Agile leader were to outline the top characteristic of their best developers, what are they? “

The response was relatively quick, and rather “off the cuff”. After re-reading it, I like my answer!

  1. Seeks to help others with any aspect of product development, regardless of her individual specialty
  2. Independently pursues continuous learning and shares new knowledge with the team
  3. Encourages and enacts technical practices to improve code and product quality
  4. Collaboratively and respectfully engages during all Scrum events
  5. Pro-actively seeks and provides feedback on code and the product being created
  6. Encourages, coaches, and embodies team-level agility
  7. Respectfully collaborates with other teams to ensure valuable features are DONE within each Sprint
  8. Embraces and actively supports organizational-level agility
  9. Enacts and coaches product instrumentation enabling Build > Measure > Learn

What’s missing from this list?

What could be improved in the original list?

nodemon leaving Node.js process running

nodemon is a great tool for use when writing Node.js applications. It is a simple little tool that simply watches for changes in the file system of your project and restarts the Node.js application when a file changes.

Of course, there are more options, but that’s the essential idea. Unfortunately, once you launch nodemon it is off and running and the only way to stop it is to brek out of the command shell with CTRL+C.

Doing this can leave a running instance of your Node.js applciation running as a background process. HUGELY annoying, especially when your app is a long-running application, like a web application.

Fortunately, nodemon subscribes to a couple of Node events and we can tap into those if we wrap nodemon in a JavaScript task runner like Gulp.

Below is my simple gulpfile.js which starts nodemon and has it watch for certain events that will be emitted when shutting down the nodemon process. This catches the exiting nodemon process and kills the Node.js process it spawned.

Is Agile still applicable?

I just read this interview article with Bob Martin and I have a few thoughts about it.

Uncle Bob is extremely code-focused and always has been in his career. This isn’t a criticism, far from it, but one must take that into account when reading his opinions on such matters. He is heavily involved in the Software Craftsmanship movement, which he sees as a follow-on to the Agile Manifesto itself.

Like any business practice, Agile has evolved and matured in directions the original 17 signatories never imagined . Others people beyond the original signatories have done a lot to further the principles into techniques like Scrum, Kanban, DevOps, etc. This is to be expected, imo, as something matures. Even Lean has evolved far beyond Demming’s orginal models.

Though the work of others in the field, we’ve learned that the original 4 values and 12 principles are applicable outside the context of software development. The primary direction it has evolved is toward frequent delivery with applied empiricism to use data in guiding decisions. We are beginning to do this quite well as an industry, imo. At GoDaddy, we are even using Agile practices to manage the work of our training team and that has been quite successful.

I would offer that his views are, of course, quite opinionated and one would likely hear different opinions from the other 16 original signatories. I would even call his views on Agile slightly dated.

In summary, Agile principles can indeed be applied to business practices within the right contexts and we’ve seen through evidence at other organizations (like Intuit, GE Medical, and others) that Agile practices can indeed scale. It’s not easy to do, of course, because scaling ANYTHING is difficult and more error prone than small scale efforts.

I respect and appreciate Bob Martin’s opinions, but in reading this particular interview I think they should be tempered with the evidence we have that shows Agile’s success beyond its original intent.

Memo on O-Ring and Software Erosion

One of the most fascinating documents I’ve read to date is the memo from Roger Boisjoly on O-Ring Erosion. The original target audience for this memo he’d written were the management folks of Morton Thiokol back in 1985, about six months before the Challenger disaster.

What I find so striking about this whole story is its resemblance to the field of software engineering. We software developers can relate to this story all too well. I’ve personally been in this situation more than once. Heck, some of us are in similar kinds of situations all the time.

Roger Boisjoly attempted to halt the launch of the Space Shuttle, unfortunately to no avail. In his particular case, a failure of the Space Shuttle would cost the lives of the astronauts on board. But what about the software that we are crafting? In most cases, a failure of the software would not result in the loss of human life. It would cost the company a particular amount of money. Worst case scenario, its reputation would be flushed down the drain alongside the money.

But what should we do when we encounter reliability issues in the software that we’re working on? Well, first of all, we make an assessment about the severity and the impact of these problems and fix them accordingly. But what if it takes us a couple of days, a week, two weeks or even a few months to fix things? Well, then we usually turn to the management staff, explaining in our best non-technical terms what’s going on and ask them for the time (aka budget) we need. But here comes the tricky part. What if they don’t want to listen? What if they don’t take us serious? What if they don’t trust us that our findings are correct? What if they simply ignore us, wondering why we still have the energy to even come talk to them after or during this dead march that we’re in? What if they do listen to our plea, wholeheartedly agree with everything we say, walk us back to the hallway and then simply don’t give us anything except more business requirements and feature requests?

But now on to the million-dollar question. What do we software developers do when we don’t get the time to do the right thing? Well, we could try to fix things in our spare time, sacrificing the precious time we have with our family and friends or perhaps even our sleep for the next couple of days, weeks, months, perhaps even years? I don’t think that this is very sustainable. Or we could simply ignore management, stop adding new features and business capabilities and start fixing things on our own behalf, like some kind of software development team mutiny? I guess this will end up with one or more developers getting fired. Or we could start a campaign on social media about how software developers are being wronged at this or that particular company. Would anyone even care? And this will probably end up in some layoffs as well.

So what should we as professional software developers do to make things right in these kinds of scenarios? Maybe the people of the software craftsmanship movement could draft a script with concrete actions that guide software developers when they find themselves in the same situation as Roger Boisjoly?

I can only wonder what would happen to our industry if only 10% of all software developers would follow the actions described in such a manifesto. Wouldn’t that be useful advice?

Definition of Ready

There is a practice in many agile conversations known as having a “Definition of Ready” for a Product Backlog item. That is, a given User Story (or other PBI) must meet the Team’s “Definition of Ready” to be considered actionable or even worthy to estimate.

This can be desirable from the team’s perspective when they are not getting enough information about the work they are being asked to do by the Product Owner.

While I understand the desire for this from many teams perspective, this as a potential struggle between precision and self-organization. Lest we forget, backlog items are invitations to conversations in which many of the attributes are detailed in collaborative discussion.

I know that having a Definition of Ready works for many teams. No denying that I’ve seen it be effective to helping clarify ambiguity. This is just a caution that it can go too far in some cases if we trade flexibility for a mandatory checklist.

The Definition of Ready is a practice that I believe makes sense to understand and explain to any team struggling with lack of clarity in requirements, but I also believe it is a practice that a team can elect into, just as we choose Planning Poker vs. some other estimation technique.

Agile 2016 Needs You

You know that new way of wielding JavaScript you’ve been using? Or that container deployment model your company is building? Or the way you’ve integrated UX design with the workflow of a Scrum team? Yeah, we want to hear about that.

It’s that time of year again. Time to submit proposals to the Agile Alliance’s annual conference. This year’s event will take place in July in Atlanta and promises to be a full week of jam-packed learning.

I’ve been going to the annual Agile conference for many years now, and been part of its planning for the last few. This year I am pleased to report that I am the program chair for the technical tracks at Agile 2016 and this means I am looking for you, oh developer who thinks of what they do as post-agile.

Although there are numerous learning opportunities at Agile 2016 including dozens of topic areas, I like to focus on what started the conversation in the first place: Delivering elegant software in a timely manner with high quality and satisfied customers. That’s why I am pleased to be soliciting sessions in the following areas:

  • Development Practices and Craftsmanship
  • DevOps
  • Testing and Quality Assurance
  • UX

These certainly aren’t the only things learn about at Agile 2016. The Agile conference is the biggest of its kind in the world and attracts presenters and attendees from all over the globe. Although registration is ready and open, this isn’t a call for attendance. This is a call for participation.

Come share what you’ve learned that’s making your team more effective. That’s what it’s really all about. Whether it’s that new stack of JavaScript tools you are using or the container hosting model your company is piloting or the empirical processes you’ve used to build something cool, come share it. I guarantee you’ll be glad you decided to submit a session and you will definitely learn something from someone else, too.

I have never left an annual Agile conference without a new bag of tricks that I want to try for myself, my team, or my company. I invite you to the fray.


I’ve had some great opportunities working with teams applying lean and agile techniques to domains beyond software development. Along with other areas, I’m having lots of conversations around applying Scrum in HR teams.

This is fairly unique because the core usage model for Scrum is to apply it when the work is fairly unknown and complex, and the team is working together to create a shared product. Many knowledge worker teams simply aren’t like this. HR tends to be one of them.

It helps to identify the different types of work happening in each team. I delineate three types of work: project work, ad-hoc work, and repeating work. Here’s what I mean by each.

Repeating Work

This is work that happens on a schedule and happens often. For example, new employees may start on any given Monday in our organization, and processing the paperwork of adding those new employees is something that happens each week, regardless of other plans.

Ad-Hoc Work

Ad-hoc work is what happens when something out of the ordinary occurs and must be dealt with immediately. In IT this would be akin to, “the server is down.” In HR it might be something like, “someone just anger-quit” or some other circumstance that must be dealt with immediately.

Project Work

This is work that fits into a project (has a beginning and end) and has a clear deliverable. This work is planned and is often amendable to being managed with lightweight Scrum. Project work is often the work that motivates people and offers them opportunities to go beyond their traditional responsibilities.

An example of project work might be creating a newsletter for a company’s new wellness program, planning an event, or implementing a new benefit program.

Teams vs. Teams

In agile software development teams, we try and break down silos between individuals and encourage shared accountability for work and output. While this is a worthy goal, it is more difficult in teams like those we find in an HR department. In these teams, we really do find teams of individuals rather than a single cohesive unit focused on one deliverable. While one can argue that it would be an improvement to grow the team into one with shared accountability, this is far easier said than done. Teams of individuals are the norm.

We All Want More Project Work

Project work is typically what moves a team, department, and ultimately a company, forward. Yes, the repeating work must be done to maintain current levels of service and excellence. Yes, the ad-hoc work is often very important and cannot be deferred.

Yet, project work typically is where we get to add new value. We get to create something that didn’t exist before, whether it is software, an education curriculum, a new HR program, or perhaps revamping of an old system.

Project work (sometimes ad-hoc) is where we get to exercise autonomy, mastery, and purpose. Predictably, it is the work that most people find fulfilling. It also happens to be the work Scrum is most adept at managing. Repeating and ad-hoc work are typically things that take away from a Scrum team’s capacity (whether we track it in the Sprint or not).

Lightweight Scrum for Teams of Individuals

Scrum perfectionists beware, I am about to run an Extract Interface on Scrum, leaving a few bits behind for software teams to implement.

We’ve used a lightweight Scrum-like process for managing our family’s work for many years and I’ve found that applying similar practices to non-software teams tends to work well as a starting point. Here is my base formula for an agile practice in environments like these.

  1. Plan work together no less often than every 3 weeks. Focus on project work first while doing so. Leave capacity for ad-hoc work.
  2. Show your work to each other and stakeholders at a Sprint Review. Solicit feedback.
  3. The team reflects on itself and how it does its work each Sprint.
  4. The team keeps a visual representation of the Sprint Plan current at all times. This is typically a wall of cards, Trello, or some other lightweight approach.

Note this is a starting point and not an ending point. Over time, we hope to see more cross-training and generalization in the team. We hope to see fewer incidents of ad-hoc work. We hope the team will actually learn to self-organize. All of these things can indeed happen and more.

There are lots of places to go once you have these basic elements in place.