Testers keep telling me that testing is not just about breaking things. They also tell me that they are there to help the team think rather than just point out the dumb things they have done in the last sprint.
That’s probably all true. But I have been asked by someone to give them a mechanical set of steps to do when you are an agile tester. That way they have a starting point when they join an agile project.
We all want to be more customer focused and closer to the customer. All that sounds great, but it assumes that we have some idea of who the customer is and what they want.
So maybe we should list our customers by customer segment. Let’s see – I am James and I am a customer of your product. I live in Sydney and I am Australian. But unlike most Australians I am a bit short and not very good at sport.
Now you know me really well you can flog your product to me. You can even build a persona around me (see this link). If you are more sophisticated you might even start doing empathy maps and value proposition canvases.
But the point is not to build a detailed picture of me. Knowing I am tall or short is nice and knowing I am Australian might tell you about what I want in a product … but just as likely it won’t tell you how to make a product relevant to me.
Rather – we want to know what things I want to do (ie my “jobs to be done”). So let’s see what that means.
I have included some agile is awesome videos. But to be fair, agile is not always awesome. So here are a couple of great videos that show the pain of going agile – from the point of view of an passionate agile PM. The first video shows his attempt to go agile in a large organisation – “I want to run an agile project” I want to run an agile project Then I guess he resigns, because now he has joined a consulting company who want to run all their projects agile. Hopefully life will be better, but sadly … … Continue reading Agile is actually really hard videos
When a small team is working with great rhythm, it often looks like there is no upfront planning or design … and sometimes that is in fact the case.
But more often than not, that small team is integrating into an existing “ecosystem” of products, services, internal processes, team structures and IT systems. And generally speaking the small team is building something complex that needs both some foresight and some willingness to learn and improve the system’s designs customer expectations or company direction change.
I am supposed to be doing some blogs on scaling agile, but I was distracted by being very lazy.
But sort of on topic – people often ask me “what are the roles in agile and what are their responsibilities?”
I usually say there are three roles – product owner, team assistant and team member. People ask me about Scrum Masters and I often say that it is really “Scrub master” for “person who scrubs up for the team”. But whether I call them iteration manager, team assistant, scrum master or something else, it is a key role.
Then people often ask about testers and BAs … and I say they don’t really need them in agile, unless they do need them. This seems to annoy people more than help them but I think a lot of agile coaches are giving people the same generic answers.
So here is a slightly different answer.
Agile teams are self organising so the team might invent different roles based on their own context. Similarly, the team might need front end developers, or llama herders or configuration experts, but agile won’t tell you that … because the roles in your team depend on the kind of work you are doing.
In a typical project, I often find myself looking to fill these roles, even if I have people performing more than one of them:
I was in two related conversations recently – what is the secret to being agile (mentioned here).and “how do you scale agile to work in big organisations”.
I will publish the secret to scaling agile soon, but I realised that there is one danger that you need to be aware of before you start to scale – heroes can be great for small teams but they don’t scale well.