Category Archives: Team

Response Unicorn Isn’t Responsive (When Your Team Doesn’t Get “Agile” or “Lean”)

Agile, Career, Leadership, Lean, Learning, Software Career, Team, , , , , , , , , ,

In response to Agile: 3 Signs That You May Be Drinking Unicorn Blood by Joseph Nielsen. Joseph is a friend and former co-worker who’s reviewed my stuff in the past, and we collaborated on the concept for this post. I’m just a year late in publishing it.

Whatcha Mean We Wanna Be Agile? What The Hell Is Lean?

Having spent at least half of my career on teams with ad hoc organization and work practices, this is a question I once asked. It was my first time at Agile Roots in early 2010 when I knew I wanted to be Agile. I mean, I understood the value of some of the tools and practices often associated with Agile. Like several people from my company at the time, I had caught the “vision” and thought bringing back some of these tools and practices would make our organization Agile.

I was a development team lead at a previous employer at the time and was utterly unprepared for the level of resistance we would receive from both upper management and individual contributors on my team. Knowing what I know now about change and why people find it scary, I’d recommend my younger self to read the book Fearless Change: Patterns For Introducing New Ideas or a similar work. Nevertheless, I (and several others) pushed forward with our “agile rollout.” We created physical kanban boards on every empty wall in sight and held standups around them. In the meantime, the company was hiring traditional PMO project managers who were trying to put it all into MS Project, and some folks were trying to get traceability by plugging the results of standup into electronic kanban boards using Team Foundation Server.

Rightly, many folks were questioning the approach and overall vision. Developers just wanted to go back to having their 30-45 minutes being spent in standups back. Management wanted PMO-style project traceability, and accuracy be damned. Analysts wanted to build their requirements and throw them over the wall to developers. QA testers and dev wanted to interact as minimally as possible.

They were all quoting Carly Simon whether they knew it or not.

Are you seeing some problems?

We didn’t get buy-in.

We didn’t have a concrete strategy for implementation.

Most importantly: WE WEREN’T HAVING RETROSPECTIVES. For some misguided reason, we made the same mistake I’ve seen so many others make: we thought standups were the key, not retrospectives. To be honest, I’m not even sure we knew where to start.

I’ve heard this called frAgile. At any rate, eventually something had to win out, and it was the waterfall/ad hoc approach. We took down all the boards and ended all of our agile experiments at the direction of leadership. I don’t blame them. The whole situation was a hot mess.

Other Ways To Do It Wrong

I had seen the light, and therefore, the next company I worked for wasn’t adamantly against Agile. I made sure of it. However, that company is no longer in business. No, I don’t think it had much to do with their agile adoption or the semblance of it they had. This group had many of the basics of Scrum in place, even if they got there partly by accident.

They would pick up bits and pieces and bolt them on until, at a certain point, they had standups, planning meetings, reviews with stakeholders, and a leader huddle which sort-of worked like a scrum of scrums. But they were estimating work in hours, they didn’t organize cross-functionally, stuff was “thrown over walls” for others to pick up all the time, and THEY WEREN’T HAVING RETROSPECTIVES.

You might ask, where did the good practices come from? The folks in charge had those ideas. If an idea didn’t come from someone in charge, it probably wasn’t an idea worth having. All fine and dandy, but you can imagine the teams didn’t feel much autonomy (a key motivator from Daniel Pink’s Drive: The Surprising Truth About What Motivates Us). They certainly weren’t coming up with a lot of great ideas on how to be better.

I came in and still had my Agile Roots-colored glasses on. Everything I wanted to do was related to getting folks thinking about continuous improvement, continuous learning, and reflecting on what we were doing and experimenting to see what we could do better. (By the way, I believe that as an Agile organization, those are the main components you MUST HAVE to get to a thriving place.)

At any rate, my enthusiasm was– out of place, and my leaders reminded me on several occasions that I should mind my position and keep my head down.

So I did.

They promoted me for it. Twice.

