agile | Geek 2 Man

January 23, 2019January 23, 2019

Schrödinger’s Engineering Team

Hopefully, you’re already familiar with the thought experiment of Schrödinger’s Cat. The concept of a cat both simultaneously alive and dead, existing in a dual state until observed, is one of Quantum Physics’ greatest visualizations.

Alas, a poorly informed engineering team can also exist in a dual state. However, unlike the hypothetical cat, they have a greater tendency to collapse and loose all productivity rather than being able to both work and not work at the same time.

I was recently in a situation where my team was asked to complete a set of tasks for a core piece of functionality in our new product. Midway through the sprint, word came from upper management (via our Scrum Master) that they were looking into third-party vendors to perform this exact same piece of functionality. Better still, even with this new information, Product did not terminate the sprint, and we were required to continue on what could very well now be a useless task.

At that moment, we became Schrödinger’s Engineering Team. Our Sprint suddenly existed in a dual state in which our tasks would be completed and provide value to the organization as well as all the work would still need to be completed and yet be absolutely useless to the organization. Talk about a morale killer!

Information is always important, but adding direction to the information is just as important when giving it to an engineering team mid-sprint. If the information would change the direction of the current sprint then Business needs to consider also prematurely ending the sprint. While terminating the sprint may be a little frustrating to the team, it certainly won’t have near the long term morale issues that continuing forward in a dual state will have. That doesn’t mean you should hold on to the information until the end of the sprint though. Doing that will merely aggravate the team, drop their morale, and cause them to trust you even less. On top of that, you’re also wasting the organization’s time and budget by continuing the sprint with what could potentially be useless deliverables. It’s better to cancel the sprint and regroup than to deliver unneeded or unusable product.

So how do we avoid creating Schrödinger’s Engineering Team? Just like Quantum particles, we need to observe the team. We also need to observe the information we give to the team, in particular with how it relates to the in-flight sprint. Then make a decision, with the team’s help if necessary, based off of the observation of the information. Don’t just leave them in a dual state limbo.

October 12, 2018October 12, 2018

The Feedback Loop – How Agile is your Hiring Process?

We are agile in our development processes, especially in terms of striving towards continuous feedback. Why do we not allow for this same feedback loop to occur with interviews as well?

One of the key tenants of agile development is the idea of continuous feedback. The faster we learn where we deviate from the request the sooner we can correct course. And usually, the earlier we correct course means there is less effort required to do so. I don’t really need to continue on about the dev cycle here, do I?

Here’s the catch though: We don’t do this feedback loop often enough with each other as individuals.

Let’s skip the discussion over performance reviews for now. Depending on how often they are scheduled (quarterly, annual, only when things go wrong?) and how they are formatted, they qualify at some level as a feedback loop.

The key item here is that there is no standard or expected feedback loop in the interview process. It’s the rare manager and interview process that will give feedback to the candidate.

Let’s say you have three interviews, all for the same level position, and all three companies have the same interview style and code challenge types. After your interviews with Company A, you find out that you are no longer in the running. No big deal, right? You still have two more to go. Next thing you know, Company B rejects you. Both times it was right after the code challenge. Did you make the same mistakes on moth challenges? After all, they were both about creating a basic blog service from scratch. With a little feedback, even general commentary, you might have had the chance to study up and not make the same mistake the second time. Now you’re on your third try, and guess what, it’s that blog service again…

Had the earlier companies given feedback, you would know where your weaknesses were. It still may not help you get the next job, but it would at least give you the opportunity to improve your skills in areas others think you are lacking.

For example, if company A came back and told you your skills were great, but they didn’t like your attitude, you’d know to take a deep breath and be more personable and down to earth the next time. If company B told you they didn’t like how you named your variables in the code it may not help you much, but if they told you that you made too many database queries for the same data points you’d know that maybe you should look into how to better use the Objects you had built. You get the idea. A little feedback can go a long way sometimes…

There’s also the personal part here. Too often we treat our candidates as mere numbers. Did their resume check all the boxes of things we’re looking for? Did they show up for the interview on time? Are they local? Is there anything else we can use to weed them out because we have so many candidates and feel overwhelmed?

I know it’s overwhelming at times as the hiring manager to have so many resumes and candidates to sift through. It’s just easier to reject and move on, right?

Maybe.

But if you’re a company that prides itself on relationships with its customers and how great and communicative your culture is in the office, why wouldn’t you extend that communication and personal touch with all the candidates you interview and reject? If you can point to specific items, do so. If not, there’s nothing wrong with a “sorry, but another candidate was even more qualified than you.” At least the feedback loop has occurred and the candidate can move on.

