Don’t build processes for the sake of processes. You have to understand why you need them in the first place; ideally, the whole team should understand that. You’ve already learned about the project management frameworks such as Scrum and Agile from the previous lectures (more on that here), but it’s important to understand the factors that make these effective. We at JetBrains also build processes, but we recognize that there’s a risk that this will be absolutely pointless if we fail to answer the three main questions. Why are you putting this process in place? When are you doing that? What does this process entail? If you don’t have the answers to these questions, no project management philosophy will be able to help you in your venture.
Synchronization
Another important aspect that the team should be aware of is who’s doing what and where everyone is heading to as a result. That’s when synchronization comes into play. It doesn’t matter which format you use, the only rule to abide by here is its convenience. You may find that what works best for you is just writing in a team chat, and that’s ok; go for what suits you.
One of the practices that is usually adopted by Agile adherents is a stand-up meeting, during which everyone shares their results with everyone else. But the reality is that stand-up can be boring and ineffective, which is a far cry from what it was meant to be. It can be boring because some team members may not have a clue about what others are doing, or find it uninspiring, or the whole process gets dragged out for too long. It can be that stand-up isn’t really what the team needs at this stage. We in our team do have stand-ups, partly because they help us to synchronize quickly, partly, and most importantly, because they give me a comprehensive understanding of everyone’s tasks and progress. There are teams out there that don’t need to hold such meetings daily, just, say, once a week. But even if you’re dealing with a simple, no-frills stand-up, you need to understand the reasons behind it. When we introduce new processes, it impedes people in their work, especially if this work is already well-organized. For this to be effective, we need to make it so everyone is interested in what it is that they’re doing. If people are not interested, you’ll feel that at the stand-up.
EAP, Feature Freeze and CD/CI
Each company has its own objectives and tasks. In our case, this is launching a new release every four months, with a functional, high quality product that meets the needs and expectations of users. We at the .NET-development department churn out lots of products on a regular basis. The department employs 100 people working with 200,000 files, a total of over 20 million lines of code, and a task of making our solutions operable on a variety of platforms. Lately we’ve been doing about 1,000 commit operations every day. This is an enormous amount of work, and we’re in need of processes that will help us carry on with such baggage.
One such process is bugfix planning (or correction of software bugs). Be prepared to perform additional bug fixing as soon as an hour after you release the product. Sure, the processes only exist to prevent this from happening, but there isn’t a 100% guarantee of success.
We use EAP (Early Access Program) to make sure that we’re making the deadlines. This is a tool we at JetBrains invented 15 years ago, but it has spread to other development teams as well. EAP provides us with an early access to our end product, and we activate it at the beginning of the release cycle. What this means is that we put all the finishing touches to the features left over from last year, add something new, and move to a weekly-cycle working format where we develop a version of the software we’ll then use. It’s a necessary procedure because we deal with desktop products and not web servers which we could give the user access to and roll back onto the latest runtime version should there be any problems. Ours is a solution which users have to install themselves, and that’s why we need a mechanism that will make it possible for a large group of people to test it: there’s no way you manage to assess 20 million of lines of code by hand, and a fault-free code is something from the fantasy world. As a result, 5 to 10% of users are ready to operate the EAP versions.
Another crucial aspect here is that at a certain point, we start working cyclically, and that makes us know what to expect. It’s important because it gives you an understanding of how everything is going to work, and, consequently, how you’re going to juggle your priorities and what is more urgent: completing this feature or fixing the bugs identified by you or your users instead. EAP is a great way of involving users in what has already been done, but we’d also like to avoid being inundated by all the feedback, so it’s better to offer the user a decent-looking version that works.
Feature Freeze marks a point after which we’ll be refraining from adding any new functions to our product, or else the system won’t be stabilized, leaving us no time to carry on with all the necessary procedures of conducting internal and external tests and writing guidelines. We at our department usually schedule Feature Freeze a month before the release date because we prioritize quality over quantity; it’s okay if our product has less features, but the most important thing for us is to make it stable.
CD (Continuous delivery) is a software approach where a user is constantly provided with the latest version of a product with all the new functions. CD guarantees that everything stays in order whatever the situation you find yourself in.
CI (Continuous integration) is a software development practice which implies merging all the blueprints into the main development branch several times a day and conducting regular automated assemblies of a project for the timely identification of defects. CI acts as the cornerstone of the development process without which nothing will work, CD above all else. All your developments should be constantly assembled, reassembled, and tested, ideally in an automated way to save you time and effort. CI also lets you run continuous tests on how productive your product is, so it’s a very useful monitoring tool.
Thematic weeks is a technique we’ve introduced just recently. Last week, for example, was dedicated to bug fixing. Our testing department prepared a list of what the development team need to get fixed; I don’t know any developers that are fond of bug fixing, but having a clear-cut checklist made this minute work less annoying and more exciting, so it’s turned out great.
You can’t have too much tests. Tests help us ensure that even if we introduce some changes to the overall code, our product is still going to work. If all the tests come out green, this means that the product is stable, and it’s the best possible result you could wish for.
Protector robots
If you have this opportunity, back your processes up with robots. These are a trigger that will raise the alarm before something goes wrong. We have a merge robot that operates on CI and guarantees that the test we’ve written passes the mark. The issue is that this doesn’t work well with the more complex, undercover glitches present in the code; these go on to the manual testing stage, after which we write new tests that will factor in these problems. The more tests we put in place, the greater the possibility that the product can be used as soon as it’s released.
What also makes robots so great is that you can teach them other useful tricks, for example, to update you on what’s going on. Our testing department just loves being updated on what each developer is working on at this exact moment of time. It comes in handy because we have less paperwork to deal with, and testers are more aware of all the happenings.
Boasting and praising
It’s vital for a team to have a positive communication culture, in which every member can boast as freely as they can praise others. This too can be done in a group chat, so that after they come up with a new feature, developers can tell others about it and get the feedback that will motivate them to keep up the good work. All team members can evaluate the work that’s been done by liking these posts. What this also does is it sparks a discussion where everyone shares their ideas around. After all has been talked about, we can pass to the next stage of feature-thrashing.
Feature-thrashing
Before a new feature moves into the production stage, we invite people from our and other departments over to grill a developer on the various nuances of its operation and recommend some improvements. This lambasting session lasts no more than half an hour but still gives a great boost to the quality of the product. What’s more, it provides tech support specialists and tech writers with a first-hand insight into the new feature, which makes their work easier.