With a little more clout, I picked my battles, and where possible, I tried to get the folks I worked with to think differently. We were starting to see some progress. Developers were getting excited about our work again. They were getting back the passion for this amazing job we do. By this time I was the software architect for all the teams, and I was unhappy. Even if folks in the org were starting to catch the vision, upper management was not. I believe they thought we had our working system and didn’t need to try to make it better. Two years was an awfully long time to see as little progress as we had, and I felt like I was still dragging leadership along kicking and screaming.

Additionally, the company was struggling financially (and worse than I knew). When I announced my intent to start looking for another job, the next day I was asked to put in my notice after having been promoted during that same calendar year. They couldn’t afford me if I weren’t in it for the long haul.

So I tucked my tail between my legs and decided to do better at picking my next employer. I wanted a place where Agile was already a reality, or at least where a culture of learning and improving wasn’t just “this silly idea Will has.” Three weeks later I was starting work at what I hoped would be the right place. The lesson, as far as I was concerned at the time, was that bottom-up influence doesn’t work for Lean-Agile adoption.

The Grass Was Greener (Purpler)

HealthEquity touted their culture when I was interviewing, and I DID NOT buy into it at first. My previous employer was ranked in the top 50 for corporate culture in the nation more than once by Forbes. “Culture” was no longer a brand of kool-aid I drank. I guessed the purple drink was probably laced with cyanide or strychnine.

I did know three things about HealthEquity:
1. A friend of mine already worked there, referred me, and spoke highly of the place.
2. The director I’d be reporting to was new to the company, and he seemed to share some of my values and was open to new ideas.
3. The company was offering competitive wages including stock options. I didn’t assign a mental value to the stock options (they had none), but I figured if they were incentivizing folks by giving them a stake in the company, that probably wasn’t all bad.

It was enough. Now I’ve worked for HQY almost double the amount of time I’ve ever worked anywhere else. We’ve been through good times and bad times and great times.

When I started, there was no SDLC at HealthEquity. Stakeholders would sit next to developers and tell them how to program. Developers would push code directly to production and had admin access to the production database. We had a QA manager (in a QA department of one), and he ended up doing DevOps and release management as a full-time job because no one else was doing it, and the company assigned him the “quality issues” they were having with releases because that’s when everything broke.

Work was very ad hoc with a tendency toward waterfall. I don’t remember my actual response when I was finally allowed to contribute effort toward a production project that wasn’t a bug, I know I was ecstatic after the months in purgatory. I’m not sure if I let the “excuse me” out when my director asked me to create a comprehensive design for an entire project that looked like something that would take months to complete before I wrote a single line of code.

Of course, I tell you this to supply a baseline. HealthEquity is now one of the premiere agile shops in Utah. How did we do it? RETROSPECTIVES. Partly.

It Matters Who Buys In

The company hired a new CIO/CTO about three months after I started. Her role was to bring us to some semblance of order, so we could scale predictable teams and get the quality problem under control. I think it was her second month when we had some ridiculous number approaching TWENTY urgent production releases because each successive release to production either didn’t fix the problem we were trying to fix or they caused a cascading issue so drastic it required another urgent release.

The CIO/CTO was patient and prescribed a strict diet of agile conversion and a focus on quality. The quality staff ratio improved to one tester for every two developers in short order. A director of PMO with a strong Agile SLDC background was brought in. Our tooling and work pipelines were updated and organized. We organized into cross-functional teams of dev and qa. Then came the consultants.

To their credit, the consultants did a great job setting a baseline for what Agile should be while training us on the specific process of Scrum. The sessions were filled with retrospectives and lean coffee. I was in heaven. Yes, there were a few folks who were not pleased. Mainly those who’d been with the company for some time. They didn’t take long to self-select out to new jobs once the future of HealthEquity technology became clear. The baseline was set, and that was one of the keys.

The consultants, I think, were a critical factor. It showed everyone two things:
1. Leadership was serious about this agile thing because they were taking us away from the constant pressure to deliver more features so we could learn about it.
2. As a company and a team, we were willing to put our money where our mouth was. Hiring consultants is in no way cheap.

Is this the end? Have we achieved “AGILENESS LEVEL 5000”? No. Will we ever? Probably not. The secret true agilistas know: there is no such thing. There is only review and improve. At HQY our technology leadership (and even our CEO) understands this. We give our teams room to experiment, fail, improve, succeed wildly, and be better tomorrow than we are today.

