Lean manufacturing, the precursor to the “Agile” methodologies, has the concept of “Stop the Line”. When a defect in the product is identified, the entire assembly line stops to locate and rectify the factors that caused the defect.
The major difference in a software development “line” is that there is no physical assembly line, so it is easy to blur the distinction between what is and isn’t part of the product and hence the “line”.
In the Lean manufacturing model it’s acknowledged that the cause of the defect may be more than just a faulty component. It may be the tools, processes or even the skills of the people involved in the manufacturing of the component that contributes to the defect. With the line stopped, the right solution can be found before production resumes.
In software development however, development continues. One of the problems Adrian points out is that
if developers keep working while the build is broken, they build up a large backlog of commits which makes it more difficult to identify which revision broke the build
It goes further than that however. By continuing to develop, the team and management are assuming that the defect was caused simply by a mistake in coding of that feature or the build process. What if the problem is in the development process, the tools or the experience of the developers involved?
Adrian goes on further to suggest that some companies go a little closer to a “Stop the line” approach by putting
an embargo on commits or close the source tree to prevent any further changes from being committed
Once again, development doesn’t stop, we simply stop putting things on the assembly line. Once the build breakage is resolved, all these potentially broken changes are pushed through.
By stopping the entire line, your development team can not only address the current defect, they can also perform a “Root Cause Analysis” of why the problem occurred, leading to better processes, tools and people.
So why do so many companies see “stopping the line” as a waste when it is the complete opposite?
I believe it’s based on a management perception that if you aren’t developing code directly related to the final product, in other words features or bug fixes, then you are not being productive. In addition, there is a belief that the number of hours spent coding directly relates to the productivity of the team. So a team is discouraged from taking the time to not only improve their tools and processes, but also to analyse what needs improving.
]]>I recently had a comment on my original post. In it the author indicated that "Competence" in their opinion was far better.
As they put it,
Capability always indicate the “possibility” that the person have to do something, but may be he can not really do it.
“I have the capability of speak in Chineese because i have all the neccesary for this, but i can not because i dont know chineese language”.Competence is always the capability but shown in practice, This is not the ” possibility” its real, practical.
While I agree, someone who may be capable of performing a task may not really be able to do it, in the real world of IT, there are many situation where limiting yourself to just a set of competent skills may be detrimental. For example, it may mean you overlook an outstanding developer with the right development mindset but not a particular language, who would be able to take you and your business along with the changing landscape in IT.
The other problem I have with the comment is the example. I don't believe you can draw a parallel between a spoken language and a computer language. For one thing, the grammatical rules or "syntax" of a spoken language are significantly larger and more complex than a programming one. Now while I can speak, I therefore have the Capability to speak another language, I don't yet have that Competence. However, I am Competent in many computer languages, and therefore have the Capability to quickly and easily master a new one.
In the IT world, competence does play an important part, but I believe if you rely entirely on that alone in your decision to hire someone then you are selling yourself very short.
]]>
I guess it should have been expected, but what was interesting was that it seems the delay is not due to unexpected issues in the fit-out (as in water damage, etc) but rather the delay in the supplier getting the taps to the company doing the work.
Talking to the plumber, the problem lies in the suppliers not having stock sitting in local warehouses. Now this wouldn't have been a problem, but the time from agreeing to do the project, and it starting was very quick. As such, the time for the delivery of taps was longer than the time until they were needed. So if we weren't able to kick off this project so quickly, then they could have ordered those items in advance enough to get them here in time.
This got me thinking about Lean development practices and the “Just in Time” approach. If we consider that the aim is develop something “just in time” for when it is required, then it is possible that an opportunity may arise that, to take advantage of, would reduce the available time to develop and subsequently cause delays.
Of course the trade-off of doing “Just in Time” is that you aren't building a stock-pile with all the inherit costs and problems. It does however mean that the critical path analysis for taking advantage of a sudden opportunity does require you to know the “Just in Time” periods that could affect you.
]]>
One of the offices is very evidently a call-center. It’s clad in shades of grey and blue with small cubicles. It seems to suck the energy out of you just looking at it.
The other (pictured) seems to draw you in. In fact, upon entering, I had not idea what they did1, but you felt that it would be an interesting place to work.
It may seem obvious, but it’s important to consider the impact your office environment has on potential employee’s as well as the current ones.
When recruiting, if a candidate walks in the door thinking, “wow, I want to work here”, or compares favorably your office/team with their current office and team part of the hiring process just got simpler.
For your own staff, having a place that they want to work in, along with an outstanding team to work with brings it’s own rewards. Higher productivity, less down-time due to illness and greater retention to name just a few. These rewards have value not easily measured but a lot higher than what it can cost to make a great environment.
1 – My wife’s first guess from the photo was travel, but it turns out they are a tattoo artist.↩
]]>Most engineers I’ve worked with, I would consider “creative”. They are constantly finding and developing creative solutions to problems but just as importantly they enjoy creating things.
I’ve always enjoyed creating things so I gained a lot of satisfaction in my career from creating solutions in code. In the years before I moved to management, I was mostly involved in Web and GUI development. Both of these not only give you great feedback on your development but also provide a sense of creation.
About a year ago, I started playing GamesWorkshop’s Lord of the Rings. While I enjoy the game, I really got involved in the painting of the models.
I spend a reasonable amount of time making and painting models which culminated in me entering a painting competition (the model was from WarHammer not Lord of the Rings)
I recently came to the realisation that I had substituted the creative experience I had as a programmer with my modelling.
So, when you move from development to management, consider that you will no longer fulfill your creative requirements with your work and find a creative outlet.
]]>While the Weekend Australian article, “What Interviews foretell” by Karalyn Brown focussed primarily on the interview process from the candidate perspective, there were some good points for employers.
In my career I’ve been through quite a few interview processes, so it came as no surprise that Bob Olivier, director of Olivier recruitment
believes employers can easily overlook how a candidate matches the values and working style of an organisation – the “cultural fit”
One of the many attributes I’m looking for when we interview at Ephox is how the person will “fit” into our team. So while I’m ensuring the candidate gets a chance to evaluate our culture, we also ensure they will fit into the team through the code review and Coffee Interview.
Rightly so, Steve Begg, general manager of operations of executive recruiters Tanner Menzies and Olivier
believe that the recruitment process provides a glimpse into a company’s working culture. A formal series of interviews can indicate a more bureaucratic employer. A “meet the team” chat reflects a more open and casual working style. However, Begg stresses both method are valid recruitment tools
At Ephox we have what I believe is a good mix of formal and casual in our interview process. In addition, I’m are upfront at the beginning of the interview process with what the process is.
So what is our process? Well like many companies we start with a phone interview. As a significant amount of our communication is with overseas clients and our other offices, this also gives us a chance to evaluate how well a candidate can communicate on the phone.
We then move to a more formal, in office interview. We delve into the candidates abilities and also talk about us and the role, leaving nothing hidden. We want candidates to want to work with us so make sure they have the information to do so.
Successful candidates are then asked to do a coding exercise but unlike most “formal” ones, ours is a little more candidate friendly. We email the candidate a simple program requirements and ask them to submit the code, in their preferred language, when they have been able to complete it. After submission, we get the candidate back in to discuss the code and the solution approach with a couple of the senior engineers. This gives the candidate a chance to gauge what it is like to work within the team, and importantly for us, gives us a chance to evaluate how the candidate solves problems and discusses solutions.
Finally, if all goes well, we have the coffee interview to allow the entire team to participate in the process.
Why do we go to all this trouble to ensure both the candidate, the team and the company fit together? For one thing, we have very good retention and want to keep it that way.
]]>
I was reading an article in a recent Campus Review entitled “Wellness & retention” which discussed some of these options.
Universities have traditionally not been the highest paid positions, so retention of good IT staff in this climate is becoming an increasing problem. The University of South Australia has tried a different approach to just competing on salaries.
Over the past five years, its 100-strong IT team has been the focus of a wellness program aimed at encouraging employees and recruitment prospects to view the university as an employer of choice.
Some of the things that UniSA has undertaken are gym passes, weekly exercise programs, fresh fruit, fruit juices in summer, and soup in winter.
What they found was this focus on health of their staff resulted in a drop in attrition to 2%. It also had side benefits
The program costs about $15,000 a year but pays for itself with a reduction in sick days.
I believe there are a number of factors beyond just pure salary that influences a person’s decision to stay with a company. Things like culture, colleagues/team, stress, management and how much the company values them.
At Ephox we’ve always had a great culture of fun. In addition, we have a great coffee machine, go to the pub on Friday’s for roast lunch and have beers at the end of the week.
Recently I asked the team what additional things we’d like to have in the office. I was looking for suggestions that meet one or more of the following criteria;
I got some interesting responses including fresh fruit, monthly neck/shoulder massages and quarterly team events. So we’ve started getting in fresh fruit, are about to trial in office massage and have nominated one of the team to be the coordinator for a team event.
I’d be really interested in what other companies are doing to retain great staff other than paying higher salaries.
]]>
At Ephox we have a good collection of technical books and I’m always looking for new ones to add. It was suggested that we should get a copy of “Head First Design Patterns”. As the Head First series are designed to be written in, I purchased a copy for each member of the team.
I was sure it was a good decision when the day after they arrived one of the team stopped me to tell me how good it was. This was quickly followed up by one of my senior engineers raving about how easy and compelling it was to read. Finally, one of the team rang me on the weekend prior to their week of leave to confirm they could write in the book, as they were really getting into it.
So, if you want a low cost form of training, don’t just buy books for your team library, but actually give them their own copies.
]]>Our CCAs are evolving into more advanced research that resemble 20% time, with projects spanning many CCAs. So when Atlassian announced it was going to emulate the Google’s 20% time model I was keen to see how it worked out for them.
It was with interested then that I read the recent followup on the progress over the last 10 weeks. In the post Charles reflected on their progress to date with a series of questions put to the developers.
The one I was most interested in was “How much time have you had to work on it?”. Charles summarised the responses by saying
almost all the responses were in the 2-3 day mark, and none higher.
This is closer to 4-6% for the 10 weeks they’ve been going than 20%. Why is this low?
In theory, saying to developers you can devote 20% of your time to do research/personal projects should result in 20% time being spent. The problem, as I see it, is that most project are on tight deadlines, and developers are committed to completing those project related tasks. A fact that seems to be borne out by the following response
…the biggest problem for developers finding time to work on their projects was fitting it around their scheduled work
So what’s the real problem? Well your projects are planned but no time is set aside in the schedule for 20% time activities. When your developers start working on 20% time, the schedule starts to slip, eating into “buffer” time. If the features then require that buffer time, how does the project manager deal with it? Easy, cancel 20% time.
How do we deal with this? The answer I think lies in a response to the question “if you could improve 20% time in any way, how would you?”
“Mandate that particpants (sic) have to spend 2 days a fortnight on it, otherwise it's difficult to keep the pace up to 20%”
So, when planning a project, not only do we need to put aside time for feature overruns, but also time to accommodate 20% time. Again, all good in theory but at the end of the day, as a product company, we need to deliver product. The trick is to balance the successful delivery of new releases with the obvious benefits that can come from 20% time.
I’ll be very interested in how Atlassian handles this over the remainder of their trial.
]]>
The Coffee Interview involves everyone in the the team, except the manager, going out with the potential hire and having a coffee. While discussions can be technical, it's not a technical interview but rather a chance for everyone involved to get to know each other. At the end of the coffee I get consensus from the team as to whether we should hire the person or not.
What we are trying to do in this interview is determine if the team can work with the person, and the person can work with the team. It's a case of ensuring the hire is a good "fit".
By involving everyone the person will work with, we are essentially building an emotional contract between the team and the new hire. These people are the ones who can exert the most influence over the success of the new hire and as such, the Coffee Interview provides a way to invest them in the success of the person.
]]>