Testing in Agile Part 4: Skills /Training

SKILLS

Agile teams need training!

One of the missing links in the implementation of Agile development methods is the lack of training for teams. I noticed in our recent survey on Agile that only 47% of the respondents answered “Yes” that they had been trained in the Agile development process, with over half responding “No.” This number is way too high. The “No” respondents should be closer to 0%!

Have you been trained in Agile development?Percent answered
Yes47.8%
No52.2%

Check out last month’s Survey Summary Article
A situation that is too common these days is a team says: We are Agile because their manger told them they are and they have daily meetings. They have cut down the size of their requirements docs. They call their development cycles sprints and their daily meeting a scrum. That’s about all the Agile there is to this development organization. No management backing off, no self-directed teams, same old tools, no more measurable unit testing or Test Driven Development (TDD), and no increased test automation – they now just call themselves Agile.

This is wrong. This is not Agile. This will lead to problems. What you want to prevent is a wave of the magic wand and… “abracadabra, you’re Agile!”

Training solves problems

Before starting any Agile implementation, the team must be trained in a variety of ideas, practices and methods. Such as: What are Agile, Scrum, and XP? Why are we doing it? How should you do it? What are the new “roles?” How do I do my job differently now?

To make a case for training lets put together a few foundation ideas of Agile development. Teams and individuals must be trusted to do their jobs. Without proper training – that trust will not happen. Simple. Also, in my experience with Agile teams, one common hard learnt lesson is the importance of changing and improving the way teams work and develop software through the use of retrospectives and continuous improvement; that is, teams constantly reflect back on what worked, what did not and change practices, processes, and sometimes, even teams. This is key to Agile success. Teams need training and coaching here. This is not your old fashioned post-mortem.

There is a common phrase in the Agile world: Fail early, fail often! This means, fail fast – find out what does not work for you, remove inefficiencies right away and find the practices that do not work for your team and get rid of them fast. Try something – fail at it, fix it, make the process better, change how you do things till people are comfortable with how things work.

To do this crucial piece of the Agile/Scrum/XP most effectively, get training about what is Agile and why are these practices used? When your team has problems – all teams do – having good training on the practices, and the processes to recognize and take action on problems as well as recommended or alternative practices will help you fail fast and fix problems – getting more productive and happier faster!

Agile training for whom?

The main audience for this article is test teams. Most test teams do not dictate management training. But if you have the ability to make a suggestion, strongly suggest your company’s management teams get training in understanding Agile and critical management topics such as: Chickens and Pigs, the importance of product owners, customers or customer representatives working with the Scrum team daily, empowering self-forming/self-directing teams, and team ownership of quality – rather than the traditional single point QC by a test team. Having management understanding of these topics is a minimum starting point and support for productive teams. Management needs Agile training too!

The whole development organization and Scrum team will need training and a new glossary. The practices and glossary will make a laundry list of training topics fast: sprint, spike, scrum of scrums, done, release planning vs. sprint planning, what happens at a scrum meeting and what does not, cross-functional and self-directed team roles, the role of the scrum master, etc.

For other non-test team members there can be significant training, like unit test training for developers and choosing a good unit test harness, TDD (test driven-development) vs. unit testing, scrum master, and product owner training.

Let’s pause here for a second, since I want to make sure you are aware that I talk in detail on many of the above skills, topics and methods in my last three articles in this “Testing in Agile” article series. I encourage you to review them since they will provide additional context to some of these suggested training areas.

Here are the links to those articles:
Testing in Agile Part 1 – Intro to Agile for Testers
Testing in Agile Part 2 – Agile is About People
Testing in Agile Part 3 – People and Practices

Skills for test teams

Let’s move on — specific to test teams, in most organizations, after a whole-team training on Agile development, the biggest burden for technical training and testing skills is the ability to be much more dynamic and self-directed in test strategy.

The testing skills needed for Agile test teams are more responsive, dynamic, thinking on your feet methods rather than following-a-plan type testing many test teams are accustomed to. The test team needs to move away from validation and into investigative, exploratory, aggressive, unstructured methods, such as “error guessing.” Test teams need new strategies that are more responsible for reviewing design as well as hunting down bugs and issues!