As a hiring manager I do everything I can to make my candidates feel comfortable, and then to let those that were not selected know as soon as they are out of the running with a reason why. It’s not always in depth, but if they fail the code challenge, they get a general idea of what went wrong. If they’re not experienced enough after a discussion, I let them know. If the job requirements change mid-stream I let them know that too (Hey sorry, it’s not you, it’s us).

Agile isn’t just a development cycle or a catchy buzzword. It’s a mindset. I’ve been on both sides of that hiring desk, and the companies and candidates who have the Agile mindset always come out on top.

June 7, 2018

Swarming

This morning there was a large amount of bird chirping outside. When I looked out the window there were about a dozen sparrows, and mockingbirds chasing a hawk. They were swarming and chirping all over the place and working together they chased that hawk out of the area. They teamed up to defeat an unexpected problem that came out of nowhere which was bigger than they were.

When you stop and think about it, it’s no different when a critical production issue or overly difficult problem appears in front of a an engineering team. The problem is identified, the team drops everything they are currently working on, and they “swarm” the problem until it is eradicated. During the swarm some people may drop off the problem when their skills are no longer required and other may get pulled in as the team determines the next steps they need to complete the problem. Ultimately, think of swarming as Pair Programming on steroids.

As a manager or team lead you need to recognize when swarming could be a help, as it does take resources away from day to day work. Honestly, I think it’s usually pretty obvious when swarming is needed, and it doesn’t hurt that the team will usually say so. Swarms don’t often affect the outcome of the Sprint as the swarm has a force multiplying effect which gets things done faster, however it’s always wise to communicate to the stakeholders that a swarm is happening and when the possible risks may be to the Sprint. Regardless, if the team comes to you asking to swarm on a problem, let them, they know what they’re doing.

Swarming is a highly effective way for a team to accomplish a large task quickly. Even a bird brain can see that.

April 25, 2018

The Rocket Fuel of a Project – Good Acceptance Criteria

I had a manager once who would constantly harp on both the product team for not writing stories with good acceptance criteria and on the engineering team for accepting these “poorly written” stories. He would claim that his engineering team was the engine, and it would only perform as good as the fuel you gave it.

Better fuel makes things perform better, whether it’s high octane gas for your car or great acceptance criteria for your engineering team

If you’re familiar with Agile, then you’ve probably had the general story format of “As a [USER] I should be able to [DO SOMETHING] so that I can [ACCOMPLISH SOMETHING].” beaten in to you. It’s a great concept, and as a Scrum Master, I can say that it does work. Of course, you don’t have to take my word for it (even though I hope you will). Mike Cohn of Mountain Goat Software, one of the authorities on Agile and Scrum discusses the advantages of the As a User, I want User Story Template.

Here’s the one problem I have with using that format: Engineers get their hands on it. They bastardize it. They take it to be gospel. They use it to not have to think.

I’ve had engineers who would write system level stories with things like “As a System, the System should have Logging, so that the Developer has something to look at with things go wrong.” Gee, that’s nice. What are you trying to log? How will you access the logs? (which should really be another story quite honestly…) What sort of things do you mean by “go wrong?” And of course, my favorite bit, “As a System, the System should…” Is the web server actually sentient and have a concept of self? (Try and bend the process and I’ll pick anything and everything apart…)

Then there’s the individuals who just don’t want to follow the format. “Why?” they whine. “What’s wrong with just attaching a picture of the white board from the meeting we were all just in to the story? The devs who will build it are in there.” You should definitely add the picture. It’s an artifact to the process. But don’t rely on it! Weeks could pass before the team gets to that particular story. A crucial team member could get hit by a bus or win the lottery. You need context to the story.

I’ve seen issues even following the format to the letter. This arises from the statement being too vague and the product owner expecting more than they wrote. The engineers take those vague statements as gospel, and then hide behind it as the story doesn’t pass, or ends up having three more stories written to clarify the original work. They use it as a crutch to not have to think about more than what was written and potentially not deliver greater value. I once saw a story rejected because the statement was “As a User, I want to be able to log in and see what I have permission to see.” A little vague, but tolerable. The story was failed because of a different issue; the product owner didn’t like the error messages displayed if it was a failed login attempt. Funny, I didn’t see anything in the sentence regarding failed login attempts… You know what would have alleviated this issue? Acceptance Criteria.

By explicitly stating after the “As a User…” statement what the expected results would be this could have been avoided. Acceptance Criteria for the above log in story could be as follows:

