Where does learning new skills fit into Agile?

Question

I am starting a financial software company and in the process I have been studying Agile principles and methods and the one aspect of development that I have not yet seen addressed is where to fit the continual need for developers to learn new skills and technologies into the development process.

Before working on financial software for the last couple of years, I spent most of my career as a 3d graphics programmer working on video games and GIS and biometrics software and I have always simple had to dive off of a cliff into things and figure out how to fly. While I always succeeded, I am sure I am not going to live as long as I would have if I hadn't killed myself working so many 100 hour weeks and months at a time.

Now that I am starting a software company that doesn't quite have the intense innovative demands of 3d graphics, I want to establish a more holistic approach to development.

Maybe agile just doesn't address this, but if it does, I haven't found where and I would appreciate any knowledge or expertise or experience anyone has with this.

Answer 1

This doesn't really have much to do with Agile, or even with Software Engineering. It is simply true of any company in any business: you need to set aside time for training. Period.

Agile has this idea of "sustainable pace", which means that, at no point, should the team work harder than what it could sustain for an indefinite amount of time. I.e. no "crunch time". This needs to be honored by training as well. So, it a sustainable pace for your team is "no more than 5 hours straight without break, no more than 9 hours per day, no more than 40 hours per week", and you want to provide 10% time for training, then you need to plan your projects for 36 hour weeks.

But again, this has nothing to do with Agile, that's just common sense and primary school math.

Personally, I would think that something like allowing for half an hour per day, one half-day per week, and one full week per quarter would allow the team to acquire different-sized chunks of knowledge quickly and at a steady pace.

There are also some Agile practices that help with knowledge transfer, i.e. to smooth out differences in the level of knowledge across the teams:

• daily retrospectives
• retrospectives per sprint
• retrospectives per project
• pair programming
• ping-pong pairing (swapping the driver and navigator after every step of the red-green-refactor cycle)
• promiscuous pairing (no fixed pairs, pairs are assigned randomly and changed every morning and lunch)
• odd number of team members (if you do pair programming, leaves one team member free to learn)
• mob programming (a variant on pair programming where the entire team uses a single computer and screen, a designated team member is simply a "typist" and the others tell him what to write)
• promiscuous teams (developers are randomly assigned to teams every day / every sprint)

Pair programming and mob programming not only provides continuous code review but also continuous knowledge sharing. Ping-pong pairing prevents one person "hogging the keyboard". Promiscuous pairing spreads knowledge through the entire team, promiscuous teams spread knowledge through the entire company, and ensure that every developer knows every project and every codebase; it will also lead to a high degree of standardization in the codebase(s). While the prime focus of retrospectives is to provide feedback on the development process and adapt accordingly, it can also be used to communicate an uncommon issue and how to solve it.

It should go without saying that the employer should provide an extensive library, paid subscriptions to ACM, Springer, IEEE, etc., as well as quiet rooms to study in and larger rooms to teach in. Lots of whiteboards and flipboards, as well as projectors everywhere are of course sensible in general, not just for training.

Answer 2

I'm going to agree with most of what Jörg W Mittag said, but not with the statement that "this doesn't really have much to do with Agile". A number of Agile techniques support learning and development of individuals and teams.

The Agile methods tend to be based on increments or continuous flow. In either case, work is ordered based on considering factors such as priority, value, and dependencies. Since the focus is on the short term work, the team can identify knowledge that is needed to deliver and, if the lack of knowledge is problem, plan for gaining that knowledge just-in-time. Visibility and transparency also tend to be key aspects of various Agile methods, so stakeholders can see what the team is working on and how they are working to improve their abilities to deliver value. When extensive learning is necessary, it can be planned into the near future or the current iteration.

Once individuals on a team have gained knowledge, there are techniques around pairing and mobbing. Pair Programming is a key practice in Extreme Programming that has been applied to other methods as well and is designed to, among other things, facilitate learning. Mobbing is applying this to more than just two people. The close collaboration and cross-functionality of teams means there aren't silos and this information is disseminated.

