Here’s an always challenging question: how are great software development teams formed? Managers, scrum masters, we all struggle to create continuous progress within our groups. And we know that there’s lots of factors in why that is – communication, skills, individual quirks. Sandy Mamoli and David Mole tells us that self-selection is the answer, and their book, Creating Great Teams (How Self-Selection Lets People Excel), provides us with the details.
Here are some notes from the book:
- Fundamentally, two factors determine whether a group will forge itself into a team: 1) Do these people want to work on this problem? 2) Do these people want to work with each other? Neither a computer program nor a manager can answer these questions. Only the employees who will do the work can.
- Self-selection is a facilitated process of letting people self-organize into small, cross-functional teams. Based on the belief that people are at their happiest and most productive if they can choose what they work on and who they work with, we think it’s the fastest and most efficient way to form stable teams.
- The best motivators are autonomy, mastery, and purpose. Autonomy provides employees with freedom over some or all of the four main aspects of work: when they do it, how they do it, who they do it with, and what they do. Mastery encourages employees to become better at a subject or task that matters to them and allows for continuous learning. Purpose gives people an opportunity to fulfill their natural desire to contribute to a cause greater and more enduring than themselves.
- No one chooses to work on more than one team or project. Time and again organizations fall into the trap of optimizing resources rather than focusing on outcomes. People often believe that multitasking, having people work across several projects, and focusing on resource utilization are the keys to success, when in reality they’re not.
- People communicate face to face. There are barely any discussions about process or how to communicate. Team members just talk and coordinate and collaborate as needed. Things are much faster that way.
- In the spirit of letting people control their way of working, we never mandate whether a squad should run scrum, kanban, their own special creation, or a traditional way of working. Following Daniel Pink’s principles of motivation, one of the key forms of autonomy is being in control of your processes. Giving people autonomy over who they work with should be extended by letting them choose how they work together.
- There are two agile practices we believe should remain mandatory: retrospectives and physical story walls (if you are co-located).
- It’s fair to say that sometimes employees don’t want to work with each other. And that’s okay. People know whether they’re going to gel in a squad with a particular person, and if not, it makes sense they would choose not to work with him or her. Self-selection, unlike management selection, allows them to make that choice.
What does our team actually want to accomplish this particular sprint?
Do I know my teammates well enough?
Does everyone in the team feel safe working together with each other?
Can I rely on everybody in the team?
What does a user story mean to us?
Do we even need tickets in order to perform our best work?
Do we truly need this specific document to move forward?
How can I help a teammate feel good with the work he/she is doing?
What’s the minimum amount of input do we need in order to start?
What’s the 20% of activities that contribute to 80% of outputs we desire?
Do we believe in what we are building?
Which rules, in reality, help us become the best versions of ourselves? Which don’t?
Whenever there’s an issue in production that I can’t seem to replicate quickly in our development environment, the problem reminds me that I have not tested everything in our software, that there are gaps in the model I’m currently using to test our application. The mistakes I make in diagnosing a problem helps me improve but also tells me that I have not explored our systems enough, or that maybe I have forgotten something that should help me test, or that perhaps there are modules that have changed since I last visited them.
More importantly, such scenarios prompt me to remember that I literally can’t know or test everything, that I need help in these cases, and that is precisely why it takes a whole team always extending continuous effort to bring quality up to a point where customers love our app. That means everyone’s testing skills need to stack up, salespeople, testers, programmers, product owners, everyone.
What: Create executable specifications for an ongoing project sprint. Executable specifications are written examples of a business need that can be run anytime and acts as a source of truth for how applications behave. It is a living documentation of what our software does, and it helps us focus more on solving the unusual and noteworthy problems instead of wasting time with the ones that we know we shouldn’t have been worrying about.
- Join a software development team for one sprint duration.
- Discuss project tasks for that sprint with everyone.
- Ask about requirements examples and create executable specifications for those tasks as the application is being written.
- Refine the specifications when necessary.
- Continuously update the specifications until they pass.
- Keep the specifications running on a preferred schedule.
Why: To see if writing executable specifications alongside development is feasible during the duration of a sprint.
Limitations: Tester writes the executable specifications, programmers work as is.
- Writing executable specifications can be done during actual app development, provided that tester is experienced with the tools for implementing it and understands well why the need for such specifications.
- It is of course more beneficial if everyone in the team learn how executable specifications work and write/run the specifications, and why the need to implement it.
- It will take quite a long while before executable specifications becomes a norm in the existing software development process, if ever. This is a function of whether everyone believes that such specifications are actually useful in practice, and then building the skills and habit of including these specifications in the team’s definition of done.
It’s easy to learn something when you’re genuinely curious about it, no need to look for any other external motivation. On the other hand, it’s terribly difficult (often a waste of time) to teach something to someone who is not interested in the subject at that given point in time.
Software tester and programmer pairing in bug fixing or feature-writing situations is supposed to be a fun experience for both parties. Either of them getting frustrated at what they’re doing means something is blocking them from being able to perform well as a duo. Maybe they don’t know enough about the needs of the other person or how to fulfill those needs, maybe they don’t understand enough about the thing they’re building or how to build it in the first place.
If the people using the software have qualms regarding a feature update, maybe there happened to be a miscommunication between clients and developers about what feature the customers really want built. Solving that communication problem matters, maybe more than writing feature code quickly, definitely more than pointing fingers and blaming other people after the update’s been released.
Testing with deep understanding of why the application exists the way it is and how features actually work in both user interface and code helps us perform our testing more effectively, especially in situations with time constraints.
Pair testing happens more often than I initially thought it does, only not as explicit as how I imagine it happening.
For whatever you wish to be master of, it pays to have mentors, people you follow and respect and trust and provide feedback. If there aren’t any in your place of work, find them online.
The agile community at NewVoiceMedia recently wrote a book for Scrum Masters and for everyone who is looking to improve their knowledge about what scrum masters do. Their output during a hackathon, within 48 hours, the “So You Want To Be A Scrum Master?” ebook available at LeanPub, contains great ideas, stuff that I’ve learned through experience since I had the opportunity to become a scrum master myself, alongside being a software tester.
Some takeaways from the book:
- Maximise the time a team member spends doing what they love, and less thinking about how they should be doing it.
- Being a Scrum Master can sometimes come with the misconception that you are there to tell people what to do. That is definitely not the case. We’re not in the business of telling people what to do and when to do it and we’re not in charge of anyone.
- Make problems more visible before trying to point them out, and before offering a solution.
- Your job is to help team members stick to their commitment – we all find building new habits a difficult thing to do. You are protecting the team from themselves, from the tendency of human nature to pull each of us off the path we actually want to be on.
- To turn around a team, work with individuals in the team and listen to them.
- Always help. But only when your help is requested or when your offer of help is accepted.
- Not everyone who truly believes they are agile knows what it really means. They need battle scars of having tried lots of different things and lived through the consequences.
- Just because your label is Scrum Master you do not have to only follow the Scrum methodology to the letter. In fact, your job demands that you do not.
- Let the team fail.
- The end goal of a Scrum Master is to effectively make themselves redundant for their team.
Is there ever a specific software development process that works everytime, for all kinds of teams, on all sorts of development projects? If there is, how is it done? If we don’t know, do we need to create one or do we let each team decide and use what works for them?
Does it matter that teams are very productive as described by numbers and documentation, or should we focus on building team interaction and collaboration?
Do we write and test software for the sake of a manager’s approval?
Is it worthwhile that a team continues to use the latest trending process, or a comfortable legacy one, even when they know that the process has already failed them many times over?
Is it difficult to trust a team when you don’t know exactly what they’re doing but you understand that they deliver their best work every time?
Isn’t it a manager or a leader’s responsibility to believe that their team is capable of doing something great, to find and understand the needs of the team, and to help them in gaining those things? Isn’t it our job to guide them in becoming self-sufficient? Should they serve us, or should we serve them?
How does one appropriately evaluate team performance?
Does diligently performing estimation and daily stand-ups and writing user stories and going to meetings that take all day means we’re agile? Should we only continue to follow structured procedures that other people tell us to do or should we think about them deeply and see for ourselves whether they have merit on our team, experiment and decide on our own if they work?