The user will be able to enter their user ID (email) and password and select the button labelled “Login” to log in to the system.
If the user enters an incorrect ID and password combination they will be presented with the login screen and an error message above the fields stating “You have entered an invalid ID or password.”
When the use successfully logs in they should see content appropriate to their User Roles:
- Standard users will see their dashboard with content they have subscribed to defaulting to the last 30 days ordered from newest to oldest
- Staff will see the internal dashboard
- Admins will see the internal dashboard augmented with extra tabs for user account management and subscription payment management

So how do you write good acceptance criteria?

Think of acceptance criteria as a helping guide for how you or someone else would test this work. No amount of detail should be spared on your road map of how to verify the story. In some cases it could be as detailed as an AAA TripTik (If you ever had a paper one made for you, you’ll know what I mean). It often helps to draw out a flow chart or build out a spreadsheet of desired actions and possible outcomes. For the login example, the spreadsheet might look something like this:

Login Acceptance Criteria Example

Page	URL	Action	Expected Result	Data Needed
Login Page	/login	Login as a standard user	Standard users will see their dashboard with content they have subscribed to defaulting to the last 30 days ordered from newest to oldest	User: standard@sample.com Password: password
Login Page	/login	Login in as a staff user	Staff will see the internal dashboard	User: staff@sample.com Password: password
Login Page	/login	Login as a system admin	Admins will see the internal dashboard augmented with extra tabs for user account management and subscription payment management	User: admin@sample.com Password: password
Login Page	/login	Attempt to log in as an invalid user	User is redirected to the login screen and is given an error message above the fields stating “You have entered an invalid ID or password.”	User: baduser@sample.com Password: badpassword

While this will often fall to a designated QA individual or team, not every organization is set up to have a dedicated QA group. Regardless of if you have QA available to you or not, be sure to write the acceptance criteria with enough detail that anyone in your organization could follow the steps. It will help with testing, and it will help with development. If you do have QA available, engage them to help you write Acceptance Criteria that will help all of you. They’ll have plenty of tips to give.

So back to the fuel… You can give your engineers basic requirements, or you can give requirements and acceptance criteria. One will act like 87 octane in a Corvette; you’ll get there, but there will probably be some sputtering and a few issues down the road. The other is going to be like putting in 93 octane in that same Corvette; it’s going to purr and give you much better performance in the end.

March 23, 2018

Hot Cross Buns as Acceptance Criteria

You’re probably thinking to yourself right now, “Great, he’s about to give us another recipe example for breaking down tasks and achieving the desired acceptance criteria.” Well, stop that. The food is merely a vehicle for this post.

First, a little background: I’m currently on a business trip, and as my hotel room has a kitchenette I did a little shopping at the grocery store; a Publix to be precise. Why Publix you ask? Well, we don’t have those in our neck of the woods, so it’s something different for me. After all, I can go to Kroger’s any time I want. Back home, all the neighbors have been asking my wife where I’m travelling and what I’m doing (they do the same to me when she travels for work). During the course of one of these conversations a neighbor brings up that there’s no good store-bought hot cross buns where we live, and that the best ones he’s ever had were from Publix. After all this, my wife texts me:

Publix Market has the best hot cross buns… Do I need to bring some home? You’d make [our neighbor] happy. I’ll head there tonight for some. LOL

Now, stop and read that again. This time, read it as a product owner and an engineer. The hot cross buns here are almost a feature request, but not quite. It could be a preliminary fact-finding discussion to see how feasible it was to achieve an objective; getting hot cross buns. Or maybe it’s just a discussion over some cool feature that was seen elsewhere that the product owner just wanted to share. Usually it’s something like “checkout this cool slide show transition.” This time it’s just a statement of where to get the best hot cross buns.

It just so happens that I’m in a position to find and obtain these incredible edibles. Being the engineer that I am I immediately see this as a problem that needs solving, and offer a solution: I’ll get some and bring them home from the trip. It’s not so different from, “You like that slide show transition? Let me see if I can slide that in to the sprint for you. Don’t worry about a ticket…” Nowhere in the text conversation did my product owner ask for hot cross buns. We had a phone conversation afterwards, and the conversation continued, and I said that I would stop and get a box. I figured I’d pick them up after dinner on my way back to the hotel. Note: my product owner neither confirmed nor negated this suggestion. In fact, I think she may have been working on another project.