Even with the ability to plan for and execute on learning what is necessary for the immediate work, having knowledgeable team members is very important. Having people with some level of existing knowledge of the tools, technology, and domain will allow them to be more informed when taking on learning tasks and be more effective when disseminating knowledge to other team members.

Answer 3

Plan a proof of concept task for the sprint in which you want to budget time to learn a skill. Keep it focused on something very specific, like learning how to create an accessible HTML table. Keep scheduling proof of concept tasks until you have learned the skills needed for the story. Give each POC task some story points and a due date so you can properly time-box it, and show progress at the end of the sprint.

So what if a story should only be 5 points for an experienced developer? Maybe it takes 3-4 tasks at 8 points each. After those POC tasks the story still might be only 5 points, but at least you set aside the time to learn the new skills so that 5 point story isn't 40 points — even if the story and POC tasks add up to 40 points.

Answer 4

Scrum has the idea of a 'spike'. If the team is taking on a new technology or capability, a spike is a story to encapsulate that work. So while a story in agile is a user focused bit of functionality, the output of a spike is documentation of what was learned, and a work breakdown for putting it into practice in the real application.

In practice, I've found that it's a good way to manage at least small-scale training - enough to get devs up to speed with a new system or framework while still giving accountability to the schedule.

Answer 5

I didn't see this in the other answers, so I wanted to add that many organizations start guilds, or chapter, or Centers of Excellence around skill areas. These can be broad topics like technology or specific ones like React Native Development. It all depends on if the interest to participate exists in your company.

Regardless, these groups often own the task of helping people in the group grow professionally. This creates a separate space outside of the work to reenforce and expand skills for both people who use those skills every day and even people outside of that discipline who are interested in cross-training. This isn't the only solution to this problem, but it seems to be becoming an increasingly common one.

Answer 6

Some others already mentioned aspects, but I just wanted to share how I fit personal development in a agile environment.

1. Ongoing development

This is the easiest one, reduce your capacity in each sprint until you have enough time to do ongoing development. The hard part is usually sticking to your plan, and also doing the development if there are more other tasks to be picked up. If you have emergencies you can sacrifice this time now and then, but otherwise don't.

Because you reduced your capacity, anything you do in this category is somewhat outside the direct concern of other team members, and they probably don't have much reason to worry about it or update the planning specifically in each individual sprint.

2. Larger efforts during a sprint

What I have found is that if you have planned something with a larger impact (e.g. 2 day training during a sprint), you should update the sprint to reflect this. I am not sure what the theoretical solution for this is, but I have often seen that people just put the training task task on the board to make sure it is visible that someone is busy with this.

Alternately you could correct the sprint capacity of the specific sprint, but unless people look very carefully at your measured performance/efficiency I would stay away from this. Especially in a fresh team, stability is probably more valuable than accuracy.

Answer 7

Agile is a set of philosophies, take a look at the manifesto, that's ALL Agile is, so when you say how can Agile solve my problems, I recommend learning (a lot) more about Agile. Let's take a concrete implementation of Agile: SCRUM. In SCRUM we have the concepts of a Sprint and spikes. Through these two artifacts, it's possible to accomplish creating a budget for learning.

If you look at a sprint as a pie chart, you can divide the priorities based on topic, one such topic can be... learning new skills!

A spike is a research task on a sprint that involves assessing the feasibility of something usually through learning.

Lastly, the thing you've been doing is still on the table and you can learn WHILE doing whatever you're working on, at which point you can try increasing the story points / capacity to cope with the technical challenge.

Answer 8

To quote out of the Agile Manifesto itself:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Emphasis is mine, highlighting the parts that are probably most applicable to you.

Fundamentally, well trained agile developers can respond to changing environments much better than those who let their skillsets petrify.

If I may add my own definition of agile, we can also bring "customer collaboration" into the mix. I find the best definition of agile to be one based on the idea of agility -- if the customer (or the environment) changes radically, how well do you cope? If you are fostering an environment of customer collaboration, they will have a vested interest in your team knowing what they are doing.