The goal of this phase of adoption was to set the baseline with a consultancy group, create ground rules, then unleash the continuous improvement and learning. The consultants were brought back on site multiple times to iterate. Over time, folks began to catch the vision. We hired in-house agile coaches to take over the continuous improvement. These are people who could be consultants in their own right, but wanted a 9-5 at a local company. The dedication to doing nothing halfway drove home the idea that HealthEquity is in the lean-agile thing for the long term.

Why Is It Awesome?

At HealthEquity, teams work together with leadership to take action on feedback and retrospectives. At first, I remember being surprised when issues were actually addressed. I’ve never worked somewhere so responsive. In previous organizations, near revolt was sometimes required to make any meaningful change. Here, we adapt, adjust, test our assumptions, and try something new when we don’t get the result we hoped for. Again: retrospectives. But the source of our willingness to experiment and take action to improve comes from the top down. If your organization’s leadership doesn’t believe in it, and you do– maybe it’s time to start looking at better options.

Like Joseph wisely quoted when he read this “love is a battlefield”. Struggling and improving together is the point; it is the destination. Today, we are working toward a low WIP-limit team collaboration approach and building out the quality and tooling to support Continuous Delivery. Will that be the end? No. Our teams will not settle. They will continue to find ways to improve. It’s in our DNA.

Let’s Retro This Article, Shall We?

What went well:

  • My reviewers were fantastic, and the article wouldn’t be half as well written or have as many good images/memes without them (THANK YOU, Joe, Katie, Britton, Caulin, Matt.)
  • It’s always a little dicey supplying personal details in an article like this, but I think it adds some credibility and people seem to like it.
  • Writing about this helped me increase my understanding of the patterns of a successful agile rollout.

What didn’t go well:

  • The speed with which I completed the article. MONTHS.
  • I let it block other things I’ve intended to write.

What could improve:

  • It could have maybe been broken up into a couple of articles– I waffled over this a lot. So looooong.

I’d love to see your retrospective items in the comments, fair reader.  Also, why not check out my other Agile articles. See you next time.

A Tech Lead Is Not A Manager: Influence vs. Authority On Agile Teams

Agile, Career, Leadership, Software Career, Software Development, Software Engineering, Team, Technology Career, , , , , , , , , , , , , ,

I previously wrote about how I worked on an agile team as a tech lead. The article focused on the things I recommend. Today, I’m going to take the opposite approach and share what to avoid: the misuse of authority including mistaking an influencing role for an authoritative one.

You can read the original article here.

Roles, Roles, Roles

On agile teams, a Tech Lead is far more like a Software Architect or an Agile Coach or a Product Owner or an Engineer than a Manager, Director, or another role with people reporting directly to them. You don’t have AUTHORITY as a Tech Lead, your weapon of choice is INFLUENCE. Of course, even people with authority should rely on influence as much as they possibly can. Authority is a tool in the toolbelt of some roles, and those people must use it sparingly. Autonomy is too important to take away from creative workers (and Engineers are indeed creative).

At times authority must be used by people in what I like to call “dark side” roles. Managers, Directors, Veeps, etc. must at times use the stick instead of the carrot. Usually, this is reserved for extreme cases when a team member is refusing to follow company policy or is threatening or endangering someone. In a positive culture, these things should seldom IF EVER happen.

One of the things I love about the organization at my current company, HealthEquity, is the culture of influence. Influence is the currency of the day at all levels of leadership, and it’s used efficiently and effectively.

What Does Misuse Of Authority Look Like?

Some key things to look out for: body language, word choices, and the audience. Watch for words like these coming from your mouthhole:

But, I’m the Architect/Manager/Director/Scrum Master/Tech Lead/etc…

…you have to do this.
…this is the only option.
…because I said so.
…it’s my way or the highway.
…eat crap and die.

Absolutes and personal attacks/insults are not going to work. They may sometimes achieve the immediate effect you wanted, but it’s going to come back to bite you in the end.

Avoid negative feedback in a group setting at all costs. If you MUST provide negative feedback (and yes, sometimes we must) always, ALWAYS, do so in a private 1:1 situation. Involve your people leader if you aren’t comfortable one-on-one.