Off I go to dinner (I’m starting work on the slide show, and said that I’d add the undocumented, un-asked-for transition). The restaurant I went to (recommended by coworkers) had an hour wait, and being the hungry engineer that I was I passed and went next door since it had empty tables. Of course, with my engineer’s luck, it was a bakery. And wouldn’t you know, they had hot cross buns… Now, these aren’t the ones that would satisfy my acceptance criteria. They’re not Publix hot cross buns. But, being the engineer who always wants to please, and always wants to deliver more, I eye those hot cross buns. Of course, I still want to do the right thing, so what do I do, I contact a product owner. I text the neighbor. Not the product owner I had the initial discussion with, but now a totally different one! I chose to ask a different product owner on my own, not because the original product owner was unavailable or had passed me off to a new one – or was out of the office and designated a replacement. Now I’ve made promises to two different product owners (my wife and neighbor), for two different acceptance criteria (Publix and bakery hot cross buns), and still no official request within my sprint (dinner time/business trip). But I’m the engineer, I’m supposed to say how things get implemented, whereas the product owner gets to tell me what gets implemented. I decide to treat the purchase of the baked goods as a how, not the baked goods themselves being the what, and I buy some from the bakery. Better still, I don’t buy just one, but three boxes of hot cross buns. After all, if I were programming those transitions, then three unasked for transitions and some other features would be better and make my product owner happier than the one discussed, but still unasked for transition I offered to do. Right?

Guess what? My product owner wasn’t very happy when I told her what I had done. Where my engineer mind thought I was going above and beyond, in reality I was adding my own scope creep, wasting time and money on something that wasn’t asked for. If this was development, I would have put my sprint and deliverables in jeopardy, and wasted the company’s money on my salary for doing things I wasn’t tasked to do. I still put my deliverable in jeopardy, as these aren’t Publix hot cross buns, but fresh bakery ones, which won’t last nearly as long.

Plus, since the Hot Cross Buns were not in the original sprint plan (business trip), I have circumvented a process that is in place for a reason. Remember that as a developer, the process is there to protect you too, but if you start agreeing to do things outside the process and without documentation, you could find yourself in a lot more trouble than you initially bargained for. Plus, there’s always the “but you did it for me with the Hot Cross Buns…. Why can’t you do it for me with the Coffee?” argument that the product owner can make. Or the you did it for product owner 1, but you won’t do it for me…. argument (which could get you into all sorts of HR issues.)

So the next time you want to do a favor for your product owner, make sure to agree to what is being requested, then prioritize the work, and document it. Don’t go assuming that they want something just because of a conversation or email. Don’t go involving other/different product owners with your questions because you’ll only get conflicting marching orders, and acceptance criteria. If you think there’s a better way of doing something, discuss it with the original product owner, as there may be a reason they are specifically asking for something, and there’s no need to add in all the extra work you’re considering. Instead make suggestions on how to improve upon their improvement. And finally – Just remember the hot cross buns, and your product owner won’t get cross with you when you deliver.

As for all those hot cross buns? It looks like I have a lot more breakfast items than I had planned for…

March 14, 2018

What is Digital Transformation?

One term I’ve seen recently is Digital Transformation. The first time I encountered the term the first thing I thought of was small businesses integrating more software and processes in to their brick and mortar presences. I know one shop that still hand-writes their sales tickets, and adding some technology to their shop and processes would be a perfect transformation. That’s close, but not quite right.

Digital Transformation has been around for decades, each time infusing organizations with more technology, more processes, more ways to potentially deliver faster. However, with each new infusion comes new challenges. Challenges which are not necessarily related to the technology itself, but how the organization handles it. You see, as wonderful as new technology is, without changing the processes you manage, all you’re doing is the same thing, but faster. That’s great, but eventually you have to change your processes and even your organization to continue to succeed. If you’re in the music business, it doesn’t matter how much faster you can produce CDs if you haven’t leveraged your technologies to deliver digitally as well as change your overall strategy to make digital delivery your main product with CDs being secondary. I know I’m over generalizing here with the music industry, but bear with me…

This isn’t about products, or even specific technologies. What Digital Transformation is about is organizational cultures and how well they are able to adapt and change. It is about how easily can they take the technology they have, or are about to implement, and deliver faster that their competitors. Remember my music example? Which organization can take their technology (digitized music) and deliver it faster to the consumer? The organization that uses digital files to produce CDs for distribution (because that’s what we’ve always done) or the organization that offers the same digital music files for immediate download and consumption? Obviously the one who offers it for immediate consumption will succeed in getting the immediate advantage over their competitor.

Technology changing how organizations do business is what Digital Transformation is about. It changes the expectations of the organization, it’s partners, and ultimately the customers.

Don’t expect this to happen overnight. It takes small steps, with each department buying in to the change, for the transformation to succeed. You can’t just hire in a new executive and expect to be transformed. They can help, but without the rest of the organization’s willingness to change the only thing that will happen is a large investment in new technologies to do the exact same thing that you’ve been doing. The entire organization needs to be ready to adapt, and the processes need to reflect that. As the culture changes, so does the organization, ultimately leading to greater value to the customer.

Digital Transformation is the ability for your organization to adapt and change using the technology available to you.

Tag: agile