I have been working in technology for about 13 years, and software specifically for 10 and some change. According to this article, it’s all over, I’m done. According to the author, Jon Evans, people that have 10 years of experience are too set in their ways and probably can’t keep up with the pace of change in technology anymore.
Contrast that with this article by Dan Bricklin describing the team that created the IBM PC. Every person on the team had credentials in the form of sweat equity. They had spent time working and building important, or at lease useful projects, for years before the PC came to be.
So which is it? Does experience in technology help people create novel products, or is it something dragging teams down?
Does experience have value?
I came across a post on scrumalliance.org today describing an agile scorecard. The scorecard is a set of categories and criteria that a manager or lead might use to assess each person on a technical team after a sprint. The author suggests that this is good because it moves assessment from one or twice a year, to every few weeks.
This sounds good at a superficial level, team members that don’t get feedback often may not know that they could change something small to be a more useful person. But, the details of this scorecard are full of anti-patterns. Things that, to me, suggest organizational dysfunction and a complete misunderstanding of agile principles.
Here is a closer look.
So then the director walked by my desk, at 4:30PM on Friday, dropped off some data and said “I need a report on my desk Monday morning.” I can’t believe that guy!
Why did my friend do? He took the folder, wrote the report over the weekend, and turned it in on Monday.
Many of us behave that way. Do the work, get the executive to go away. We did the guy a favor. He’s cashed in his chips and we think that he owes us. At the very least, he’ll be off our back for awhile.
Except that things don’t work that way.
Next Friday, the same executive will be back with two reports. Do those, and he’ll be back with four. Here’s why. Continued »
Last month, I wrote a post about what I think is wrong with Agile. Or at least one aspect of what I think is wrong with agile, there are plenty to choose from. That post was very popular, so I want to do a little unpacking of the Agile suitcase and look at the practices most commonly used starting with the work visualization tool, kanban.
Kanban is one of the most popular processes tied in with agile, maybe second only to Scrum. The basic idea is that every unit of work is displayed in some system as a card that moves through columns that indicate what stage the work is in right now. Add a dash of breaking work down into deliverable pieces, and a pinch of limiting work in progress, and that’s kanban. Simple, but it gets screwed up more than it is optimized for value.
Why is that?
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.