Training and Onboarding Series: Agile Training
Now that we’ve covered the importance of effective training, let’s talk about Agile-specific training.
Speaking from personal experience, I can tell you that your team must have a qualified and effective Scrum Master (SM) or Agile Coach (AC). If you need proof of this, go through this activity without a qualified person to help and tell me if you think I’m exaggerating! No doubt some teams will succeed, but the fact is that most teams need help.
Agile has been around for about two decades now, but it started gaining stronger traction amongst the Fortune 500 companies about 6-7 years ago. Olenick began its process of Agile training for their consultants around 5 years ago, as a result of a client request for assistance on an Agile effort. Subsequently, Olenick’s lead AC was designated to train other consultants in the company on Agile Scrum, which evolved into Olenick’s Agile Training Program.
With a training lead experienced in multiple roles within Scrum setting the program for its consultants, what Olenick did next was a key to success: instead of simply relying on newly trained individuals to provide team needs at each client, Olenick ensured each team had someone joining them with actual Scrum experience. Olenick’s Agile teams now had a mixture of freshly trained employees as well as seasoned veterans. Though this may sound like fundamental common sense as far as process, I assure you that it is many times overlooked.
Refer to my Agile experience story in my previous post, and you’ll see just how one company thought a single AC could suffice for an entire organization, comprised of many teams. Had Olenick been provided the opportunity to do a client evaluation at that company, they would have ensured each team had a strong SM or AC. An organization will never succeed with any amount of change, let alone a drastic one such as a crossover from Waterfall to Agile Scrum without the proper support system talked about in my first post. Having strong leaders with actual experience within each team -or at the very least each business unit – is the first step. Allowing people to practice is the next – but we must also ensure practice is happening while monitored. Practice “for practice’s sake” is not enough if you aren’t practicing correctly. Monitoring the actions and processes to ensure that what is being done is in line with the training is necessary. Note – when I say practice, I simply mean to put in place, then allow the team to learn from their mistakes and grow. Agile Scrum is rooted in the “learn and improve” model: do something quickly, but also try and do it correctly. Fail fast if you’re going to fail, so you can fix those failures for the next sprint.
It’s also imperative when considering a move towards Agile practices that you evaluate your needs properly, and once that evaluation is complete consider which framework best suits your needs. For example, it would not make sense to train your team on Agile Scrum if you ultimately end up pursuing Extreme Programming (XP). Most often organizations will land on Scrum as the favorite framework for their needs. Scrum is fairly encompassing and can be used in a very broad spectrum. In fact, Scrum is based on lean manufacturing processes set in place by Toyota. Scrum is used in classrooms, and you can even find books on how to bring Scrum into your house. There are a multitude of ways you can incorporate Scrum into your life, hence its appeal to those looking to get into Agile.
As we can see, Agile training in and of itself isn’t an easy topic; the training will depend upon your ideal framework. When you do understand which framework best suits you, training is not much different for Agile than any other training in that it needs to be clear, provided from an experienced source, and supported properly with the ability to put into practice. Only by doing this will you find a more immediate level of success.
On my very first Agile project earlier in my career which amounted to becoming Scrum, we found a great deal of success – but only after we had struggled for 7 months of not delivering a single piece of working software. It took a SM change for us to get into true understanding and practice to where we could produce working software in a 2-week sprint. So, no doubt, you should eventually see success, the question is whether you want to see that success early or further down the road.
Thanks for reading, and be sure to look forward to my next post about Managing Agile Teams Remotely.
SUBSCRIBE to Olenick Expertise to receive my upcoming articles, and more IT-focused articles written by Olenick consultants right to your inbox.