Recently we launched a new Webinar that describes some of our approaches to software development team management, with a specific focus on improving the productivity of a team by reducing the breaks in developer flow that project managers often impose. In this webinar, we go over our core principles we enforce to make this approach work, and talk about the tools we use to make it happen.
Webinar Transcript:
Hello and welcome to Improving Developer Productivity: Status Updates Without Interruptions. I’m Nathan Stuller, and I’m Development Manager and Lead Software Developer at Unstoppable Software. We’re a software consulting company and we allow our clients to focus on their core business instead of worrying about software development.
In this webinar, we’re going to go through some of the things that slow down software development teams – mainly interruptions – and how we can do some things to get around that and improve productivity.
Now throughout the years, there’s been a lot of things that have improved software development. Things like object-oriented development have increased the level of abstraction, and have allowed developers to focus on the higher-level business problems. Other strategies, like Agile methodologies, have allowed teams to adapt and write relevant software with smaller teams. It makes me wonder, what will the next great breakthrough be?
Now, perhaps the most destructive problem for a programming team is something we’ve known about for a long time – interruptions. We have companies out there like Fog Creek software that are trying to educate the community on the importance of silence in a developer’s office, by putting blog posts out and sharing their office layout and architecture so that people will start the understand the importance of that. Yet still, a lot of startups believe that the most effective way to get people to work is in development bullpens – open environments which can be very loud, with people talking over each other (which does improve collaboration in some ways), but it definitely optimizes for interruptions.
It makes me wonder, is that the next great breakthrough? Just reducing interruptions in the workplace? Can we create better habits to allow us to hold more information in short term memory, so we can reduce bugs and work faster? What if we could solve this with just the available software tools that are out there?
Now the importance and the prevalence of interruptions is not something new – we’ve known about it for a long time. The book “Peopleware” identified this problem decades ago. And yet, we still have the situation where it is pretty common where a manager may pop in and ask, “Hey how’s it going?”, or “What’s the status on this project or task?”. Or, if a team is behind on a project they may all work together in a war room.
Well, if “Peopleware” was right, and developers’ flow states are so valuable, then it’s truly important to reduce these interruptions. Having a project manager ask “So where are we now?” every hour – which then requires developers to ramp back up after leaving the office – basically grinds projects to a halt every time the project manager asks.
So what are some of the things we can do to improve productivity and reduct interruptions? We can use some of the tools that are out on the Internet. The cloud has put a lot of information out online, which helps us to access that information without having to interrupt each other. So, using a host of tools to centralize that information enables an amazingly powerful concept, which we call “Asynchronous Transparency”.
So instead of being bothered by another developer or a project manager, and having to communicate status back to a boss or client, instead you update these central databases. So for instance, at Unstoppable Software, after fixing a bug, we resolve it in our bug tracking software system, and then when someone else wants to see where things are, he or she doesn’t have to bother the developer who was working on this bug, they can just look it up in the system and see an update.
I know this isn’t a breakthrough topic, but we feel like we take it a step further. Our management beliefs are such that we have to have transparency in multiple directions. It’s a key tenant in our approach – it’s especially important for remote teams, and we have examples of this throughout our business. We display a project budget “burn down” to our developers, so when they are going through and closing out tasks, we can show them how the remaining amount of work relates to the project budget, especially since that budget was based off some of the estimates that the developer gave in the first place.
We open up our backlog databases to the client – as I mentioned, we have that central database for our bug tracking software. We can show that to the client so they can have an understanding of what’s going on with the project and where things are. We also send demo screencasts which can be viewed at any time.
We’re trying to empower our team members to get the information they want, without interrupting others who would traditionally keep that information. We don’t entirely eliminate same-time communications – that would be silly – we still get everyone in a room together or on a virtual meeting together from time to time, and we still do daily stand-ups. We also don’t share everything – it may not be appropriate to share all billing rates and customer lists, for instance.
But over the past 8 years, we’ve established a suite of application development tools that we feel work extremely well in our process. We have things like project planning software – like FogBugz or LeanKit. We use time tracking, source control, GoToMeeting, SproutVideo for sharing screencasts. These help us work more effectively with our customers, it works especially when our client is remote or not local. These tools allow Asynchronous Transparency – a guiding principle helping to reduce interruptions and improve productivity.
Let’s get into the strategies for reducing interruptions in flow. First we want to embrace Asynchronous communication. In the words of Brian Tracey, continuous contact is not essential. In other words, if communication is not required to resolve an emergency, and its not completely urgent, then it should be delivered in a way that allows the recipient to access it whenever they need to. In that regard, email can be better than chat or texting – centralized project information can be better than in-person meetings.
So something that we do a lot of times is instead of gathering multiple people all at once for a big meeting or a big demo, we’ll record a screencast, and we’ll put it online for people to view when it is convenient for them. We’ll put a password on the video so it’s not out in the public domain, but that helps for things to be asynchronous, because it sends off the important information, but it doesn’t require a response right away. And we want to keep in mind that the best way to be asynchronous and to have that advantage is to be as transparent as possible. You see, I’m able to get more information if things are transparent and its already out there – I may not even know what information I need to ask for, unless it is out there (Which would then require me to interrupt someone and ask them).
We also break down large projects. We use an Agile iterative methodology. So we separate big projects down into smaller milestones, or sprints. We feel that creates more transparency, and it also reduces risks. The reason we think it creates more transparency is, if you have a big project, and it’s been over a month since you’ve seen any progress on it, or any tangible output on it, then it is really frustrating and you want to ask “What is the status on this?” You’re in the dark and you want to interruption people to get the information. But if you break things down into smaller outputs, then you can see that continuous feedback and you don’t feel like you have to interrupt people.
In our way of doing that with the smaller springs, we can also still use a scientific approach, which we do with estimation and release planning so we can tell when a project will finish with a certain statistical probability.
We also embrace online software, or programming tools that are in the cloud. As a I mentioned we’ve developed a set of tools that allow us to use our Agile process, and we try to focus on the present.
So what are some of the ways that we improve access for clients?
We give our clients access, to FogBugz – our project backlog. In this way, clients can see the status of a project, what remains to be implemented or fixed. We also send those SproutVideo screencasts. We use SproutVideo to host them, we password protect them, and send them to the client to view of their own schedule.
How do we improve access for developers?
We have the same strategy – it works both ways. We store items in FogBugz in our project backlog, and we allow developers to use the tool to estimate tasks and see what’s next. It’s a great centralized tool that allows all the developers on the team to see what’s going on. It provides similar benefits to other tools that are out there for project planning like LeanKit.
WE also use source control – now pretty much everyone does who is a professional developer – we use SubVersion or Git, depending on the project. It allows developers to easily have access to different files, and what they can do is both access the same file while working pretty well not to interrupt each other or have any conflicts if they merge each other’s information back in.
Improving access for managers. Hey, look what’s we’ve found here – we have the item list in FogBugz again! It’s our central project backlog, so this is a great way for managers to see what is still remaining to be done in a project and this piece of software uses something called Evidence-Based scheduling to predict the probability that a project milestone will be finished by a deadline.
At Unstoppable Software, we’ve developed an internal product that is a “Burndown Chart” – that is the tool that maps the project budget against the estimated time remaining on a project. This really helps us because it shows us some of the velocity of our team, and if we are entering into a troubled area on a project, it helps to have a high-level view for our managers.
Lastly, we need to be aware of tools like Slack or chat. There are goods and bads with both of these – Slack allows people to collaborate really well with each other – there are rooms where people can have conversations and you can search back on that so you can have that history of conversations (you can go back and look for knowledge in that way). But, it tends to make people feel like they have to be connected and communicative in the Slack rooms – which can then become a breeding ground for interruptions.
Something that we’ve done with this is we have our source control commits going into Slack – this can be nice because if you’re waiting on something to be committed into source control so that you can get the update, then you can just wait in Slack and see when it comes in, instead of forcing the developer to notify you when they’re done. That’s another option though that you could do.
Something that can help to battle the downsides of chat or Slack but still get some of the benefits is to be able to go “Unavailable” or “Offline”. If you’re on a chat, you could set your away message to be “Unavailable”, or if you’re in Slack you can just close out that program if you’re trying to have heads-down coding time or a little through time.
That concludes my webinar – I think you’ve seen how important it is to reduce the interruptions. It can come with problems and be difficult, because you still need to share that information. But if that reminds you of some of the challenges in your team and you’d like to find out how we might be able to help, then reach out at the link below and we’ll get right back to you. Thank you!
