Be a Servant Leader

Managers: be a Servant Leader.   Why?   Because it works.

I’ve been practicing Agile in various forms since 2006, and along the way someone taught me about the concept of Servant Leadership.    As I learned more, I found that Servant Leadership fits my natural leadership style, so it is something I’ve embraced in my career, and it’s paid off well.

Over the years, I’ve seen many people who aspire to this style of leadership behave in what is essentially an anti-pattern.   This has been witnessed by me many times:

  • A team is in a room, or on a conference call, addressing something important.   This could be a red team addressing a problem, an application deployment that isn’t going well, a testing session, anything around which a company might assemble a team aimed at quick resolution.
  • The team is working productively, calmly, with a reasonable method of hypothesis development and testing, and all is going as well as possible.   Then, an executive or another manager joins in.
  • The manager may listen quietly for 10-15 seconds, or even a few minutes, and then, attempting to help, begins asking questions.
  • The team perceives the questions as direction, drops what it’s doing, loses its focus, and chaos ensues.    People are concerned with addressing the manager’s questions, testing the manager’s theories, basically abiding the manager’s desire take the lead in solving a problem that may or may not be well understood.

Here’s my suggestion, other managers: If you want to find out how that team is doing, it would be acceptable to call in, but only if you don’t speak (other than to offer kudos to the team for solving the problem, once it’s solved, or to announce that dinner is on its way).

Of course, if you’re pretty confident that the team is going off the rails due to fatigue or knowledge gaps that you can fill, then get in there and help.   But keep in mind that as soon as you speak, you will likely cause a change in their focus.  You may be directly, negatively impacting productivity, motivation, and leading to a longer Time To Resolution.

If you think it’s OK for you to jump in and start testing knowledge in the heat of the battle because nobody is intimidated by you, you’re probably wrong.

Be a Servant Leader.   Be there to help when the team needs you, and be out of the way when the team is doing well without you.


Raspberry Pi Jenkins Monitor

Behind my desk at work I have a display on which I keep an eye on one of our Jenkins environments.   I initially set this up using a spare Win 7 PC, running a hacked open source screen saver that would load a url into a .net web control.     That worked fine, but I wanted to get rid of the PC that gets no use other than displaying my web page, so I turned to my RPi.

In my research, I found there are several approaches for this.   But most of them boil down to either Midori or Chromium.    I took the Chromium route.

First, about the Jenkins page I use for this.   What I’m looking for is queue length, status of agents and executors, and status of recent builds.   With that goal, I’m not using one of the radiator plugins, I’m just loading build history on the All tab: http://<jenkins address:port>/view/All/builds?auto_refresh=true.

Note: The auto refresh parameter at the end enables Jenkins auto refresh so that you don’t have to plug in a mouse to click the Enable Auto Refresh link on the page.   Thanks to my brilliant team for deciphering that secret code.

Basic set up was easy:

  • Latest Raspian image (using Noobs)
  • Do the steps in lokir’s blog, using the appropriate URL (above)
  • Optional: add –enable-offline-auto-reload  to the chromium command to reload in the case the page goes down (not sure this does what we think it will do)
  • For power, I just plugged USB into the monitor’s USB port, so there is no separate power supply required for the RPi, which is nice

That got me going.    But the display behind my desk is in portrait mode, so that I can see most of the Jenkins agents to keep an eye on them.    So I needed to flip the display.

ZenTsang’s post here (scroll to the bottom) is the way I got this working in portrait mode.   No re-compiling, just give the GPU a little more RAM, and plug


into the config.txt file.

And viola, I have a RPi Jenkins display!


The next challenge, for anything that doesn’t auto-refresh, would be to make the page reload occasionally or on a trigger, but Jenkins makes this easy with the Enable Auto Refresh link.

It’s a heavy page, but the RPi is keeping up.  It’s been running for 24 hours so far without issue, so I think we’re good to go.   If you want to do something similar, it’s not too tough, even for a Windows guy like me.



What Matters

Last spring, Mike Lamonica, a co-worker, came to work with his head shaved.   I of course commented on the modification – something like “it’s about time you got that rats’ nest under control” or possibly using slightly stronger language.   He then told me about St. Baldrick’s.  Mike lost his beautiful daughter Juliana to cancer at age 3.

This year in addition to donating I volunteered as a shavee on Mike’s team JJ’s Angels.    So on Sunday my 49 teammates and I all lined up Army style in front of a row of chairs at a bar in Syracuse to have removed something that for many of us is in short supply.   And it was one of the most moving experiences I can remember.

I’ll be back next year.

Here are some links:


Rotating Scrum Master

I work with what is now a fairly mature and highly functional scrum team.     Back when we started, we were working with a consultant on a set of technical issues, and along the way he suggested we allow anyone in the team to serve as scrum master.

I initially had some concerns about this.  In my CSM training a few years back we talked about the development of the team – the forming, storming, norming, performing thing –  and how changes of any kind (additions to the team, removing people, etc) would impact the team dynamic and potentially push the team back into an earlier stage of development.  I also had past experience as scrum master for a couple of years, and we never even considered rotating at that point, so I just never really thought about it.