Training is also needed for when and how you test. Teams need to split their time and tasks between developers and testers for unit testing, user story validations, UI testing and devoting focus on strategies around manual and automated testing. There are also documentation changes and ideas for more lean and efficient practices — avoiding documentation waste. Agile teams must have new approaches to writing test cases. These issues get solved with training.

In successful Agile organizations, traditional style test plans are useless and not nearly dynamic and flexible enough for the speed of Agile projects. This does not mean people who test stop planning! It means, instead that a different, leaner, more efficient set of test artifacts need to be created. This, again, is a training issue.

And, as mentioned in other places, good test teams should and can take on more technical tasks, such as design review and build management/continuous integration – read more about continuous integration in my last article on people and practices. This should be achievable for well-staffed test teams with good training and skill development.

Also important for most development teams is team building, communication, and “feel good about working together” type training. Many organizations are moving from situations where the relationship between project management, development and testing is sometimes strained. These frayed relationships generally occur due to poor communication and are often exacerbated by individuals with different motives or unrealistic timelines. In Agile development frameworks, these bad dynamics kill any chance of success. Soft skill training is yet another key to Agile success.

Here are some skills I have often found lacking in testers who are involved in an Agile development project:

  • good, on the spot, rapid fire estimation skills – for people who test and people who write code, product owners and scrum masters
  • depending on the existing skill set of the many test teams, some testers will need help and training to successfully contribute to software design critique
  • many times in this series we have discussed the need for massive test automation. That most teams need help looking for easier, more effective, faster ways to do more automation is clear. Test Automation in Agile deserves its own white paper – I will however, talk a little bit about automation playback tools for Agile in my next article, the last one in the series.

Good Agile trainings should be full of learning games and learning activities. That Agile is “learn-by-doing” is clear. Training adults needs to be lighter, more fun, engaging – and immediately related to their job! There are significantly higher levels of retention with learning activities than with only lecture or reading. But most importantly, the activities and games are a perfect way to present a new way of thinking, teamwork dynamics and principles to foster good team dynamics.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

Our comprehensive issue on Agile, which was set to be released in June, has been moved to early July. We’ve made this decision in order to accommodate an article from one of our industry’s thought leaders. We’re really excited about this piece and we’re sure you will be too! LogiGear Magazine is dedicated to bringing ...
Author of The Agile Warrior, Rasmusson answers questions from LogiGear’s testing staff about test automation in agile projects.
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Four of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”   LogiGear Corporation  LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and ...
One of the features of using Agile methods is the opportunity for continuous improvement within a project. There are a number of improvement opportunities throughout a typical iteration or sprint─over the next few weeks I’m going to walk through a few, starting this week with the Retrospective. Retrospectives are one of the many tools in ...
Michael Hackett sat down with FNC’s Chris Floyd to get his take on numerous Agile topics.
LogiGear Magazine – November 2010
If your Agile implementation is not about people, you’ve missed the boat! The most profound impact to becoming more Agile is happier teams! Agile manifesto Value #1: * Individuals and interactions over processes and tools Words like these do not show up in Waterfall or RUP SDLC process descriptions. Agile cannot get more basic than ...
Writing code that is easy to read and easy to test is difficult to achieve. The fact that poorly written code can function often leads to coding practices that are effective but not necessarily efficient. Too often, many programmers fresh out of school write code in the manner that was effective for passing their courses, but contains ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part One of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile” LogiGear Corporation LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and offers ...
Maximize the function of your teams The Modern Agile philosophy created by the folks at Industrial Logic is one of the most exciting ideas I’ve encountered in a while. Moving beyond the pre-canned “You must do X to be Agile” mindset that I’ve seen becoming more and more prevalent.
Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations ...
The sprint is almost over; the burn-down chart has not budged. The test team sits around waiting. They hear about all kinds of issues, obstacles and impediments at the daily stand-up but there is no code to test. Closing in on the demo and sprint review… then at Wednesday’s stand up: the heroes arrive and ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe