My co-blogger, Matt Heusser, wrote last week about his take on the service and gig economy. His post centered around how people using their own belongings, mostly houses, computers and cars, could make some extra money each month without the trappings of full-time employment. The gig economy creates virtual business ownership.
I think the gig economy is a trap, a ghetto. People working these gigs take erratic hours for low wages and don’t even have access to those wages without expensive barriers to entry. Instead of creating more wealth, the service economy creates share-croppers.
Let me explain.
Remember in A Christmas Story, when Ralfie needed some privacy to decode the radio message? The bathroom was his only option; Ralfie shared the second bedroom with his brother, and the family had just one car.
Have you noticed that doesn’t happen any more?
The typical house size in the United States has increased by a thousand feet since 1973, which is presumably larger than it was in 1940 for the Christmas Story. Meanwhile the average family size shrunk from 3.67 to 2.67, and the number of vehicles per household is up from 1.16 in 1969 to 1.89 in 2001.
In other words, there are less people with more automobiles in bigger houses. Continued »
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.