Learning on the Job
I’ve been having a series of conversations lately with one of my engineers about learning on the job. By this I mean that technological problems get figured out during a sprint. These problems usually arise from implementing technologies that aren’t so well known by the engineering team. A recent example for us would be finding solutions for complex queries with Fluent NHibernate. The conversations were sparked by recent events during our last release where a sprint goal was compromised by the introduction of a new Domain Driven Design (DDD) architecture, and the previously mentioned object relational mapper (ORM), Fluent NHibernate.
The engineer’s argument for learning on the job centres on the satisfaction gained by solving technical challenges presented by new technological ideas. As a manager, engineer’s job satisfaction is very important to me. In an unsettled economic climate such as the one we’ve just been (and perhaps still are going) through, it becomes even more important to use everything available to keep morale high. Our favourable stance to adopting new technologies over the past couple of years – we built a production app in .Net MVC right through its preview stages, releasing the app as MVC was released – has kept the engineers interested in their jobs. That being said, introducing a new technology is accompanied by risk, risk that can turn into a high cost. Learning on the job during the sprint is risky because it can create impediments that are very difficult to remove.
In order to find the right balance it is important that all the engineers know what they’re doing throughout the sprint. If a sticking point arises, e.g. a situation where you notice an engineer stuck with their head down for hours on end, a couple of scrums pass where they say they’ve got 1 or 2 hours left and they’ll be finished that day but they never do, then you know you have a problem. Sometimes this can be solved by pairing, but probably it’s a sign the team hasn’t done enough homework.
We just halted the introduction of a messaging technology into the next release and are mid way through a two week planning phase. The aim is to take a small sideways step in order to make sure the engineers are technically up to speed with what’s going into it.
The focus of the first planning week has been on story generation, next week we’ll be exploring those stories further to find potential engineering sticking points. When they are found the whole engineering team will come together to investigate the solution. This object of this exercise is not to create solutions for all our potential problems up front, as any changes to the backlog during the release could render this a waste of time, but to use the potential problems as case studies to ensure the engineers have enough knowledge about the technologies we have introduced before embarking on the sprints.
This is not something we will do between every release. A series of weekly, hour long sessions to contextually spike the implementation of the messaging technology using a current production app will get underway as soon as the release starts. We will only introduce it across our range of production apps when the team feels ready.
This is what I consider learning on the job. There will inevitably be some learning during the sprint, but the aim should be to control that as much as possible.
