I finished the second suggested reading from work. It was The Toyota Way by Jeffrey K. Liker. This is the second book I got from a former VP at work, after Scaling Lean & Agile Development.
It was a pretty good book. As advertised on the cover there are 14 Toyota Way principles. The author describes all fourteen. The author knows his stuff and demonstrates several of the Toyota principles in writing the book such as "go see", and "towering technical knowledge".
It comes in at around 300 pages. With 14 principles to cover in detail it was lot of ground to cover. The first 100 pages were pretty good. The next 150 or so dragged a bit and it seemed a bit repetitive and hard to follow all of these specific Japanese terms getting through all 14 principles. The author finishes pretty strong in the last 50 pages.
All in all it was a good book. For the first half or so I struggled a bit to see the linkage between automobile design and factory assembly, and software development. However on thinking about it some more I think I may finally be grasping what that executive may have been getting at when he commissioned a copy of these two books for his entire organization.
I'm starting to finally see the linkage between software development and physical manufacturing/assembly processes. There's a lot to be gained in software development by applying ideas from Toyota and modern manufacturing such as lean, low inventory, levelling, value streams, tracing and counting the number of "steps" from idea to production code in the field, one piece flow, finding and eliminating queuing and other waste.
I've got some more to say about it and I'm pulling some thoughts together and I'll have some more to post on it coming up.
Friday, August 23, 2013
Wednesday, April 03, 2013
coffee and a smoke
At work there's a new tenant in our building. Originally the site was built and fully occupied by my company. It's a five storey building. After several rounds of restructuring and such a decision was made to seek tenants to rent out some of the space.
It took a few months but IBM has now moved in and taken over the 5th floor entirely. Welcome IBM! We've seen them around the elevators and 1st floor cafeteria a bit. They seem like decent blokes. There were a few stragglers up on 5 and they were just absorbed into the lower floors a few months ago. There's still a good amount of space so it wasn't disruptive in my area.
Someone mentioned to me last week that the Halifax site is the only IBM facility in the world with free coffee. Apparently that is a global IBM policy. This is because the cafeteria has free coffee from the existing contract with my company. Don't be upset IBMers worldwide, the free coffee is awful, sludge, pretty much undrinkable. It's free and you get what you pay for.
Still something occurred to me and IBM may have already done this. What they could do is set up a jar on their floor and anytime someone gets a free coffee downstairs they have to put say 25 cents or whatever into the jar. Every few months or so the jar is counted up and donated to some local charity. This would then respect the spirit of the no free coffee rule while being a feel good initiative for the employees.
There was another change in the wake of IBM's arrival. The outside smoking area has been restored. There was an original smoking area about 100 feet outside the side doors. One day a couple of years ago or so HR announced that worldwide all staff smoking areas were ended and the employees had to go off-campus to smoke. But now with shared space IBM cares more about the tiny percentage of employees who are smokers and requires them to be accommodated on site. So the designated smoking area is back.
I'm glad the smoking area is back. I don't smoke myself so it might seem irrelevant to me one way or the other. I was concerned about the safety and security of my coworkers while at work. After all let's consider the unintended consequences of the HR decision to kick the smokers off campus.
Well first of all by going off campus they immediately lose the protection of the corporate security guard patrols. By definition security's realm is limited to the campus grounds. When employees step off campus they are on their own and thus exposed.
The other major issue with off campus smoking is that they were moved out of sight from the cubicles. With the on site smoking area we can see them from where we sit. Thus if there's some disturbance or security problem we can raise security from our desks or rush outside ourselves. With offsite smoking a bad actor can easily walk up to the smokers unseen from the building and create trouble. Again the smokers are exposed to additional risk.
So I'm glad IBM put the safety and security of their employees ahead of the agenda of certain anti-smoking busybodies in HR.
It took a few months but IBM has now moved in and taken over the 5th floor entirely. Welcome IBM! We've seen them around the elevators and 1st floor cafeteria a bit. They seem like decent blokes. There were a few stragglers up on 5 and they were just absorbed into the lower floors a few months ago. There's still a good amount of space so it wasn't disruptive in my area.
Someone mentioned to me last week that the Halifax site is the only IBM facility in the world with free coffee. Apparently that is a global IBM policy. This is because the cafeteria has free coffee from the existing contract with my company. Don't be upset IBMers worldwide, the free coffee is awful, sludge, pretty much undrinkable. It's free and you get what you pay for.
Still something occurred to me and IBM may have already done this. What they could do is set up a jar on their floor and anytime someone gets a free coffee downstairs they have to put say 25 cents or whatever into the jar. Every few months or so the jar is counted up and donated to some local charity. This would then respect the spirit of the no free coffee rule while being a feel good initiative for the employees.
There was another change in the wake of IBM's arrival. The outside smoking area has been restored. There was an original smoking area about 100 feet outside the side doors. One day a couple of years ago or so HR announced that worldwide all staff smoking areas were ended and the employees had to go off-campus to smoke. But now with shared space IBM cares more about the tiny percentage of employees who are smokers and requires them to be accommodated on site. So the designated smoking area is back.
I'm glad the smoking area is back. I don't smoke myself so it might seem irrelevant to me one way or the other. I was concerned about the safety and security of my coworkers while at work. After all let's consider the unintended consequences of the HR decision to kick the smokers off campus.
Well first of all by going off campus they immediately lose the protection of the corporate security guard patrols. By definition security's realm is limited to the campus grounds. When employees step off campus they are on their own and thus exposed.
The other major issue with off campus smoking is that they were moved out of sight from the cubicles. With the on site smoking area we can see them from where we sit. Thus if there's some disturbance or security problem we can raise security from our desks or rush outside ourselves. With offsite smoking a bad actor can easily walk up to the smokers unseen from the building and create trouble. Again the smokers are exposed to additional risk.
So I'm glad IBM put the safety and security of their employees ahead of the agenda of certain anti-smoking busybodies in HR.
Tuesday, April 02, 2013
don't have time
Once in a while something will come up. Perhaps a code review you need someone to do, or something like that. Now sometimes you'll find there's a snag that the person doesn't have time for it.
So I got thinking about that a bit "I don't have time". First of all the statement is obviously false. You have plenty of time. There's eight full hours available each working day and the task would take less than one hour. What the person is really saying is "I don't have priority" - this isn't important enough to bump some other task.
It might seem unimportant to make this distinction, but it is valuable to describe the situation accurately. Because by describing the problem properly then it can be a start toward some resolution. After all saying "don't have time" is absolute, final, intractable, unrecoverable. After all it's not possible to create time.
Now "don't have priority" is much more manageable. For example it could be possible to de-prioritize some other task. But more likely it allows an honest conversation. If your task isn't important to the other person, then great. Eliminate the dependency, get someone else to do the code review or whatever, and move on. Accept that roles have changed and someone has bigger fish to fry now. Realize that an error in your area is less catastrophic than an error in some other area, thus we assume the lower risk to focus resources on more critical things. In any case by breaking the dependency on your priority isn't my priority it allows everyone to move ahead.
So I got thinking about that a bit "I don't have time". First of all the statement is obviously false. You have plenty of time. There's eight full hours available each working day and the task would take less than one hour. What the person is really saying is "I don't have priority" - this isn't important enough to bump some other task.
It might seem unimportant to make this distinction, but it is valuable to describe the situation accurately. Because by describing the problem properly then it can be a start toward some resolution. After all saying "don't have time" is absolute, final, intractable, unrecoverable. After all it's not possible to create time.
Now "don't have priority" is much more manageable. For example it could be possible to de-prioritize some other task. But more likely it allows an honest conversation. If your task isn't important to the other person, then great. Eliminate the dependency, get someone else to do the code review or whatever, and move on. Accept that roles have changed and someone has bigger fish to fry now. Realize that an error in your area is less catastrophic than an error in some other area, thus we assume the lower risk to focus resources on more critical things. In any case by breaking the dependency on your priority isn't my priority it allows everyone to move ahead.
Monday, April 01, 2013
interviewing again
I attended an interview a little while back. No I'm not seeking new opportunities. I'm getting settled in with a new, better team since January and things are going pretty well so far.
The team is looking to add a new person to backfill for turnover. A candidate got through the first interviews with HR and the team lead. The TL asked the developers to do the next interview. It was a good interview I thought. The candidate was pretty solid and I thought he came across pretty well. Myself and the other developers had some probing questions. After the interview the team lead escorted the candidate out and we had a quick meeting to give the instant feedback and offer a thumbs up or thumbs down hiring recommendation.
It's a good experience to be on the other side of the desk. I didn't think I'd get to do any more interviews. In the first couple of years with the company I did a number of interviews for everything from co-op student through to team lead. I enjoyed doing them and I believe I was good at it. Then one day HR announced that in order to do interviews we had to go to some sensitivity / political correctness training class. I of course declined and that was the end of interviewing. I'm not sure what happened between three years ago and today, I didn't bring it up when the TL mentioned about us doing an interview.
--
I'm glad the disastrous HR policy is apparently no more. The closest I heard to a rationale at the time was something about what if a rejected candidate comes back with a lawsuit? yes let's talk about that. The company is large, with thousands of employees. So it's safe to say there have been around 100,000 interviews. Of these how many lawsuits have there been? Probably zero, none that I ever heard of. In the worst case even if some settlement ended up being paid to a troll lawyer then we can quantify the cost of these settlements over the population of interviews. And in the worst case the cost is probably about $1 an interview for these theoretical lawsuits.
Now let's compare that to the cost of a bad hire. Even for an entry level programmer or tester the cost of a single bad hire is staggering, well into the tens of thousands. And at the intermediate level and above it's certainly upwards of and into six figures. So what's more important financially, avoiding some imaginary theoretical small lawsuit that legal/HR would have to deal with, or avoiding a bad hire that development and the entire company would have to deal with.
Obviously the value of avoiding bad hires is orders of magnitude more important (and hazardous, as bad candidates are many and can often get quite deep into the recruiting process and even all the way on board). Yet HR/legal had the power they added this policy in order to make their lives theoretically easier. The term for this business antipattern is local optimization, where some department will put in some new rule or procedure that makes their workflow easier or faster while the overall cost to the business as a whole is worse off.
The team is looking to add a new person to backfill for turnover. A candidate got through the first interviews with HR and the team lead. The TL asked the developers to do the next interview. It was a good interview I thought. The candidate was pretty solid and I thought he came across pretty well. Myself and the other developers had some probing questions. After the interview the team lead escorted the candidate out and we had a quick meeting to give the instant feedback and offer a thumbs up or thumbs down hiring recommendation.
It's a good experience to be on the other side of the desk. I didn't think I'd get to do any more interviews. In the first couple of years with the company I did a number of interviews for everything from co-op student through to team lead. I enjoyed doing them and I believe I was good at it. Then one day HR announced that in order to do interviews we had to go to some sensitivity / political correctness training class. I of course declined and that was the end of interviewing. I'm not sure what happened between three years ago and today, I didn't bring it up when the TL mentioned about us doing an interview.
--
I'm glad the disastrous HR policy is apparently no more. The closest I heard to a rationale at the time was something about what if a rejected candidate comes back with a lawsuit? yes let's talk about that. The company is large, with thousands of employees. So it's safe to say there have been around 100,000 interviews. Of these how many lawsuits have there been? Probably zero, none that I ever heard of. In the worst case even if some settlement ended up being paid to a troll lawyer then we can quantify the cost of these settlements over the population of interviews. And in the worst case the cost is probably about $1 an interview for these theoretical lawsuits.
Now let's compare that to the cost of a bad hire. Even for an entry level programmer or tester the cost of a single bad hire is staggering, well into the tens of thousands. And at the intermediate level and above it's certainly upwards of and into six figures. So what's more important financially, avoiding some imaginary theoretical small lawsuit that legal/HR would have to deal with, or avoiding a bad hire that development and the entire company would have to deal with.
Obviously the value of avoiding bad hires is orders of magnitude more important (and hazardous, as bad candidates are many and can often get quite deep into the recruiting process and even all the way on board). Yet HR/legal had the power they added this policy in order to make their lives theoretically easier. The term for this business antipattern is local optimization, where some department will put in some new rule or procedure that makes their workflow easier or faster while the overall cost to the business as a whole is worse off.
Thursday, December 27, 2012
Scaling Lean & Agile Development by Craig Larman and Bas Vodde
Some time ago at work, our VP at the time ordered everyone to read two books. Everyone was sent their own personal copies. One of them was Scaling Lean & Agile Development by Craig Larman and Bas Vodde.
As the title suggests, this book is about scrum in large projects. This includes large embedded software systems with tens of millions of lines of code, hundreds of programmers in offices worldwide. As a running example the authors often talk about the software that goes into a large sized printer/photocopy machine.
This is a very good book. The authors definitely have the credentials to talk about large scale scrum, having practised it on the big printer projects and other large programs. An important theme is about the scrum teams themselves. The authors emphasize that the individual scrum teams must be physically located together to be a real scrum team and be effective. It's fine to have multiple teams in different sites and time zones, however each individual team must all be together.
There's a 19 page scrum primer at the end of the book. I found this incredibly useful and valuable. To think of the time and money I saw squandered on bringing in dodgy scrum "consultants" / "trainers". We spent three days flipping pennies and other worthless exercises. It would have been 100 times better to have just handed everyone a copy of this book and sent them home for 3 days to read it. Or even half a day to thoroughly read and understand the 19 page primer and we would have had far smoother and more successful scrum adoption.
My biggest regret is at work I've tried to discuss this book and how valuable it is with my coworkers. Alas, it proved to be a one sided conversation as unfortunately few seem to have read it despite my enthusiasm and recommendations.
One thing I've always wondered about the book though. As noted, it was a VP who commissioned a copy for everyone. What did the VP mean by sending everyone a copy. Some possibilities come to mind as to what was the VPs message to the dev teams, in particular the directors, managers and team leads
this is a description of what we are already doing at this time
this is an order to switch the software development to do what is described in the book
the book is suggestions to evaluate what we are currently doing, and move toward the practices described in the book
Alas since the last major reorg I no longer report to that VP so I can only speculate.
As the title suggests, this book is about scrum in large projects. This includes large embedded software systems with tens of millions of lines of code, hundreds of programmers in offices worldwide. As a running example the authors often talk about the software that goes into a large sized printer/photocopy machine.
This is a very good book. The authors definitely have the credentials to talk about large scale scrum, having practised it on the big printer projects and other large programs. An important theme is about the scrum teams themselves. The authors emphasize that the individual scrum teams must be physically located together to be a real scrum team and be effective. It's fine to have multiple teams in different sites and time zones, however each individual team must all be together.
There's a 19 page scrum primer at the end of the book. I found this incredibly useful and valuable. To think of the time and money I saw squandered on bringing in dodgy scrum "consultants" / "trainers". We spent three days flipping pennies and other worthless exercises. It would have been 100 times better to have just handed everyone a copy of this book and sent them home for 3 days to read it. Or even half a day to thoroughly read and understand the 19 page primer and we would have had far smoother and more successful scrum adoption.
My biggest regret is at work I've tried to discuss this book and how valuable it is with my coworkers. Alas, it proved to be a one sided conversation as unfortunately few seem to have read it despite my enthusiasm and recommendations.
One thing I've always wondered about the book though. As noted, it was a VP who commissioned a copy for everyone. What did the VP mean by sending everyone a copy. Some possibilities come to mind as to what was the VPs message to the dev teams, in particular the directors, managers and team leads
this is a description of what we are already doing at this time
this is an order to switch the software development to do what is described in the book
the book is suggestions to evaluate what we are currently doing, and move toward the practices described in the book
Alas since the last major reorg I no longer report to that VP so I can only speculate.
Tuesday, December 18, 2012
A new email world
Back in the late 1990s at PRIOR Data Sciences I went over to the Department of Fisheries and Oceans as a contractor to help out with DFO's Y2K projects.
I was on site at DFO for several months. Each Friday I faxed my timesheet back to the engineering services manager and all was good. With no reason to go to the office which was across the bridge I didn't drop by and log in.
One day after several months away I was in the PRIOR office and logged in. I was amazed that there were over 100 unread email in my inbox during that time. Wow that seemed like a huge number. At that time we didn't have remote desktop, and OWA was just being launched. It took over an hour to wade through the messages.
Fast forward a few years to today. My last day of work for 2012 was Thursday last week. Since then in the following 4 days, only 2 of which were business days, there are now north of 200 unread emails in my inbox. I know this because of BlackBerry.
The 200+ messages are just those that got by the Outlook filters. Back at PRIOR there were no filters, every single email went to my inbox. Today I have dozens of folders and filters and more email gets filtered than gets through to inbox. Still 200 messages in 4 days, a few marked urgent.
It's a different world now. Back at PRIOR there wasn't much point sending an email over the weekend because nobody would see it until Monday. Today it is standard to send emails which expect a response during the evening and on weekends and it's not to get a head start on the next business day. What's the expectation when someone sends an urgent email on a Saturday afternoon? Is it considered bad form to generate urgent emails outside of regular business hours?
I was on site at DFO for several months. Each Friday I faxed my timesheet back to the engineering services manager and all was good. With no reason to go to the office which was across the bridge I didn't drop by and log in.
One day after several months away I was in the PRIOR office and logged in. I was amazed that there were over 100 unread email in my inbox during that time. Wow that seemed like a huge number. At that time we didn't have remote desktop, and OWA was just being launched. It took over an hour to wade through the messages.
Fast forward a few years to today. My last day of work for 2012 was Thursday last week. Since then in the following 4 days, only 2 of which were business days, there are now north of 200 unread emails in my inbox. I know this because of BlackBerry.
The 200+ messages are just those that got by the Outlook filters. Back at PRIOR there were no filters, every single email went to my inbox. Today I have dozens of folders and filters and more email gets filtered than gets through to inbox. Still 200 messages in 4 days, a few marked urgent.
It's a different world now. Back at PRIOR there wasn't much point sending an email over the weekend because nobody would see it until Monday. Today it is standard to send emails which expect a response during the evening and on weekends and it's not to get a head start on the next business day. What's the expectation when someone sends an urgent email on a Saturday afternoon? Is it considered bad form to generate urgent emails outside of regular business hours?
Subscribe to:
Posts (Atom)