Instead, look for ways to encourage, build-up, support, and assist people in doing what you believe should be done.

Shameful Anecdote Time

Once, in an earlier decade of my life, I was an inexperienced young team lead. I had responsibility for a developer who was undertaking a critical task. The task wasn’t moving along the way my manager and my manager’s leader hoped it would. There was some time sensitivity involved, and I was asked to research the issue and get things moving along. I did some investigation and found that the developer was spending a lot of time (over 50%) not engaged in his work.

I’ll admit it; I was frustrated.

Instead of following the advice I’m giving in this article, I decided to walk right up to this person’s cubicle and ask how the work was progressing. Nothing particularly wrong with the approach, although in hindsight, I should have known the discussion was likely to become sensitive. I should have invited the developer to a private location to discuss one-on-one.

Anyway, when we spoke, the developer told me how well it was going and how hard he was working and how he’d have this already late project completed just as soon as he could, but not for at least a few more days. When describing the work remaining, I felt it was completely trivial. It could have been completed THE NEXT MORNING.

I won’t go into detail, but I lost my cool. I felt pressured and I let the pressure rule my emotions. My voice rose high enough for at least neighboring cubicles to hear, if not more. I told this developer that he would finish this work by the end of the next day or there would be hell to pay.

I’ve never seen someone’s face go from zero to pure unadulterated hatred so quickly.

The developer finished the required work on my timeline, but I had ruined a relationship and completely demotivated my co-worker. As kind, cheerful, and pleasant as I could be, it never made up for my error. The individual became a habitual underperformer, and eventually was let go by our manager.

I’ve always wondered how the situation might have gone if I knew then what I know now. Would I have pulled this individual aside privately? Would I have offered my help or another’s on the team to push through the last bit of work? Would I have asked more about the situation and sought to understand why he was underperforming in the first place?

I’d like to think I would have. I’d like to think I’d have given less weight to some of the authoritarian “truths” I’d been exposed to growing up.

Avoid False Truisms Of Authoritarians

Avoid being taken in by the truisms of autocratic leaders like Bonaparte and Hitchcock. Do not let their philosophies influence your leadership style.

“Men are moved by two levers only: fear and self-interest.” -Napoleon Bonaparte

“If an actor comes to me and wants to discuss his character, I say, ‘It’s in the script.’ If he says, ‘But what’s my motivation?’ I say, ‘Your salary.’” – Alfred Hitchcock

The work we are doing in any creative or thought-related organization requires 100% of the team’s buy-in, commitment, and enthusiasm to be as effective as possible.

Leaders don’t and can’t have all the best ideas. Create psychological safety for people you work with to aid their growth and contributions.

Authoritarian leadership styles have little or no place in Agile organizations.

In closing: I recommend avoiding the “command and control” mentality in favor of “inspire and innovate”. Tech leads (and technology leaders in general) aren’t running military operations; we are engaged in creative endeavors.

If you enjoyed this article, why not check out some of my other favorites on the subject?

Lean Teatime Is Both More And Less Than Lean Coffee

Agile, Leadership, Lean, Team, , , ,

Ok, I’m going to share this like no one has ever thought of it before.

braceYourselvesMeme

The other day, I was giving a lightning talk at Utah Software Craftsmanship about how I run bi-weekly team meetings with Lean Coffee. In short, I highly recommend the practice. It helps keep our meetings quick and on-task. Succinct really.

People seem to like it because we discuss the most important things, and we usually finish early.

If you aren’t allowing your meetings to end on time or early– use this opportunity to rethink your life. You don’t want to sell anyone death-sticks.

Back to the lightning talk. I spoke for about three of my five allotted minutes and opened up the floor for questions. There were a few, but the most interesting question by far (paraphrased) was this:

How do you get people to arrive at desisions when running a meeting with Lean Coffee?

The query took me by surprise.

For a moment, I considered decisions that came out of our meetings. Granted, there weren’t a ton. Often these sessions are more informational. Sometimes they result in questions I don’t have an answer to, so I take to-do items and communicate back to the team later.

However, we did reach decisions. We planned a team party, for example. For these types of situations, I looked for a majority consensus. Often, we found ourselves using a technique I will now dub “Lean Teatime”.

