How the creators of Pivotal Tracker work ... About developing, managing and hiring people

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

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

Video links:
www.youtube.com/watch?v=bXCNvGHeYEA - introduction.
www.youtube.com/watch?v=CFVGT98gebM - software development at Pivotal Labs.
www.youtube.com/watch?v=o4c_MKbRxNA - how do we hire people?

Pivotal Labs Philosophy (Strategy)


Software development is communication. The ability to communicate with and learn from people is key.
Software development requires discipline and rigor. We use the following practices:
  • Constant work in pairs.
  • 100% use of TDD ( Test-driven development )
  • methodology .
  • Strong focus on refactoring.
  • The use of continuous integration ( CI ). The results of all tests are tracked on monitors. (But large monitors are mainly for customers. This impresses them. The developers keep track of everything on their machines).
  • Combining teams (teamwork with the client).
  • Standups. Daily morning standing meetings (10 minutes) at all, and then breakdown into teams and the same meetings within teams. It is important to maintain communication. Basically, these meetings are aimed at identifying problems that block (take time) current work. The problems of the project as a whole are discussed throughout the company.
  • Retrospectives. Within the framework of the project, the work performed is discussed weekly. Discussion of the results of the week takes 1 hour. The meeting is attended by developers, RP (Project Manager) and, possibly, a customer representative. The discussion is open and direct - it says good, that begins to look suspicious and bad. The bad is discussed in more 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 it effective?”). Nothing is canon.
  • The proximity of the RP to work. Constant interaction between RP and developers. The interaction should be face-to-face, no “electronics”.
  • Widespread use of the Pivotal Tracker .
  • Using a demo environment for acceptance of work by a manager.
  • Planning for next week. It is carried out once a week. Clarification of expectations / consequences / assessments / understanding of tasks between RP and developers.
  • Inceptions / Outceptions (start / finish of the project). The first day of the project should be fully engaged in meetings. You need to load developers a few weeks in advance 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 specification development. In this case, you assume that you know when you are done. But this method just does not work.

Tactics


For developers

Features of extreme programming ( EP ):
  • Social activity. EP is not for a person with headphones who likes to sit in a corner and crank thousands of lines of code.
  • Designing is becoming an ongoing activity. Starting development without a complete statement of the problem is normal practice.
  • Testing becomes the main activity of the development process. You do not start coding until the test is compiled. Testing is much more important for the client than the code. The code is rather a kind of artifact. Tests talk about what the client wants to do and how he wants the product to behave, and code is a way to accomplish this task. And the idea behind agile software development is that you should be able to change the implementation at any time while the tests are still in progress. Yes, after six months you may have problems with scaling and you will have to rewrite most of the system, but you should not be sad, since you still have tests. And these tests can always assure you that the behavior of the system has not changed.
    – Вы составляете какую-нибудь формальную документацию?
    – Тесты. Мы не делаем комментариев. Мы не делаем документов. Тесты наша документация… Spec (Ruby), Jasmine (JavaScript), Capybara — это все виды DSL ( предметно-ориентированных языков ). И не надо быть программистом, чтобы понимать их. Но и до них мы не писали документации, потому что она устаревает, как только вы ее публикуете.
    – Пишите ли вы комментарии?
    – Нет, у нас есть тесты.
    – Речь о комментариях типа «что этот код делает, почему код написан именно так»?
    – Единственная причина, по которой написан код (так или иначе), это пройти тест.
  • We at Pivotal do not have our own desks and computers. What we have is a three-pair team (6 people) and three development stations (two 27 Macs and a pair of input devices). There are also separate computers for personal use and mail. But now they are almost not needed, since everyone works through phones. People are worried that they do not have personal computers, but it only bothers them 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 do not know when to finish
    • You must abandon the concept of "being completed"
    All this requires a certain type of personality, ready to live with it.


For RP (project managers, project managers)

  • RPs should track backlogs (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 receive it.
  • The larger the team, the harder. Good eight-pair RPs are very rare. You need to work hard to constantly occupy the work of all eight pairs.
  • RP needs to accept the work of developers in a timely manner. They are very annoyed when the work is not accepted the next day after completion.
  • The RP should think about the short and long term when planning tasks.
  • Developers want RP to sit next to them.

Hiring people


What do not have to do?

  • The accepted "best practices" of interviewing developers are completely erroneous.
  • No 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 knowing specific technologies. That is, if we have a project for iOS and an employee with such knowledge comes in, that’s good, but you don’t need to look for him on purpose. Exactly due to the fact that tomorrow the project for iOS will end, let's start writing for Android and what to do with specialists for iOS? It should focus on a person's ability to learn and communicate.
  • You can not ignore communication skills if you want to engage in EP. 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 are held without testing coding skills. How can you hire a person this way? That doesn't make any 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 task, which is currently available. This is about general concepts, not about specific technologies, but rather about problem-solving skills.
  • You can offer a good solution, but empathy (does the other person hear you?) And communication are much more important.
  • We have a very strict selection criterion in the first part of the interview. The candidate must score a certain number of points. If you score, then we suggest you 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 paired. It will be work in real projects. These are not synthetic problems, not fakes, not whiteboards. You sit down and write the code. In fact, this is an interview with our team.
  • This round aims to identify more specific skills.
  • “Cultural fit” (checking whether the candidate is “culturally”).
  • At the end of the interview, we ask the candidate whether he is ready for 6 months to be paired with this person? The candidate must understand what awaits him. We want to make sure that you get along with people.

So, there are three things that we verify in this way:
  1. Programming skills.
  2. Communication skills.
  3. Skills of cooperation with developers.

What do we look 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 admit your ignorance is the only way to learn.
  4. The reverse side of p. 3: The desire to say: "Let's try and see what happens .
  5. "
  6. Personability.
  7. 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 worried about what you have today. Much more important is the ability to get something in the next few months.