I’ve worked in many organisations undergoing an agile transformation, both as part of the development team and as a ScrumMaster. Over the years I’ve seen the behaviour of the development team have an impact upon the agile journeys of organisations. Given agile was designed by and for developers, its they who have the most to gain from transformation. The development team needs to understand how they can help the transformation be successful. Here are the top ten things that the members of the development team can do to help ensure that success.
Have frequent 121s with your manager
One of the things that surprises people when they enter management is how little power they really have. In as many ways that they know more than they used to, they also know far less. Those promoted to managerial positions were often top of their game in their technical specialism. Suddenly, they realise they know nothing about people management, and rarely do they receive the support they need. At this point it is only natural for them to take a command and control stance. The manager might believe they’re better and more knowledgable than the technologists they left behind, or maybe (and even worse), they know that they are not. It always surprises me to hear a manager say that they don’t trust an individual or team, and unfortunately I’ve heard it more times than I care for.
To combat the fear and lack of trust management experiences, the team must help the manager to not be afraid. If your manager doesn’t setup 121s for you, set them up yourself. Go to them prepared; have questions to ask and information to pass on. Not only will this help your manager, it will also help you. By ensuring that your manager has a chance every fortnight to find out all the amazing things that you’re doing and feel as though they are contributing to your success you will get a better review at the end of the year, and that means a better pay rise and bonus for you.
Believe you’re empowered by acting like it
The great feminist, Gloria Steinem, said that Power can be taken, but not given. The process of taking is empowerment in itself. I think that this is true in any power struggle, and not just in gender equality. I spend much of my time as a ScrumMaster telling the development team that if they think they’re best placed to make a decision, then they should make the decision. If you go to your manager with every problem, then they’re going to see you as a problem and incapable of making decisions.
Having frequent 121s helps you to be empowered. By telling your manager the competent decisions you’ve made, they’ll become more comfortable with you making decisions. By asking questions of your manager, you can show that you think they have something that you need. Go to your manager telling them about all the problems you’ve dealt with, so that they didn’t have to.
Use Outlook like the rest of the business
When I was a developer, there were days when I wouldn’t even open Outlook. Most days I didn’t receive emails that required my attention, and if I was lucky I had one meeting a week. This isn’t how the rest of the business works. Most non-developers receive 50+ emails a day, and I’ve known people who have so many meetings in a day that they’re double booked for most of it. As a ScrumMaster I make sure that I have 121s with everyone on my team each sprint, but more often than not developers do not turn up on time.
I understand the annoyance that interrupting the flow of creating software creates, but it is essential that everyone – including developers – behave like business people. I don’t expect a developer to sit watching their email and calendar all day, but I do expect them to build it into their routine. Start the day by checking if you have any meetings. After a break, check to see if anything needs your attention. Use calendar notifications to make sure that you don’t miss, or are late for, any meetings.
Software Craftsmanship is a growing movement within the agile development community. I’m thrilled by this movement, and only saddened that I didn’t find out about it until after I left development. So many development teams face pressure from management to deliver quickly without a concern about quality. I understand that this pressure is hard to resist, but it is up to every developer to do what they believe is right. It is up to each one of us to ensure that we do our best, and blindly following orders to do anything else should not be acceptable. Software is so vital to our every day lives that all of us involved in its creation need to understand the significance of what it is we do, regardless of the product.
As a developer I worked on a range of software from social housing allocation to gambling. On every product I understood that everything I created had an impact on many peoples’ lives for better or worse. I had a rather unsuccessful development career in part because I tried to stand up for what I believed was right. The only thing I would change about that time is the amount of tact that I employed. I hope that every developer and manager take these responsibilities seriously. Using the software craftsmanship manifesto could aid discussions between developers and managers so the team receives the time they need to write quality software. (Sign the Programmers’ Oath here)
Keep the manifestos fresh in your mind
Both the agile and software craftsmanship manifestos are key to everything we do in our desired new world order. To help us stay on the path, we should keep the values and principles fresh in our minds. I hope that everyone working in agile has read the manifesto at least once. As a developer I had read it once, but I couldn’t tell you anything about the manifesto.
As a ScrumMaster I’ve made a concerted effort to learn the agile manifesto. I’m still not there, but I have a far better understanding now than when I was a developer. I try to make sure that the reason behind everything I do can be traced back to the manifesto in some way. The only way I know to do this is to keep reading the manifesto so that I don’t accidentally stray away from inspect and adapt, iteration, and incremental improvement.
Support and challenge the Product Owner and ScrumMaster
The Product Owner and ScrumMaster are there in part to serve the development team. These are completely new roles, and people naturally try to map roles they already understand onto them. This often means that the SM behaves less like a coach and more like a line manager, and the PO behaves less like a conduit and more like a PM.
If the PO hasn’t helped create user personas and the team thinks it would be helpful, then ask to create them. If the SM hasn’t worked with the team to help them understand themselves, then ask what they can do to support the SM in their journey. The team should make it clear to both roles what they expect, but also help them achieve it. If you’re lucky to work with people fulfilling these roles well, then support them. When they need your help, give it willingly.
As a contract ScrumMaster, I work with multiple teams in a year. One of the first things I do with a new team is check how many people have pen and paper on their desks, and how many carry them to meetings. We value conversation highly in agile, but that doesn’t mean we don’t need to document them. Every conversation that someone in the team has, should be as though the whole team has had it. If you’re using a system like TFS or Jira, then find redemption in it by updating with any information that you find out that may be of help to the rest of the team.
Not only are notes good for the whole team, but they can be good for each member. When some stray thought pops into your mind and threatens to derail you from the task at hand, make a note of it so that you can return to it in a more timely manner. This is a baby step towards mindfulness, and a useful skill for life in general.
Act as a team
Most of us worked in waterfall projects before we started working in agile product development. It’s therefore no surprise that when we start working with Scrum we do one bit of development, then another, and then test; this time over two weeks instead of six months. That’s not iterative nor incremental development, that’s scrumerfall. By the time a ticket has entered the sprint the whole team should have a good understanding of it, so that they can work on it holistically.
The team’s highest priority is to get tickets from left to right as quickly as possible. You need to do all that you can to make sure those tickets keep moving, even if it doesn’t require your core skill. A ticket shouldn’t start moving until it has a clear path all the way across the board. No one should write a single line of code until the team has planned enough that everyone involved can write a single line of code. There’s no reason why testers can’t be setting up test scripts whilst the developers are completing their part. Individual productivity is not key, team productivity is.
Socialise with the wider business
The Product Owner is there as a conduit between the development team and the customer. The ScrumMaster is there as a facilitator for the development team. Neither of them are there to speak to anyone outside of the team on the team’s behalf. If the team needs to deal with anyone outside of the team – and they do – then the team needs to actively do so. There are two ways to do this; only speak to other people when the need arises, or build relationships with everyone ready for when the need arises. I prefer the latter.
It can feel difficult to build relationships, but it can be as simple as saying hello to others in the kitchen. Remember that the people you see around the office are all on the same side as you and probably have goals that align with your team’s well.
Look after and help other teams
Once you’ve built up those relationships, you often find out that another team is building something that will have an impact upon your team. Connections like this can deliver far more value than can be predicted. In many organisations we see employees report satisfaction with colleagues in their team, and dissatisfaction with colleagues outside of their team. This is hardly surprising as we innately trust those inside our group and distrust others.
To break up this pattern we need to remember that we’re not in competition with other teams. We all rely upon the organisation we work for to succeed, whether we’re permanent or a contractor. When other teams come to your team for support, help them in a timely manner, and with grace and humility. Treat the other teams as you wish your team to be treated. One good turn deserves another, after all.