6808987192_cb44303a47_z

Lean Teatime

Lean Teatime is a subset of Lean Coffee. It can be run either in the middle of a lean coffee session, or completely separate from it. The gist is simple:

  1. Set expectations by making clear the intent of the Lean Tea session (e.g. selecting a venue for a team party).
  2. Make sure everyone has access to Post-It notes and Sharpies (the tools of any agile facilitator).
  3. Set a timer (2-5 minutes) and have the group come up with as many ideas as possible. They will write each thought on an individual Post-It.
  4. Organize similar items into groups and stick them to a desk (or wall for bigger groups).
  5. Give everyone groups/3 dot votes and turn them loose to place dots on the item groups they prefer. Allow one dot per group or multiple, your choice (I prefer 1 per).
  6. Order the results from most votes to least. In the event of a tie for first, vote one more time with the two tied items only.
  7. I like to do a fist of five at this point to see if anyone just hates the thing that ended up on top. In this case, I’ll ask the group to offer mitigation suggestions.

All of this only takes a few minutes and usually has a positive result.

So there you have it. The “genesis” of Lean Teatime. I hope you find it useful.

If you enjoyed the article, hit me up on Twitter or leave a comment below.
If you disliked the article, hit me up on Twitter or leave a comment below.

Agile Teams Don’t Always Have Tech Leads, But When They Do…

Career, Leadership, Learning, Software Career, Team, , , , , , , , , , ,

I queued this post last year when I was a Technical Lead for an outstanding scrum team at HealthEquity. The role was new for me here, although I’ve had leadership roles at several companies over the years.

A Little Background

Our team consisted of six people who had never worked together directly. We not only found a way to meet the requirements of the project, but we also did it on time, on budget, with little overtime, and quite a lot of team fun.

At any rate, the team was very successful, and its success was noticed. It resulted in considerable renown for the team. Credit where it is due: the team’s success belongs to the entire team. My role certainly wasn’t more significant than any other. If anything, it was less important.

I’ve been asked by several people how we did it. My answer, as always, is that we have an awesome team. As a contributing member, I shared some of the load. Maybe my philosophy as a tech lead within the team helped as well. I’d like to think so.

agileTeamsDontAlways

My Tech Lead Philosophy

Top Tier Things To Not Forget

  • Principle #1: Respect the opinions of everyone. We are all professionals.
  • Principle #2: Make other team members’ jobs easier.
  • Principle #3: A tech lead isn’t the only person who has great ideas.

Also Good To Remember

  • Patience. Patience. Patience. Patience. Patience. Patience.
  • Give guidance by asking questions. It isn’t always possible, but it usually is.
  • Free team members to focus on sprint work by being the first point of contact.
    • I choose to address this by sitting at the entrance to our team area.
  • Encourage team members to learn by taking tasks that challenge them.
  • Take sprint tasks that don’t interest other team members when possible.

Probably Best Not To Do This Stuff…

  • Dictating solutions and stifling creativity.
  • Taking all the fun tasks for yourself.
  • Interrupting people unnecessarily.
  • Wheaton’s Law: Don’t Be A (Jerk).

Obviously, I’m not perfect in any of these things. I do find that having the philosophy helps point me in the right direction. I hope it helps you as well. If you’d like to read more on this topic, I wrote a follow-up article in 2017 about Influence vs Authority on Agile Teams.

Interested in technical leadership and not sure where to start? Lead some coding katas for your team.

As always, hit me up on Twitter with questions or comments. Until next time.

Interview/Hire Great Devs: Part 2

Career, Leadership, Software Career, Software Development, Software Engineering, Team, Technology Career
This is the 2nd and last post on hiring great developers. You should probably read Interview/Hire Great Devs: Part 1 if this topic interests you.

Fulfilling Expectations

Remember that the type of person you want to hire is going to expect around 3-4 hours total in the hiring process. If they feel that you don’t perform due diligence with them, their concern will be that you are not doing it with anyone else and that the team will suffer. Of course if the candidate doesn’t seem like a good fit at any point, cut them loose immediately and politely.

If your candidate made it this far, it’s time for…

Phase 3: In-Person Interviewing

