Hi @Bruce, do you think that learning time should be allocated within the sprint? If yes, how many hours per sprint/week would you recommend? Thanks!
Bruceās legendary reply:
Yes, absolutely yes. Itās one of my top 10 opinions that weād all be better off and more productive and happy and innovative (ugh hate that word ahha) if we had 20% of our work day as slack time. I doubt Iāll ever work anywhere willing to try that though, because thatās an entire day out of every week.
I think learning time should be allocated in the sprint because when we learn things, that doesnāt happen in a void in our heads. It adds to our experience and feeds directly back into work. Companies are always talking about how theyāre āinnovatingā or doing something āground-breakingā but then they donāt give people time to experiment. To me, the easiest way to make great, consistent improvements in the team is to build slack into your processes.
By that, I mean individuals need to get into the habit of prioritising their own learning and development, and make sure that they keep time in the day to do those activities even when external forces are asking them to do something else - and managers should be helping them find ways to do that. Also leaders/decision-makers/big-players need to build slack in at a team level and not overload sprints so that no one has time to do anything until 9pm. xD
How much time is recommended will just depend on what people want to learn, and how much they personally feel they can dedicate mental resources to. In the past when weāve tried doing things like āeveryone gets X hours a week to do nice thingsā, individuals will still decide for themselves how much of that time they use. It should be an ongoing conversation with managers based on what each personās goals are.
What kind of learning ? Is the learning needed for the job, or is it just to build your own skills ? If it is the former, then you could just create tickets/tasks for learning and add them to your sprint. If it is the latter, then I think most companies will expect you to do it on your own time.
IMO, the learning you do on the companyās time should be mutually beneficial. Otherwise, the company is paying you to learn for your own pleasure, when you could be doing work for the company. All that investment is wasted when you donāt use any of the learning to help the company. After voluntary resignation, I wonder how many employees would pay a company back for all the learning which they did not use for the job. I donāt know how we would we track what was used or not.
If you allocate learning time in the sprint for whatever reason, then do it according to your situation. Ex. If your learning resource (books, courses etc.) are divided into tiny chunks, then maybe 1 hour per week for a two week sprint is okay. However, if each chunk needs 2+ hours at a time, then plan accordingly. If you devote only 1 hour per sprint & complete part of a chunk in one sprint, then you might forget it by the next sprint & have to start again. Youāll have to design your own plan since you know your situation best.
Is the job so mindless that people donāt have any opportunity to learn new things?
Is the company an innovator or are they copying and making sub-par/average at best applications?
Do people just want slack time, time to learn something/anything, time to learn something specific for a product/feature to be developed by the company soon?
How many people already have this knowledge that the person wants to learn. Should all people know everything the others do? Or is it ok for each to have different strengths in the team/company?
Is the company gaining something out of it?
Are the people full-time employees, interns, consultants, juniors, seniors; Does the company have an interest on developing the people? Whatās the aim of these people - do they want to learn for their own benefit or is it a company benefit as well?
What type of learning are we talking about? learning about product, business of the product, peer work with other departments peopleā¦etc.
Different companies will have different attitudes towards learning, even before considering their direct needs. It might seem like a no-brainer that a company will have a set list of skills that they will expect their people to become proficient in; but if that gets taken to an extreme, then all the staff in the company will eventually have the same set of skills and knowledge, and cookie-cutter people end up only producing cookie-cutter products.
For innovation to happen spontaneously, you need a diverse - in every sense - workforce who will bring a range of different life experiences and knowledge to their work. Really big companies can afford to employ people whose job it is to think of six impossible things before breakfast; even quite cash-restricted organisations, such as in the public sector, may find that people will think of off-the-wall stuff during their coffee breaks, and many a good idea has come off the back of an envelope after coffee break. (Some daft and unusable ideas as well, but thatās what the backs of envelopes are for.)
The company I work for isnāt big, but even then they saw that they had a team of testers who all had similar qualifications, knowledge and life experiences; so when they needed to fill a vacancy, they recruited me because I wasnāt out of that same mould. My technical knowledge was not to the same level as the rest of the teamās, but the company considered that my wider business experience made up for it.
That wider experience is the sum of something like forty years working in a range of organisations, quite apart from stuff Iāve learned outside of work. Now, if a company decided that they wanted this sort of knowledge within the team, it would be hard to go out and find any sort of planned programme of learning that would deliver it. I take the view that anything I know is at the service of the company should we spot an opportunity to use it. Mostly, thatās just anecdotes I tell colleagues over coffee; but sometimes thereās a lesson we can draw from that which helps the work, or assists the company in some other way. Thatās just experience.
What Iām trying to say is that with the best will in the world, any company - but especially one in the IT sector where innovation should never be far from the agenda - should be open to any idea from any source. Even if the company rejects 90% of the ideas that are generated, that other 10% may be the thing that exploits a market niche no-one else has spotted. So training should be able to accommodate a degree of completely unstructured study or lines of enquiry, and any allocation of training time should have, say, 5-10% of its time set aside to allow for completely unstructured study, because who knows what that might lead to?
+1 for this - Is the job so mindless that people donāt have any opportunity to learn new things ?.
Not sure about the OPās company, but there are orgs where the work is mindless or becomes mindless eventually. Thatās when you know its time to switch jobs if the org canāt give you something better. I strongly suspect that this happens in big and/or noticeably decaying companies.
Bruce got it right. There isnāt one correct answer.
As I see it, a product or service cannot be truly innovative without some amount of learning: It wouldnāt really be new. Marketing can (and should) put a new face on new products. But if the testing/development/research staff is expected to create new value, they have a range of learning needs: from how a new test tool works, to where can time/cost can be saved in development/operations, to which new technology can offer value to the organizationās products/services.
Many years ago a wise executive several levels above me acknowledged that the staff who had the best understanding of the organizationās products were its testers. We know why: a broader, integrated view, feedback from customers, etc. So I see testers in a professional role, where we recognize what we need to know, and find the time to learn it
āTesters having best understanding of the orgās productā could be true in small/lean teams or organizations. There are orgs in which the testerās scope is so small and restricted that they cannot have the best understanding of the product, unless they try to figure it out themselves on their own time. A good product manager might have the best knowledge in such cases.