I spend a lot of time at community events every year. At every event, without fail, people want to talk about tools. The development community in particular seems to have a sever case of tool fetishism. At the testing events I participate in, people usually want to know what the best tool for X is. X might be front end testing, back end work, ETL testing, security, or whatever. This is a hard question to answer. I will rarely have enough information about the product they are working on, what the teams skill set it, and what problems they are trying to solve to give a reasonable answer. That, and I don’t really believe in the concept of best, anyway.
I do think there is something close to good enough for us right now. I want to talk a little about how I pick development tools, and why I do it this way.
It looks like agile can not stand on its own anymore. There are scaling frameworks — SaFE, LeSS, DaD, SCARE — that are all designed to organize small teams in a way that people detached from the work (ahem, managers and directors) can understand. There are the post-agile phenomena like continuous delivery and the Grows method. And then there are the hoards of trainers and consultants each trying to teach technical teams their special brand of agile process.
So, what’s wrong with agile? In an Agile2016 interview, Ron Jeffries and Chet Hendrickson describe problems across the board — planning, implementation, and process. I have mostly seen people stumble over planning and process.
Last time I wrote about the Des Moines Agile Conference – a one-day event with four hundred people, with limited speakers who pitched their topics, four sessions, and a early close followed by lean coffee. In that post I covered three of the four sessions I attended. The fourth, with Jodi Jones and Kent McDonald, was titled “What Do Scrum Masters Really Do – and Do We Need Them?”
That seemed like a topic worth exploring.
I saw a retweet last week trying to make a statement about the definition of done. Jim made a good point, software is never really ‘done’. After new software has shipped to production, there might be bug fixes, or new additions to a feature or refactoring to hopefully improve that future somehow. Software is always in flux, so it might never be done. But, being technically right doesn’t really help people that are in the business of releasing software. We still have to deliver to customers.
Software being "Done" is like lawn being "Mowed".
— Jim Benson (@ourfounder) August 29, 2016
Most of the problems I have had with definitions of done come from agile and kanban. Or rather, people using those ideas to justify not changing anything in how they work.
Twenty years ago, if I wanted to learn about software, I could buy a book or pay to attend a handful of big conferences. Today, there are still large, for-profit conferences, but an increasing group of smaller, local events, that require no airfare, no hotel, and fewer days off work.
The smaller events might charge a hundred dollars for one day. They can be on a Saturday, or have no keynote speakers, break at 3:15PM to go to open space and open bar. Like, for example, Agile Des Moines.
That I happen to be at right now.
Let’s talk about how this is a different ball game. Continued »
I have been following a thread describing fraud in the Silicon Valley. A company called WrkRiot reportedly failed to pay employees for several weeks, and then later produced falsified pay stubs to convince employees that any slowness in payment was due to banking problems on the side of the employee. In a FaceBook post, WrkRiot claimed they were taking legal action against Penny Kim for slander. Today, that post seems to be deleted and the WrkRiot FaceBook page is inaccessible.
The software industry, and Silicon Valley specifically, are in a boom now and for the foreseeable future. The promise of free flowing cash from investors trying to hit their own jackpot has created a situation where people are willing to walk an ethically questionable line.
I have worked for a few startups in the last 5 years, and haven’t directly witnessed fraud, but I have seen some questionable behavior.
I was eavesdropping on a conversation about vetting technical skill during an interview in a local Slack channel last week. One person suggested live programming or logic exercises on a white board. Others responded that this is inhumane and rigged against people that need a quiet space without people hovering over their shoulders to respond to this type of challenge. Another person suggested a take home exercise that someone could complete over the course of a few days and email back for assessment during the interview. Yet another group of people said that this type of challenge only assesses privilege. They claim person that has disposable time and resources to complete an at home programming challenge has an unfair advantage over the person that works full time, has a family at home, and has little disposable income to build a good development environment at home.
All of these perspectives have a little truth in them of course. But, we still need some way to understand what the technical skill of a candidate is. I have interviewed a few people over the years and have learned a few lessons along the way.
You might remember some of the product announcement keynotes that Steve Jobs delivered at the end of his career. Just as you thought the presentation was over, Steve would say “oh, and just one more thing”, and introduce product, like the iPod, iPad, or iPhone. Each of these took a technology that already existed but cumbersome and made it available for the masses. He presented the idea as a new category of device – and held his ground.
Steve began by introducing each device with a tag line, such as “a thousand songs … and it goes right in my pocket.”
He would also make and project his own judgements about the product – that it was “amazing”, “wonderful”, “beautiful” and magical. Journalists would copy those words without thinking, and the readers of those articles would assume they were the judgements of the journalists, not just a repeat of what Jobs said. The techniques Steve used have even be parodied by sites like college humor.
Steve projected a reality where the products were the best thing ever.
You may have watched some of those videos, thought you “had” to have the product and realized, six or eight months later, that hey … it’s just a tablet. It’s pretty, and has some cool games, and it might be easy to carry and combine multiple features, but it’s a tablet. Buying it did not make us better humans.
As of this morning, a google search for “Steve Jobs” “Reality Distortion Field” yields over forty-seven thousand results.
I attended and spoke at the first run of Music City Agile last Wednesday. Music City Agile is a one day conference themed around, your guessed it, agile software development. A sister conference, Music City Code ran the following Thursday, Friday and Saturday. Jim Benson ran the opening keynote on Post-Agile Stress Disorder (PAST). Jim presented what seems to be a more common theme: consultants arrive at a new gig and present a set of tools and process that will fix every problem. Once that consultant leaves, the tools stick and the process mostly washes away. New consultants arrive at a regular pace and present their preferred tools and process. This happens over and over again.
All in all this was a very well run conference. I’d like to talk through a little of my experience with what Jim described in his keynote.
That is, the technical staff feel they are not heard, but when we get down to talking, they often don’t know how to ask.
Today I’d like to talk about assertive communication, and how different it is from passive, using When I Say No I Feel Guilty as a sort of field-guide.