If you’re in tech and you’ve visited social media or read any news sites in the past week, you’ve probably familiarized yourself with a certain sad and lonely manifesto that’s been making the rounds. (If you’re a woman in tech and you’ve somehow avoided reading it thus far, it’s probably a good idea to continue skipping it; nary a new idea to be found.) Continue reading Caught Unaware
Want to know if your team understands something? Ask them to give you the elevator pitch. If they can’t summarize the objectives and high-level milestones in a few quick sentences, it’s unlikely that they understand it very well.
Take a step back, can you give an elevator pitch? If not, take the time to make sure that you truly have a grasp on the plan, then take that newfound proficiency to get your team on board as well.
You’ll be surprised at how much traction simply having a firmer grasp on the subject will help your team gain!
The lede of an interview in which I was recently featured ended up being the notion of not being precious with your ideas—as a result, that concept has been the topic of conversation quite a bit over the last few weeks. As often happens, the most common question to arise also happened to be the most obvious one:
How do you avoid being precious with your ideas?
This is a placeholder for an article about me that was posted on a different site. If you want to read the article, you’ll have to click through! Please try to ignore the ginormous picture of me at the top. Please try to ignore the use of the word “Pro” in the title. Creative liberties were taken!
Unlike being a lawyer or a doctor, IT has a number of entry points. Some go to school. Some convert their passion from childhood into a career. And some, like software professional Jer Lance, initially get their training and expertise through military service. We spoke with Lance about his roles spanning education, management and software development and what he’s learned over that time.
Q: How did you start your career? And how important do you think education and certifications were for you?
Wells Fargo has had to fire over 5,000 employees as it was found that they were making fake accounts on behalf of customers—these terminations took place over the course of a few years, so this has been going on for some time. More recently, however, the bank ended their program of incentives to cross-sell accounts to customers.
To recap: a company started to measure how often its employees were able to cross-sell accounts, applied incentives to that measure, and the employees dialed up their cross-sells to the point of actual fraud.
This is unsurprising, you get exactly what you measure—no more, no less.
I’ve seen this often in software delivery: companies claim to value quality, but what do they measure? Lines of code, features completed, project milestones, deadlines. What do you get in return for that measurement? You get tremendous amounts of low-quality work delivered on time and within budget—then you spend extraordinary amounts of time and money fixing all of the terrible, broken software you’ve created.
A past employer expressed tremendous amounts of frustration with exactly that problem when they brought me onto the team; their projects would be completed reliably on time or very close, but would often be delivered 100% or more late (and with tremendously reduced profit) because of the enormity of the repair tasks.
If you want to receive quality, that is what you have to measure. There are numerous ways to do so; incentivizing first-time delivery quality with zero-defect feature bonuses, tracking defect counts against feature complexity for a team, and turning off incentives for milestones in favor of incentives for active status communication are just a few that I have used with great success.
In the aforementioned company, I lobbied for and eventually succeeded in eliminating milestone measurement on the delivery side of the organization in favor of quality metrics similar to those above, and both profit and timeliness skyrocketed…but what rose the most was customer satisfaction. Suddenly, clients enjoyed our process and software, which was really my goal all along.
Remember that you will always get what you measure, but you will get the letter of it, not the spirit of it. Act accordingly.
One of the lessons that I find to be simultaneously essential to learn and incredibly difficult to teach is an idea that I refer to by the shorthand “being a consultant”–the notion of saving the customer from themselves.
Paul Sherman’s amazing presentation “The UX Unicorn is Dead” (if you haven’t read it, stop reading this and go read that) highlights an excellent opportunity to save the customer from themselves: customers asking to forgo UX or QA work (or, in some horrifying instances UX and QA work) in exchange for a lower price or faster timeline.
You get what you pay for.
“When will it be released?”
In the pantheon of my least favorite software questions, this ranks near the top.
“When it is done.”
This response has to rank near the top of management’s least favorite answers.
I’ve written and spoken on the subject of managing customers fairly extensively because I feel that it is often done incorrectly—no, not just incorrectly, but extraordinarily incorrectly, cartoonishly so. In my experience, most customer management is done from a place of complete fear. How do we avoid losing the customer, how do we avoid offending the customer, how do we avoid failing the customer.
So defensive. So reactive. So rooted in negative emotion.
Consider your brain to be like a Git repository, constantly changing and updating and checking in new information. Everybody who has maintained a Git repo for any length of time is all too familiar with the amount of technical debt that is accrued through open branches. The more branches you have open and the longer you have branches open, the greater the likelihood that merge conflicts, hidden bugs, and other evils lurk in your future code. Continue reading Decisiveness and Decision Debt
No child learned to ride a bike by reading books about it, nor by rigorously documenting all of the steps that will be required in order to do it, planning those steps, then executing those steps. Children learn to ride a bike by experimentation and incremental improvement; they learn by taking minor risks fearlessly until they pay off. Continue reading We Were Born Agile
It takes a considerable amount of bravery to be in the process of moving an organization from waterfall to agile and to ask questions at most agile meetups and conferences. Nowhere in the universe are you more likely to be told that everything you do, everything you think, everything you are is simply wrong. This is one of my biggest pet peeves. Continue reading Moving to Agile: Doing it Right
I haven’t really had the mental energy to write much about our transition to agile for the last month or two because I have been spending so much of that time period putting together and executing trainings. Even with as much enthusiasm as I have for this, it has been a draining several weeks.
The human urge to generate complexity when something seems too simple makes teaching simple things a weird chore. When I walk someone through the thought process behind answering a specific Scrum question, it’s often perceived as too simple—I get wary looks from the audience as if I’m trying to trick them. There is no trick, it’s really that simple. Continue reading Moving to Agile: Training
This post is the third in a series that began here.
It did not take very long for one of our projects to see its first curveball. As our client fell behind on providing information that was necessary for us to progress, we were in danger of running out of work. In our traditional waterfall model, that meant that we were stuck in a common position of having to pull the dev team off the project and delay the progress of the project—pushing the project day-for-day until we have what we need to move forward.
I must admit, it didn’t even occur to me to handle this a different way until someone said in jest, “shouldn’t this magical new process fix this?” Continue reading Moving to Agile: Adjusting to Change
Over the course of the last 3 months, I have been coaching my team through a transition to scrum development. This hasn’t been simply an exercise in trying something new for the sake of something new; this move has been an attempt to alleviate the problems caused by years of technical debt and unsustainable work practices that have resulted in significant points of pain for our organization. While I would certainly like to get into the why (and that will almost certainly be a topic for a different post), I’d like to focus on some of the details as to how we have chosen to execute the transition. Continue reading Moving to Agile: Strategy
An interesting observation as I work with several teams to migrate a very waterfall process to Scrum: it is ridiculously easy to let the tools and the ceremonies become pro forma exercises rather than thoughtful representations of the spirit of what we’re doing.
I think that the biggest value I add as a coach has been to remind entire teams—regularly—to focus on the spirit of the manifesto rather than following the “rules” for using the tools or ceremonies. The tools do not define our process, the tools are there to facilitate our process. Something to remember.