Approach to Learning within Sprints
Engineers love to learn new technologies. It’s not just that we like shiny new toys, we just want to solve problems better, faster or both! Some teams approach new learning by having specifically allocated time, such as every second Monday or Friday afternoons. In the company I am currently working for this is done by some teams where it is called an ISA (Inter-Sprint Activity) and are generally allocated for every second Monday (the first day of a sprint). I have never found that this approach works for me, since in a lot of cases I want to solve a problem when I am having it, not days later. I also passionately believe that every project offers opportunities for learning, so there is no need to artificially set aside time. That said, they do not always present themselves on the surface of a project, sometimes you need to look carefully to find them.
Recently in my current team we required configuration changes to be made using Puppet. Rather than create tickets in the Production Operations already overloaded queue, we decided that this work would be prioritised and implemented within our team. Initially this involved spending a small amount of time upfront pairing with a member of the Production Operations team, but after that it allowed us to become a more self-sufficient team. It also allowed me to learn how to apply a new technology, which was great. One thing to be aware of, but not fearful of, is failure. It is ok to fail as long as you are sensible. Testing a Puppet change and breaking a QA environment temporarily is generally acceptable, pushing a change directly to production servers is not acceptable; it’s just reckless. Following this in combination with pairing or code reviews acts as a safety net while learning a powerful tool like Puppet.
Start Small
Learning something like Puppet might seem like a big challenge, but there are much smaller but still very interesting chunks of work around. Last week I was doing some deployments with Capistrano and I came across a problem. If you tried to deploy an RPM that has not been installed or promoted to the relevant RPM repository, then the Capistrano deploy would fail and the application would be left in a stopped state.
I could just check that the RPM is available manually each time I deploy, however a more elegant solution is to build it into the Capistrano script as a precondition. Although I had already done Capistrano development many times before, this situation allowed me to refresh my skills and solve a real problem! Other examples that have come up recently in our team include automating manual tasks with Rake and checking our application deployment using rspec shared examples. Learning new skills outside of the usual boundaries of your role is something that is generally encouraged at my current company and can involve some unusual areas. When my team in Melbourne first started working remotely with a team in Bangalore, I gained significant knowledge about different types of microphones for Skype meetings and standups. Myself and another colleague even met up with a sound engineer, who know scary amounts about how sound travels around different rooms.
Stay Focussed
I have just outlined some of the benefits of learning new things, however it is also very important to keep focussed. Specifically when working within agile teams, it is important to choose tasks or improvements with big bang for buck. It is also, a good idea to break down the work as small as possible and deliver small pieces. For example, the work I did on improving our Capistrano deployments was only 1-2 hours work. This will pay itself off very quickly, since it will reduce confusion around failed deploys and ensure more uptime of QA and Production instances. Another aspect worth keeping an eye on, is the trust level within the team (including the product owner). You don’t want to be known as the developer who is always playing with new technology and not delivering business value. This will quickly turn into a situation where you are micro-managed, and probably for good reason. In my experience, it always works well to start small and seek approval until a trusting relationship is built with your other team members and product owner.
So what are you waiting for? Identify a small problem that wastes your time, breaks your flow of work or a repetitive manual task and spend a few hours solving it. It you are not sure how to break it down small enough to tackle in a few hours, find a more experienced team member and buy them a coffee!
Comments