The keynote starts with our dear agile chicken & pigs story. Pigs are the ones who are fully commited to the projects, all other stakeholders are chickens. Judged from the agenda, this session will be much about required skills and motivation. That sounds promising 🙂
What’s special about agile teams?
They have the authority to act, are self-organising, share ownership and (interesting!) any two can make a change to product, process and tests. This somewhat confirms what Boris Gloger said, that everybody in the team should be able to do 90% of the work, but adds that if you take any two team members you should have 100% of the skills covered. (I have to ask our mathematician Dr. Snatzke to figure out how to distribute the skills amongst team members to fulfill these two statements at the same time). Actually, Reid said that you need two to agree on making a change happen, I just assume that these two then can also carry out the change.
Is it also that agile teams are highly-motivated, highly-skilled and cross-functional? Generally, the kind of people in traditional and agile teams are the same. With an skill matrix you can identify which skills are underrepresented in the team, in this case DB and bond trading skills are lacking in the team.
What kind of skills do you have in that matrix? You can distinguish long / deep term (DB, Test) and short /shallow term skills (Java, Swing, FitNesse, Bond trading). For example, once you understand the underlying principles of programming, moving from one programming language to another is no such a big problem. So in agile teams you really need the long term skills and deep understanding.
Short term skills are project specific and can be relativly quickly trained.
Skills can be broken down into several categories:
- Development: Design, Programming, Build, Integration, Testing, Technical (Middleware, Database)
- Management: Planning, Enforce ‘process’, Conflict Management
- Customer / User: Requirements (Stories), Acceptance Test, Business domain knowledge, user manual
- all of them overlap in some places
- Plus: collaborate and communicate
Where do these skill sit in the organizational structure? So we have the management level and agile team level, but there’s also the need for a place to put specialist skills (like security). As well, we apparently need also non-team specialist testing skills. This very much reminds me of codecentric’s current organization with agile teams and competence centers (one being Agility and Agile Testing one of the core topics!)
The testing skills that you need within the team are basically the same that you also need in traditional projects: test design, exploratory testing, test tools, TDD, etc.
How are the skills distributed to the roles. While it might still work if you only have developers in the team, because they can take on also other roles, things can get complicated if you for example only have testers and business analysts (personal comment: are there really such teams?!)
- Management: Scrum Master, Lead Engineer
- Development: Designer, Programmer, Tester
- Customer: Business Analyst, Tester
Testers can not always program (Reid said that), so depending on the testers background the team of testers might acutally work or not. What if you don’t have a Scrum Master, because you have a project manager, who cannot let go, and don’t trusts the team? According to Reid, the cross-functional team member is a myth, but a great vision to aim for.
So what capabilities (not skills!) does a Scrum team need? on start-up it’s suggested that 2 or 3 of the team are both competent and experienced in agile, because they need to spread the skills. You need a good mix between experience (in terms of time spent in the industry) and skill level. Agile teams self-optimize to get tasks assigned to the team members, who can best do the job. Agile teams do hide “nice but dim” characters from management, but do not tolerate clever but selfish non-team players. In the end, no-one can hide from the other pigs in an agile team, much unlike in traditional development.
How are Scrum teams organized? Certainly not hierarchically. but for example in pairs. You normally have the roles of Driver and Navigator, while the Driver is the one who is learning (and typing), and the Navigator has the expertise and can transfer the knowledge. Another model to use is mentor/apprentice (think Dumbledore/Harry). Example pairs are BA/Tester, Developer/Tester, BA/Developer, Tester/Developer. Reid recommands to rotate the pairs only if really needed, if somebody needs some specific skills of somebody else, otherwise you might end up working with somebody you don’t like. Not sure I really agree with that, the whole team should be set up so, that everybody get’s along with everybody else pretty well, so it’s also a question of how you decide who belongs to a team, that’s not only a skill-based decision!
What if you need a skill in a team, and don’t have it in your team. Here are some ideas: new staff, contractor training, coaching. Team should be empowered to organize this for themselves. Beware of contractors going native, get rid of them, as soon as the skill is transferred. If you don’t you are paying them more than your own employees but they can only do the same work, have no more skills to transfer.
Quick show of hands who is certified by ISTQB – quite a lot are even advanced certified!
How to motivate team members? Certainly not by pay (so true!). You can motivate by design the job properly, for example with these factors as identified by the Motivational Potential Score. Any score below 60 should not be carried out by a human. So which are the most motivating test related jobs? The take-away is that the score is generally higher, if you are on an agile project, except for the Business Analyst, because they think they are very important people in traditional projects, and now they are just part of the team. The increase from traditional to agile is about 25%. (I will blog more about motivation and Scrum in the future, so stay tuned).
Reid finishes with the conclusion, that it feels good to be on an agile projects. And I can ful-heartedly agree on that one!