So when we started, we named a scrum master and proceeded.   Along the way, that scrum master started getting the itch to do ‘real’ work again, so we had someone else try it.   18 months later, almost everyone has rotated through the position, and it’s worked out very well.


  • The scrum master doesn’t get bored.
  • Everyone gets a chance to try something new.
  • The team is reminded what it’s like to be the scrum master.
  • The scrum master is reminded what it’s like to be a delivery team member.
  • Rotating the role tends to create some good team bonding opportunities.


  • The only real con I saw was some of the less tenured people didn’t really know who to go to – how to remove obstacles, so they needed some help.   For the most part though the team helped them with that, and it ended up providing good learning opportunities all around, so it was a good investment overall.

If you’re thinking about it, give it a try.  I wish I had tried it earlier.

Choose Progress over Comfort

I know a few other technology managers who obviously value a candidate’s ability and desire to build tenure in a position quite highly.   I think the reason is stability – they are looking for someone who, once the job has been mastered, will continue to perform that job well for a very long time, perhaps their entire career.   Someone who will do a good job, won’t create a lot of waves, and, most importantly, won’t leave.     And I get that.  Clearly there are benefits that come from employee stability.   But when I’m looking at a resume, a history like that is a red flag to me.

No one has (yet) left the team I currently lead, but I’ve had to deal with turnover before.  It’s never fun, especially when you need to quickly fill a critical position that you didn’t plan on being vacated.    But that’s part of the job.   You do your best to back fill properly, and in the end it always works out.

To me though, the pain of employee turnover isn’t as important as the benefit of hiring rock stars.  Now I’ve learned you need to be careful how you hire rock stars, but more on that another day.    What I’m looking for is people who are never satisfied.  I look for people who will come in, learn quickly, master the job, shine brightly for a year or three, take the team to new heights, and then rather than get bored, choose to look for their next challenge.  Hopefully that next challenge is within my team, but there are no hard feelings if it’s another team or company.   I’ll take 4 engaged, thoughtful and truly motivated people over a team of complacent people 3 times that size any day.

Someone I used to work for summed it up well – choose progress over comfort.

PhotoWham Reviewed

Nobody told me PhotoWham was up for an editor’s review on CNet’s, but that happened last week!   Here’s an out of context summary:

“It works in the latest versions of Windows, including Windows 7. It’s one of the simplest but most efficient digital photo resizers we’ve tried.”

I’m very excited, as that’s exactly what I was going for with this product!    Apparently others are excited as well; the number of downloads/week is skyrocketing.

Here’s the page:



Arduino Range Finder

I’ve been working w/ the LiquidCrystal library (which rocks), and the MaxSonar EZ4 (MB1040).  Same LCD as I used in previous posts.

Only reading one range finder so far, but this is a start. 

The LCD is set up in 4 bit mode – digital pins 12, 11, 5, 4, 3 and 2. 

PWM pin from the EZ4 is in digital 7.

Enough of that, here’s the code!


#include <LiquidCrystal.h>

 // these constants won't change.  But you can change the size of
 // your LCD using them:
 const int numRows = 2;
 const int numCols = 16;
 // initialize the library with the numbers of the interface pins
 LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
 // pin hooked up to PWM from the ez4
 const int pwPin = 7;

 //variables needed to store values
 long pulse, inches, cm;

void setup() {
  // set up the LCD's number of rows and columns: 
  lcd.begin(numRows, numCols);
  // throw up a shameless banner
  writeLcd("Manatee Software", 0, 0, true);
  writeLcd("", 1, 0, false);  

// Main loop
void loop() { 

// update display
// the main process that loops
void updateDisplay()
    pinMode(pwPin, INPUT);

    //Used to read in the pulse that is being sent by the MaxSonar device.
  //Pulse Width representation with a scale factor of 147 uS per Inch.
  pulse = pulseIn(pwPin, HIGH);

  //147uS per inch
  inches = pulse/147;

// put in the label.  doesn't seem to hurt anything to clear here, but it's
// counter-intuitive.  Probably bad practice...
  writeLcd("Inches: ", 0, 0, true);

// set and print the inches from the calculation  
  lcd.setCursor(9, 0);

// write to the LCD at a defined position
void writeLcd(char data[], int line, int pos, bool clear)
  // clear if desired
  if(clear == true)

  lcd.setCursor(pos, line);

Is this a bug or a requirements change?

In my day job, I work as a software architect and scrum master for a large corporation. Today, a group of managers asked me this question. I say what’s the difference?  In Scrum we try to focus on business value.    Let’s say there are two potential changes on the table:

1. A bug the delivery team introduced with this release. An additional character is displaying in a drop down box text value. All users will see the bug.

2. A new feature/requirements change that we learned from the first people to actually use the latest release in production. Making this change will reduce the potential for error and save each user some time.

All of our users work for the company, so ‘soft’ benefits like avoiding embarrassment caused by #1 don’t matter a whole lot. We don’t have time to do both. In this hypothetical scenario, the effort to fix them is identical.

The waterfall organization, focusing on the ‘contract’ between development, PMO, and the customer, would tend to fix #1, as #2 is out of scope.

The Scrum team would ask which item delivers the most business value. Business value can be tough to determine in a large company. When the user group numbers in the thousands, saving each user some time, even if only 5 seconds/day would be a flag to me, though. Even at 1000 users, 5000 seconds/day x 200 work days/year = 278 hours/year in potential savings. While that’s not going to make or break a large company, it’s clearly more value than the 0 seconds/day the bug fix would save users.

One thing I like about Scrum is the fact that it exposes everyone on the delivery team to patterns of thinking that in many large waterfall organizations are only known to senior managers. Scrum is helping our team members behave like business people, which is something sorely needed in a Dilbertian world.