I recently spoke at the Agile In the City London conference. As well as watching a number of great presentations, I also was lucky enough to be able to give two presentations and I’ve shared the slides below.
Category Archives: team
Creating a Team Charter
Having your team all working towards a common set of goals is extremely important. However, as leaders and managers we can sometimes get far too hung up on what needs to be delivered and forget about who is actually doing the work. Forgetting about the people and focusing only on delivery goals may get you to one particular deadline but failing to build the team effectively and align them around a common set of principles will rapidly cause longer term problems. A team charter can help prevent this.
At it’s heart a team wants to perform. People want to do good work; after all, feeling like one has not done the best one can possibly do is not a good feeling and as humans we naturally want to feel good. I like to sum this up like this:
Your team are a group of awesome people who want to deliver value. Your job as a manager is to enable them to do that.
So how can you help your team to bond around common goals, and ensure that these are not purely focused towards delivery or individual achievement? One way is by working with them to produce a team charter.
What Is a Team Charter?
A team charter is a set of principles that the team live by. It should be produced by the team, owned by the team, and be visible to not only the team, but also all those who work with them. It defines who they are and how they like to work.
In short, it’s the team’s rules of the game.
When everyone understands the rules, were part of defining those rules and as a team they own those rules, then the team is stronger.
A Team Charter Workshop
I recently organised and ran a workshop with my team in order to produce a charter. For some background, we consist of four different sub teams, each with around 6 people in them. The teams are cross functional software engineering teams, wth developers and testers, plus they have the skills and experience to push software live and build and maintain our infrastructure. In short they own our products from cradle to grave.
The Workshop
Starting Point
It was important first to set the scene and explain to the team what a charter is and why having one would be a good idea. A charter should be simple and so should how you explain one. Here’s how I explained charters to the team:
- It’s the ‘rules of the game’
- Helps us have a team culture of safety and confidence
- Manages our expectations of others
- Can include practical things
- Is short and snappy so that we can remember it (7 items is perfect)
- Will go on the wall so everyone can see it
Examples
I thought it would help to give the team an example of a charter. I’d heard Stephanie Richardson-Dreyer talk at a tech meetup at MOO a few weeks beforehand and she gave me the idea for the charters, and had fortunately also written an excellent blog post on the subject based on experience from GDS. I recommend reading it – her team’s charter looked like this:
- tech support is a learning experience, you should aim to learn more about how GOV.UK operates during the week
- work together, be inclusive and don’t leave anyone out or alone
- it starts at 9:30, be there
- feel free to go to essential meetings, but tell people ahead of time and see item 2
- make small improvements to make it better for the next team (e.g. documentation, automation)
- there’s no such thing as a stupid question
- help others and be patient – not everyone knows the same things
This was a great starting point and example for my team.
Getting the Team To Think
After some warm up ice-breakers then it was time to start thinking about what should go into our charter. While it could have been productive to jump straight to getting the team to think about what defines them as a team, previously I’ve found this is not always the easiest thing for them to do, and jumping straight to the solution doesn’t always get the best results. Sometimes trying something different helps people to think and come up with ideas more easily.
So I flipped their thinking around. Instead of thinking about what would define us as a team and what a good team would look like, I got them to think about the exact reverse.
What Would the Worst Team In the World Do?
Reversal is a popular problem solving technique and one that I’ve used on numerous occasions. I find it works for me. And sometimes, thinking about worse case scenarios can be fun. So the team were encouraged to think about the characteristics of unsuccessful teams then:
- Discuss them in small groups
- Group them into categories:
- People
- Processes and Comms
- Delivery of new features
- Technology
- Stakeholders
- So we would not get too many items then the teams were encouraged to dot vote where there were more than three in a category, to get the three the team thought were the most important
We then got the teams together and each team played-back their thoughts to the whole team. It was fun. We clearly knew what bad looked like 🙂
And Then Reverse
This is then where the reversal came into play – the teams were now encouraged to take their ideas (and any they had updated as a result of what they had heard from other teams) and note down the characteristics of successful teams instead. We encouraged them to think about their own context and the overall team, and how they wanted to work together and be recognised by stakeholders and other teams.
Bringing It Together
Once the teams had reversed their ideas we brought the ideas from each group together. A group discussion enabled us to find the commonality, discuss each theme and agree on importance. The result was a number of themes, one per post-it note, on the board. There were a lot of ideas.
Now it was the team’s turn to agree on what the most important items were to them. These would be the one’s that ended up on the charter. So another dot vote was called for. Each team member dot voted on their top 7 characteristics of our team.
The Result
We have our team charter. It looks something like this. It’s framed and on the wall for everyone to see. It defines us as a team to each other and to those we work with.
And when the time is right we’ll revisit it and update it if circumstances change.
Should Your Team Have a Charter?
I think so. The exercise of producing a charter brings team’s together and helps them bond around common goals and principles, and shows that the most important thing is the team. When new people join the team it helps them to understand what defines the team and what’s important. When new teams work with us then they can easily see what makes us tick.
Why not try a produce one with your team?
Want To Learn More?
I found these two blog posts very useful when learning more about charters and preparing for the workshop with the team:
- How we improved Technical Support at GOV.UK
- Why creating a Team Charter is so important for high-performing teams
Experiences Of a Testing Bug Bash
I’m working in a team, that’s developing a mobile application and back-end, that does not have any testers. We didn’t plan it that way, but temporarily, that’s just the way it is. While I can add my testing skills and experience to the team, that’s not the primary reason I’m there, and so I’ve been looking at ways in which the whole team can help to contribute to a quality product.
It’s been interesting. At first, when our tester left then nothing happened. Like nothing at all, tickets moved over to the ‘Ready for Testing’ column and there they stayed. Immobile, ignored and unloved. It was as if all eyes were to the left, where the fun stuff for developers was, understanding designs and coding. Although there are unit tests and some automated integration level tests for our code it clearly wasn’t enough.
Session Based Team Testing – A Bug Bash
I’ve used session based testing in the past when I managed test teams, and have found it to be a very useful way of breaking exploratory testing work into understandable pieces, and distributing that work out to the team. James and Jon Bach explain the approach far better than I can. Ministry of Testing have also got an excellent resource on SBTM.
Having read some articles from people who had broadened their approach then I thought I’d take the session based testing concept and roll it out to the whole team as a bug bash.
The key point for me was that any sort of session had to be fun. Initially I feared that not all the team were going to see the full value of such a session since it wasn’t development work per se, so keeping the approach light-weight was key. The ideas for our first bug bash had formed.
Organisation
Getting away from the everyday work was important so the bug bash took place in a separate room, close enough to our team area that it was quick to pop out and pickup forgotten devices, etc but away from the interruptions that phones, etc provide. I made sure we had enough phones, tablets, post-it notes, pens and cake to keep us going. I also brought in some popular testing books and the Test Heuristics Cheatsheet from Elizabeth Hendrikson, in case people needed some inspiration.
We use JIRA as our project management tool and since we were testing a whole Epic then it made sense to break the testing down on a story by story basis. Working with our lead developer, we took each Epic in turn and used that to form an exploratory testing charter stored as a Google doc. You can get an example version here. Using charters enabled us to define the boundaries of the testing; ensuring there was not too much overlap. It also meant that people who were not so familiar with the story were able to quickly learn about it, and areas to test, without needing to spend time reading stories and Epics in JIRA.
So, the charters were ready, the room was ready and the people were ready. Time to start.
The Bug Bash Session
We decided on two 45 minute sessions with a tea break in between. The whole team attended; PO, designers, UX, developers and myself. Everyone was a tester for the afternoon. We agreed who would pickup which charters and made a start.
I made a Google doc in which people could record potential issues which I kept projected up on the wall throughout, so that we could all see the progress that we were making and the issues that were being raised. I encouraged the team to add screenshots as well as text and this really helped to make things clear and to prevent duplicate issues making their way into the list. Discussion was also key to the success of the session; having everyone in the room at the same time meant that potential design issues could be shown to designers straight away for review.
The lead developer for the feature was also present, not testing but helping to explain architectural and development decisions, and also to fix some bugs on-the-fly.
The session went well. We got all the charters finished and the session concluded with a quick retrospective.
Retrospective
What Went Well
Charters give structure and prevent misunderstandings
Having structure was critical to the bug bash, given that it was a new activity for the team, and they were not experienced with exploratory testing. It also meant that we got the most from the session and people were not all testing the same thing.
Hints and examples in charters are good
By including examples, and ideas on areas to test, people had a guide to start them off. Given that they were not experienced testers then this really helped.
It is good to have charters split by story
This meant that it was clear what was to be tested and there was a clear link back to the project management tool people were used to.
Some of the bugs were fixed during the session
This clearly shows the value of group pairing for me.
What Could be Improved?
Make the charters simpler
I had hoped we would get some data on setup time and test execution time so had added that to the charters but it confused most people.
Make the process of splitting up the charters and recording who is working on each one, simpler
Although it as clear to them which charter a person was working on, we didn’t keep a visible record of who was working on what. Next time I’ll write this down and pin it up on the wall.
People could swap charters halfway through the session to give multiple points of view
For each 45 minute session one person would pick up and test against a charter. Swapping round could add value and a new set of eyes onto the area.
Comments
Aim to do this for all large stories
This was great to see since it showed that the team saw the value in the approach.
Consider pairing
This will be our next step for the Bug Bash sessions. Pairing people up could help to add more value by giving multiple viewpoints.
Going off charter was a good thing
Some charters were bigger than others. People naturally started to go off-charter once their charter was done and this gave multiple viewpoints across the whole feature.
Being away from the desk is a good thing
By being one team, with one goal, isolated from our day-to-day activities, we were able to effectively test and find many issues in the feature, without the usual distractions that break concentration and flow. Having lots of cake also helped 🙂
Conclusion
We will definitely do the Bug Bash again, and I see it as becoming a really important part of our delivery processes, even when we get a full time tester back on the team. It really helped everyone to understand the feature, to explore it and to test together, giving multiple viewpoints on potential issues.
With some guidance the whole team made a great contribution. I’d encourage everyone to try a similar approach,
Exploring An Existing System
Recently I’ve been reading Elisabeth Hendrickson’s excellent book ‘Explore It!’. For anyone who has an interest in exploratory testing it’s a must own. I wish I’d discovered it earlier to be honest, since it gives so many useful hints and tips, as well as confirming that the ways of working that one has chosen are also recommended and used by others.
As well as using it for my own learning, I’ve been slowly going through the book and working out what parts I can use in the regular lunch and learn sessions that I run at work. While we practice exploratory testing, in fact it’s the cornerstone of our sapient testing strategy, there are some areas where I feel we could take approaches that could benefit not only testing, but also the wider business.
Working With Legacy Systems
We frequently work with legacy systems and so one chapter that was of immediate interest to me in Elisabeth’s book concerned exploring an existing system. When one has an existing system to test I find it’s all too easy to become primed by what others have already discovered, and to fall back on existing test cases (whether physically written down or in someone’s head). This can bias you, resulting in less effective testing.
Elisabeth makes the point that an existing system may well be unknown to the tester, but also may well be unknown to the whole team, or at least contain parts that are unknown. While the software fulfils a business need, how it actually goes about doing so may be less clear. That makes it ideal for exploration.
Recon Testing
James and Jon Bach like to call the initial exploration of an existing system ‘recon testing’. I like this term, by taking an initial session to explore and discover the basics of the software under test then one can then plan more effectively for future sessions, and write future charters in order to drive those plans (if you want to know more about the concept of session based testing and how charters fit in with this then have a look at James Bach’s explaination). Recon sessions help to map the territory and give insight.
During a recon session you can learn a lot, but the most important areas to ensure that you have gained insight into are:
- The ecosystem in which the software under test resides.
- Touchpoints to other systems.
- Variables (things we change or can change).
- Obvious vulnerabilities and potential risks.
Our Training Session
During our training session we carried out recon testing on the Staples ‘Easy’ button, and a standard service bell. This no doubt annoyed those in the room next door 🙂
By starting training with something simple, and not software based then it’s easier to pick up and learn the basics of a new technique without bias or the complication of software. We then compared our experiences, testing, (and the charters produced), with those that the Bach brothers produced when they carried out an exploratory testing exercise using the same product. Fortunately for us, their session is available on youtube, so it was an excellent addition to our de-brief. In it they explain the different testing techniques they use, and why. It’s well worth watching.
Enough Recon Testing?
One area to focus upon when conducting recon testing is whether one has conducted enough recon testing. Fortunately ‘Explore It!’ has this covered, recommending you ask yourself questions about the system that you have been exploring. If you don’t understand what the system does, how input and output works or how the environmental configuration affects the system for example, then it’s probably time to think about more recon before you move into more focused test sessions. Fortunately for the ‘Easy’ button and bell testers, (and those sitting near the meeting room where we had the lunch and learn), then this was not necessary 🙂
A Useful Addition
Recon testing is something that I think we’ll find is a really useful addition to our strategy. I’d certainly recommend that you check it out, and that you check out ‘Explore It!’ which contains much more useful information and techniques to use in your exploratory testing. I’ll certainly be using the book to inspire some future training sessions for the team.
Incentivising Community Engagement?
I firmly believe that in order to be as effective as possible, testers need to engage with the software testing community. Learning from others, particularly outside of the companies where we work, makes us more rounded and better informed individuals. It enables us to inspire ourselves and our colleagues in ways that we could not otherwise.
Recently I’ve been wondering why more people do not engage with the community. What is stopping them, and how can we all help change this? We can explain how brilliant the wider community is, and we can give examples from our experience. We can send people to conferences and email round blog posts. What is that does not work?
What do we do about those within a team who do not want to interact? Those who do not see it as a good use of their time, and are not willing to spend time on community matters, even if that time is given to them by the company. Should we incentivise people to do so? At least in order to push them in the direction of the wider testing community, where hopefully they will get hooked? Or should we do the opposite? Is it a valid idea to make community engagement a part of people’s role description, and therefore penalise those who hold such positions and do not exhibit such engagement?
Or is there another way of persuading everyone that the software testing community is key to their personal development? I’d be interested to know what you think.
Testing As An Activity
Recently I’ve started to come to the belief that we can solve a lot of our problems if we just start to think differently about testing. If instead of thinking about software testing only as a distinct discipline, we instead to start to think about it as an activity. After all, testing is just that, an activity. It’s something we do. Something we’d love others to do more. James Bach likes to define software testing as a performance, and what is a performance without some activity to perform?
Once we start to think of testing as an activity then it matter less that it’s not always testers who do it. Everyone in a team should test, it’s just that the tester role can be where the expertise lies, and where the test coaching comes from.
Think of all the problems we can solve if we think like this.
!(Certification) = !(New Job)
There’s a lot said in the testing press and blogs about certification. There’s some well known haters of ISTQB and a few, albeit quieter, exponents. There is of course the training providers shouting loudly about their guarenteed pass rates, how their courses are faster than all the others, and how you won’t survive in testing without the qualifications that you can get from them. Is certification as important as they say? I’m beginning to think that maybe it is, but not for the reasons their sales people present.
Firstly some background. I’m ISEB Foundation and Practitioner certified. I enjoyed the courses which I did with the excellent Grove Consultants a few years ago. OK, the exams were not fun but the courses were. I felt like I learned something and I went along because I wanted to learn. The qualification was good, but secondary. I felt it wasn’t essential. I still feel this way, I’m not an out-and-out ISTQB basher but I feel things are beginning to go too far.
Once I became a team leader, and then a test manager I continued to send people on the courses. Some didn’t want to go, but I felt it was important for them to learn something new, and more importantly to learn the same way, and using the same information, that the rest of the team had already learnt. It gave some consistency. That was useful.
Fast forward a few years. I now have a team of testers and delivery ops people. Times have been hard and training has been hard to come by, by the time these people joined the team there was no training available that would lead to the ISTQB/ ISEB certifications. Has the quality of what we do decreased? Well, no. If anything, we’ve gone out and trained ourselves, trained ourselves, and updated our ways-of-working in even better ways. We are still consistent in our approach, and as a bonus, some people can now train others. Also a good skill. Not getting the ISTQB training has annoyed some, whilst others weren’t bothered at all.
Now my team and I find ourselves in a new situation. Soon we will all lose our jobs as R&D is moved overseas. Suddenly the issue of certification slams itself forward again. Most of the job ads scream ISTQB certified, for recruiters it’s almost the first question asked “Are you ISTQB certified?”. How have we come to this?
I think a lot of the testing community is stuck in a vicious circle. If we get lazy with our recruitment then we quickly fall into a trap of just putting “ISTQB certified” in the “Essential Requirements” section of our job ads. We are the ones who caused the recruiters to ask “Are you ISTQB certified?” Certification within the industry becomes self fulfilling. And those of us recruiting testers don’t necessarily get better testers.
So what’s the solution? More certification? I think all those of us who recruit for software testers need to re-visit what we look for in a tester, to adjust our outlook and our requirements so that we are trying to find those who are good at what they do, not what they have studied. A few years ago I used to run a written interview test for candidates which was based on the ISTQB syllabus. Many of those with the qualification failed.
And to my team, without certification and needing to find new jobs? I’ve sent them on ISTQB courses. It’s only fair, they need the best start they can get in their job searches. But if I find myself in this situation again then I hope that it’s not this way….
* For those of you without any programming knowldge – ! in the title means “Not” 🙂
KanBan for Management
Finally, a post on KanBan 🙂
I’ve been running teams who have been using KanBan for a few years. We find it is a really useful methodology to use, especially for our maintenance and dedicated testing/ release teams. Being a little lighter than Scrum, it enables us to quickly re-prioritise backlog items; ideal when you don’t know when the next Showstopper bug is going to come in.
Recently I’ve started to take things a little further with a pilot in my management team, which consists of test managers, defect managers and product owners who are driving various software projects to completion, mostly in the maintenance and productisation phases. The pilot involves using KanBan to run the team and prioritise the various actions and items that we need to drive forwards.
We wanted a lightweight approach to the toolset, so rather than go for a heavy tool, or something online (company policy – nothing on 3rd party servers), we picked SherePoint. Daniel Roots excellent guide on how to setup a KanBan board in SharePoint has been invaluable and what we have now certainly fits our need. OK, so you may not want to use this to run a detailed software project without some adaptation, but for prioritising and driving the management backlog then it works just fine, especially when tasks are sync’d with Outlook.
Changing our way-of-working was, as usual, initially difficult, but quickly the benefits of being able to see what everyone was working on and where it was in the cycle became apparent. Figuring out the work in progress limits for the team was a challenge, given the varied nature of the different roles, but we found that, more often than not, our tasks relied on each other, and therefore our ‘internal’ WIP limits did too. This meant that the team did have a natural velocity and this could be used to set WIP limits accordingly.
You may wonder whether this approach sounds a little heavy-handed? I’d argue that it does not, simply because you always keep an action list or backlog for a management team. Maybe you have tried to colour-code it or tabulate it, in order to make it more visible? You are halfway there. Why not go the full way and try KanBan for it instead?