Let Your Experts Do The Talking

Evil Nerd Genius
And now we all know the truth about German programmers…
They code in cuff links.

Next, have candidates interview on-site with your existing people for one to two hours (if you don’t want the whole team in there at once divide the time into 20-30 minute blocks). There are pros and cons to both approaches.

Be sure to communicate any overarching goals with your team. If this person is to fill a specific role, let them know so they can analyze the fit. If everyone you hire should be a continuous learner, make that clear. If you want someone who won’t be bored with tedious work, that should also be communicated. There are only two technical guidelines to stress.

Just.

Two.

  1. Long coding assignments should not be performed on a whiteboard.
  2. Long coding assignments should not be performed on a whiteboard.

There are plenty of decent alternatives to making a developer sweat about syntax and handwriting. Bring a laptop to the interview and pair program with them. Send them a coding assignment to complete on their own prior to the interview (time-boxed of course). This applies to anything longer than a fizz buzz-type problem.

Otherwise, let your experts ask whatever questions they believe are important. They are evil geniuses who want to unleash hell on your candidates, AND THEY SHOULD.  These should be some of the people you trust the most to help achieve your goals as an organization, they know the right questions to ask!

Afterward, get a quick thumbs-up count from your team and if it went well…

Perform A Leadership Review

Do an in-person with anyone your team doesn’t dislike. Probably 30 minutes or less. See if your impressions from the online/phone screenings seem to hold up. If you are considering this person for a role that may increase in responsibility, make sure to ask the right questions (including if they are interested in that sort of thing).
At this point, assuming success, proceed to…

The Final Phase: In-Person Closing

Sell, Sell, Sell (Be Obvious And Honest)

Allow 30 minutes to answer their questions and really sell them on the opportunity.

Sale! 50 Percent Off

What you have to offer is great, remember that! This is the company you chose to work for and continue to stick with. Even you you are having a bad day (we are all entitled occasionally) do not sell the opportunity short. Talk about the best parts of your job. Be enthusiastic. After all…

“Nothing great was ever achieved without enthusiasm.”

– Ralph Waldo Emerson

Be completely open and honest. Don’t conceal problems but don’t highlight them as anything other than what they truly are: opportunities to improve. Developers are optimists. We believe in change for the better and want to help it happen. Appeal to our desire to solve problems.

Eat Lunch

The candidate that makes it this far should have a very informal lunch with the team he will be working with so everyone can get a feel for interpersonal relations… it’s very difficult to get a feel for someone who is expecting trick technical/personal questions at any point and is on foreign territory. Lunch offsite is neutral territory and you can learn a lot about a person in that environment.

Lunch is a good habit to get into anyway. I like it.

It goes without saying that if you get to this point then you most likely have a keeper.

Make An Offer

Do this after lunch or do it the following day. You should know if this is the right person for the job or not. You have all the information. If the answer is no, tell your candidate as soon as you know.

The Offering

Negotiation is to be expected. However, in today’s competitive market, get your best offer out on the table as soon as possible.

NEVER try to undercut a programmer/developer/engineer/etc. It will not end well for you. The candidate maybe offended and walk, or worse, join the company and go though all the training and ramping-up and leave for a better opportunity in 6 months.

There are many, many jobs and too many online resources available to compare salaries and other benefits. If you aren’t sure you are being realistic, check out your competition on Glassdoor or general rates on Salary.com. Take this data to the powers that be and make a change if needed.

If there are other great reasons to work for the company, things that give you a competitive edge, highlight them. If you have a great environment for learning (see my posts on the subject here, here, and here) tout it! If you’ve hired well-known or respected developers, point candidates to their online presence on Github, LinkedIn, and Stack Overflow for verification. If you have stock options, great healthcare, or free/discounted products, talk about them.

You get the idea.

Conclusion

Overall, this is pretty similar to the process one employer used when convincing me to move to halfway across the country (for minimal pay increase, no stock options, etc.) and I had plenty of other opportunities. The overall process is proven and is common with really good shops that care about hiring the right people. Remember to always end the process after any stage as quickly and succinctly as possible. Do not get a reputation for wasting people’s time.

Image credits:
minion
.
https://www.flickr.com/photos/liquidnight/