How the creators of Pivotal Tracker work ... On the development, management and hiring of people

An interesting lecture by DANNY BURKES, technical manager (engineering manager) on how their work is organized at Pivotal Labs, has been published on www.edx.org as part of the Software as a Service course. I want to share with you some excerpts from this lecture translated into Russian.

The lecture is structured as follows. First describes the software development philosophy at Pivotal Labs. Then more specific recommendations are given for developers and project managers. In the end, it tells about the practice of hiring people in their organization.

Pivotal Labs Philosophy (Strategy)

Software development is communication. The ability to communicate with people and learn from them is key.
Software development requires discipline and rigor. We use the following practices:

• Permanent work in pairs.
• 100% use of TDD ( Test-driven development ) techniques .
• Strong focus on refactoring.
• Using the practice of continuous integration ( CI ). The results of all tests are monitored on monitors. (But large monitors are mainly for customers. They are impressed. Developers keep track of everything on their machines.)
• Combining teams (collaboration with the client).
• Standups. Daily morning standing meetings (10 minutes) for all, and then splitting into teams and similar meetings within teams. It is important to keep communication. Basically, these meetings are aimed at identifying problems that block (time-consuming) ongoing work. On a company-wide scale, the problems of the project as a whole are discussed.
• Retrospectives. The project discusses the work done weekly. Discussion of the week takes 1 hour. The meeting is attended by the developers, the RP (Project Manager) and, possibly, the customer representative. The discussion is open and direct - it says about the good, about what is beginning to look suspicious and about the bad. The bad is discussed in some detail (up to an hour), after which a list of steps to solve the problem is compiled. Inside the company, work is discussed once a month (general questions, for example: “Are we still working in pairs?” - “Is this effective?”). Nothing is canon.
• The proximity of the RP to work. Continuous interaction between the RP and the developers. Interaction should be with eye to eye, no "electronics".
• Ubiquitous use of Pivotal Tracker .
• Using the demo environment for acceptance of work manager.
• Planning work for the next week. Runs once a week. Clarification of expectations / implications / estimates / understanding of the tasks between the RP and the developers.
• Inceptions / Outceptions (start / finish of the project). The first day of the project should be fully engaged in meetings. You need to load the developers for a few weeks ahead and during these weeks you should avoid meetings at all costs. Software development never ends. You must respond to customers and the wishes of people. This statement conflicts with software development by specification. In this case, you assume that you know when you're done. But this method simply does not work.

Tactics

For developers

Features of extreme programming ( EP ):

• Social activity. The EA is not for a person with headphones who likes to sit in the corner and turn thousands of lines of code.
• Design becomes a permanent activity. Starting development without a complete statement of the problem is a normal practice.
• Testing becomes the main activity of the development process. You do not start coding before making a test. Testing is much more important for the client than the code. The code is rather an artifact. Tests say what the client wants to do and how he wants the product to behave, and code is the way to do this. And the idea of ​​agile software development is that you should be able to change the implementation at any time while the tests are still running. Yes, in half a year you may have problems with scaling and you will have to rewrite most of the system, but you should not be sad because you still have tests. And these tests can always assure you that the behavior of the system has not changed.
  

  - Do you make any formal documentation?
  - Tests. We do not make comments. We do not do documents. Tests our documentation ... Spec (Ruby), Jasmine (JavaScript), Capybara are all kinds of DSL ( domain-specific languages ). And you do not need to be a programmer to understand them. But even before them, we did not write documentation, because it becomes obsolete as soon as you publish it.

  - Do you write comments?
  - No, we have tests.
  - Speech about comments like “what does this code do, why is the code written in this way”?
  - The only reason why the code was written (anyway) is to take the test.

• We do not have our own tables and computers in Pivotal. What we have is a three-pair team (6 people) and three development stations (two 27 Macs and one pair of input devices). There are also separate computers for personal needs and mail. But now they are almost not needed, since everyone works through phones. People are concerned that they do not have personal computers, but they are only worried about this on the first day.
• "Uncertainty".
  
  • You have no specifications.
  • You do not know where you want to come
  • What you know today may change tomorrow
  • You don't know when you're done.
  • You must abandon the notion of being complete.
  All this requires a certain type of personality, ready to live with it.

For RP (project managers, project managers)

• RPs should track backlog (outstanding tasks). This is a very big job.
• RPs must every day ensure that the backlog accurately reflects what they want to receive, and the second is the order in which they want to get it.
• The bigger the team, the harder it is. Good eight-pair RPs are very rare. You need to work hard to constantly work all eight pairs.
• RP need to timely accept the work of developers. They are very annoyed when the day after the job is not accepted.
• The RP needs to think about the short and long term when planning tasks.
• The developers want the RP to sit next to them.

Hiring people

What not to do?

• The accepted "best practices" developer interviews are completely erroneous.
• You do not need to keep people in the room for 5 hours and conduct interviews with 10 of your employees.
• No need to test specific technical skills. It is about the knowledge of specific technologies. That is, if we have a project under iOS and an employee comes with such knowledge, this is good, but we don’t need to look for it specifically. Exactly due to the fact that tomorrow the project for iOS will end, we will start writing for Android and what to do with the iOS specialist? It should focus on a person's ability to learn and communicate.
• You can not ignore the communication skills, if you want to engage in electronic signature. Even if the candidate looks like a super specialist, but has difficulty communicating or does not look friendly.
• Hiring should not be blind. Often, interviews take place without testing coding skills. How can you hire a person like this? It makes no sense.

How do we hire people?

The first part consists of a pair interview. About 45 minutes. Maybe on Skype, but better live at a regular desktop.

• We together solve the usual working problem, which is the current moment. We are talking about general concepts, not about specific technologies, but rather about problem solving skills.
• You can offer a good way to solve it, but empathy (if the interlocutor hears you?) And communication is much more important.
• We have a very strict selection criteria in the first part of the interview. The candidate must score a certain number of points. If scored, we offer to come to the second round of selection.

The second part - you come and work all day. Half a day with one person, half a day with another person in a pair. This will be work in real projects. These are not synthetic problems, not fakes, not marker boards. You sit down and write code. In fact - this is an interview with our team.

• This round aims to identify more specific skills.
• “Cultural fit” (checking if the candidate is “cultural”).
• At the end of the interview, we ask the candidate if he is ready to sit in a pair with this person for 6 months. The candidate must understand what awaits him. We want to make sure that you get along with people.

So, three things that we check this way:

1. Programming skills.
2. Communication skills.
3. Skills cooperation with developers.

What are we looking for in people during the interview?

1. Fundamental skills in programming and software development.
2. Curiosity and hunger for the development of new skills. This is an important personality trait that falls into our area of ​​work.
3. Ability to say "I do not know . " Is it convenient for you to say this? You must understand that the ability to recognize your ignorance is the only way to learn.
4. Reverse side of p.3: The desire to say: "Let's try and see what happens . "
5. Personability.
6. The confidence that you can give the best advice, as well as the understanding that the client can ignore it.

So, we are not looking for specific technical skills. All this is very inconsistent. We are not very concerned about what you have today. Much more important is the ability to get something in the next few months.