Self-organized teams are at the heart of agile software development.
To self-organize team members have to manage their work, the processes that they use and the way that they work together as a team and with their stakeholders.
Robert Pankowecki is writing the book on Developers Oriented Project Management which aims to help programmers, product owners, project managers and agile company owners to improve their project management practices and move towards more flat organizations.
You can download a sample of this book from Leanpub.
InfoQ interviewed Robert about planning activities, differences between developers and project managers, building relationships with customers, and improving communication in teams and between the teams and their stakeholders.
InfoQ: What made you decide to write a book on developers oriented project management?
Robert: Initially we started writing the book to help remote teams. But over time we realized that many of the practices can be beneficial to any kind of programmers team, including a stationary one. Many of our friends from other agencies were interested in how we work, our potential customers also wanted to know it. Even in our own team some of the strategies were born and used in one project, but the knowledge have not moved into the other projects yet. So the book is about strategies that are working for us, that we experimented with and found beneficial. I hear from other programmers that they go to work, get a big task and spend 2 weeks implementing it. We wanted to show and document that there is other way to work. And by showing and emphasizing on the benefits we want to give them something that they can propose in their current work environment. Small changes to push from bottom up. But this book is not only for programmers. It is also for product owners, team leaders and even project managers. They can push for the same changes but for their own benefits. After all, in the end, we all want the same thing. Working software, delivered continuously, that can react on daily basis to ongoing changes in the world.
InfoQ: Where do project management activities done by developers differ from the ones done by project managers?
Robert: I believe that when programmers collectively deal with project management activities the result is a much better transparency. As programmers we are accustomed to looking at code which is stored in code repository like Git. The code is created and modified incrementally and by looking into history of commits we can often see the process of creating a workable solution. Project management activities when done by project manager are however often sealed from the rest of the team. Calls and emails are flying between PM and the customer but the rest of the team does not have an access to it. This communication when done well is building a trust between the agency and its client. And to know how to talk with the client, how the relationship was build, what were the fears of the customer that we were able to overcome, that is the knowledge that should stay with the team, even when the PM leaves or is on holiday.
However the communication cannot be sealed when it is done by multiple people in a same way that code cannot be sealed if we want multiple people to work on it. When the team receives an email from the customer, everyone can see it. When one of the developers answers it, everyone can see the answer. Sometimes the answer is just ok. Sometimes however the answer is a spectacular, very well thought, email, which dispels all customer doubts. And everyone learns from such experience. Like when we see a well structured code, we try to learn and use it through out our codebase in similar cases. In a similar way we can learn from others how to communicate properly. With respect to customer knowledge and opinions. But the most important aspect is that the communication is transparent so everyone is getting a better feeling of customer needs, expectations and priorities. We learn how to work with such person. It's not a hidden knowledge. It's exposed. We know how to talk to our client. And every client that we work for is unique.
Our superiors like to think that business value of our product should not be limited by the technical challenges that we face. And that is what we always strive for. However it is usually a science fiction. Many projects' codebase is not in such a clean state so that we can easily adapt it to every new requirement of customer. And many teams lack skills to do it. But there is usually a wide range of possible things to implement and possible solutions to any problem. When programmers talk with the client they almost immediately start to imagine solution to the problem in the code. And they know what is going to be hard and what is going to be easy. And because of their knowledge of current state of the code, they can propose multiple ways of solving the problem and many times guess more-or-less correctly which solution is going to be easier and which one harder. So they talk with the customer and it is like "I hear what say, sure we can do it. I think that will be about 3 days of work. But you know what is hard, that part about supporting this usecase for unlogged users. If we drop this requirement, and by looking at the server I see that only 2% of our users are not logged, I can have this feature for you by tomorrow, what do you think about that?" If your programmers can talk with the business and provide valuable feedback like that, that is a huge winner. The other agency might be 50% more effective, but your programmer just convinced the customer to drop useless requirement (by providing actual data) and speed up the development from 3 days to 1 day. The best money for you customer is the money not spent. Direct collaboration between programmers and business allows us to avoid confusion in understanding the requirements. And it provides opportunity to negotiate a scope based on developers knowledge and business needs.
Many agencies have fear of letting the programmers, especially junior programmers talk with the customer. They are not confident in their own programmers communication skills. However there is no other way for them to learn it, but to actively and constantly talk to the client. Engage in the communication to understand the domain of the problem and real business cases that are the reason for the software to be built. After all, that's what Domain Driven Development encourage us to do. To talk to the customer and get to know their domain very well.
InfoQ: One of the essays in your book talks about the developer’s attitude to project management. It mentions that developers often expect that project managers have arranged everything so that they can do their work. Is this also the case with agile teams?
Robert: I would say that it depends on the company that you are working for. Some of them claim that they do Agile because they established some of the Agile practices like iterative process, continuous delivery, pair programming or others. But the entire process of talking to the customer and gathering requirements is delegated to one person. Be it a project manager or senior developer, does not matter much. Still only one person is doing the activities.
Sometimes this situation is an effect of the arrangements in the company, and such work style is pushed from the top management because of lack of trust to the programmers that they will do it properly. But sometimes, even if the management would like to lean towards more agile and direct communication with the customers, the obstacles come from the programmers themselves. They feel insecure and uncertain when doing project management activities. There is a small chapter dedicated to changing that attitude because it is a critical factor when you want more self-managing teams. Without proper change of mindset, they will always prefer working with code over working with customer.
But there are a great number of companies which adopted Agile more deeply and their developers truly collaborate with the customer on daily basis. They do it eagerly and with passion, because they already know how valuable and critical these activities are for the success of the project. I hope that after reading the book more programmers will also happily adopt such positive mindset.
InfoQ: Another essay talks about how developers can build a relationship with their customers. Can you explain why this is important and how developers can do it?
Robert: It is just way easier to peacefully collaborate together when we know each other and trust each other. I think the best way to explain it is to compare a situation when the customer is only talking to project manager with the situation when the customer can discuss the issues with every team member.
In first case the relationship is built between the PM and customer only. They get know each other very well and find ways to cooperate. They learn each other. What's important for your agency is that the PM learns the customer. How to propose features, how to talk about deadlines, what are the fears of the customer and more. The entire quality of communication depends on the nature of this relationship. When the manager goes for vacation (or leaves the project or company), everyone is left with nothing. What used to work smoothly is now put in great risk. The whole trust gained by on manager is now gone.
Compare it to a situation when there are five people in your team and customer is talking directly to each one of them. When one person leaves there are still four left and the trust stays on the same level. New person joining the project to compensate for the one that left, must of course gain the trust again and prove to be valuable team member. But the whole knowledge about how to talk to the customer, how to negotiate, how to discuss scope change, all of that stays in the team. Same way you can have Collective Ownership for your code, same way you can have Collective Managership.
The trust and relationship built directly between client and programmers proves to be very useful in negative situations. There is a risk of not meeting the deadline, or personal situation that requires developer absence for few days, anything. It's great when you can just talk to the client directly and explain it from your perspective as human being, instead of pushing it to the project manager, which must now explain it to the client, and worrying and waiting for the result of such conversation.
But such relationship also gives us a space for better direct collaboration and closer feedback loop. As a developer you can directly ask customer for the requirements, tell about the progress, ask for feature verification. Listen to the praise and deal with customer doubts. This makes the entire work more smooth and pleasureful.
So now that we know why, the question is how to build such relationship. I think the answer is: by helping dealing with classic PM activities. Talk to the customer, help prioritize tickets, help split features into smaller stories that can be deployed earlier, challenge tickets which bring no business value, implement business metrics and propose valuable things to measure that help in making future decisions. Sometimes the best thing to do, is to honestly tell your customer that this feature/project/solution is not going to work, and we should not waste money on that and instead try something else.
InfoQ: There is a whole chapter with essays about communication in your book. What makes it so important?
Robert: As I mentioned earlier we started the book to help people work remotely. Even though the tools are already here and the possibilities, it is still not a very popular option. We have few model companies which prove that it is a viable way of working and that they can deliver the software. So it is a possible option, and desired by many people but most of us working remotely were never trained for working in this kind of environment. We spent years going to stationary schools. Our parents, teachers and mentors could not work that way and they usually had to go to some kind of office. There is no TV show that will show you how remote people work so you can't learn it from media.
And when you are working remotely communication does not happen the same way it happens when meeting face-to-face. So remote teams must find their own ways of working because otherwise the communication just won't happen. And without working communication you don't have a working team or working company. But it seems that every remote company that we talked to had to invent its own system. So we wanted to share what's working for us so that you can have a kick start at the beginning and iterate from that. Obviously, what's working for us might not be working for you, but let's at least share a list of the practices that may be worth trying, so that it does not take so much time for everyone to invent them, on their own, again and again.
To have the communication aspect mastered is especially important for companies which are half-remote, half-office. I think this is the hardest setup. For everyone-in-the-office companies the communication will just happen spontaneously. The fully-remote teams usually sooner or later find their own way to have everyone informed and kept in the loop. But if you are half-remote, half-office, then you can't relay anymore on spontaneous communication because it never reaches the remote workers. I've heard stories about companies working from office which tried hiring remote workers and later found out that the deal didn't work very well. Usually it happens because they haven't found a way to reorganize communication so that it is fully, conveniently accessible for remote workers. The whole thing failed not because of lack of technical skills of remote workers but because of communication problems.
InfoQ: I'm assuming that there are also similarities, activities where it doesn't really matter if developers or project managers do them. Are they also covered in your book?
Robert: Indeed there are some activities that we cover in the book, where the end results might be the same, regardless of the executioner. Such as "split the ticket" (2 stories instead of 1) or "challenge the ticket" (story removed from backlog). But the problem is that such techniques, maybe obvious to PMs, are not that obvious to developers. You need to tell them, that they as well have the authority to do such things. That it is part of their toolbox and should be used depending on situation to make their life easier.
InfoQ: In your opinion, is there still a need for project managers in software development?
Robert: I always perceive PM as someone who plays similar role in the team as Senior Developer or Architect but in the area of Soft Skills. Senior Developer is not the only one person coding in the project, there is whole team for that. But it is his/her role to inspire and provide leadership in the technical area so that everyone can grow while working on the project and so the code remains clean. PM on the other hand should not be the only one person doing PM activities; entire teams can work on that. But it is her/his role to coach and mentor everyone in that area. How to talk with the client, how negotiate scope, manage deadlines, and keep quality high. If everyone in you team is great at that, you can live without PM, because every dev at any moment can play the role of PM. But what if your team has not yet reached such stage? You need a coach or a mentor. PM can be such person. But I imagine it to be more like "come with me and we will talk to the customer and try to gather the requirements" instead of "let me talk with customer and I will come to you later with my findings". I imagine PM to be a navigator on the business part of the project to the developers, not a buffer protecting them from ever going onto such land.
In one project our PM had background in the customer support team of that project. It was interesting to see this non-technical person be able to judge parts of our code based number of problems related to it that was submitted through customer help channels. This person was able to provide feedback on what's important to the users, what the priority of next tasks is because she knew what's mostly affecting and irritating users. I would have never thought of giving such person some of the responsibilities of project managers. Great choice made by our customer.
InfoQ: Can you name some estimation, planning and tracking practices that developers can use?
Robert: It's funny because we don't use much of these. We try to avoid estimations and rather our preferred method is to split tickets into very small stories until we see the path from current status to desired state of the product. For planning and tracking we simply use whatever our customer likes. Redmine, Pivotal, Trello, the tool does not matter as much as your process. We don't believe in iterations because we don't see much value in putting artificial barrier separating days, which does not bring any value. We try to see the project as constant stream of time and people working on the most important task that they take when they are finished working on current task. Customer can reprioritize tasks on daily basis according to the always changing business knowledge.
InfoQ: Can you give some suggestions how communication can be improved in teams, and between the teams and their stakeholders?
Robert: Sure, although I am not sure if that's gonna be revolutionary in any way :)
Firstly, make sure everything important is written and people can link to it. Surprisingly still many companies fail at it. They have telephone calls and forgot to make notes. When they do, they send emails, but you can't easily link to emails. We went with hackpad.com recently and this is one of the best things for us recently. Remember to link to the discussions and decision in as many places as possible. Especially in commits. You might be wondering whose communication is that going to improve? Developers with other developers. And they are stakeholders too. It doesn't really matter what you choose to go with. Pivotal, Redmine, Trello, Hackpad, Github. Every good tool allows you to link to the ticket/issue you are discussion about. If you communicate with stakeholders (clients, subcontractors) via email, just copy at the end of the conversion the most important decisions into your ticket tracker. Especially if your email communication is not transparent to entire team because you are exchanging emails one to one with the other side.
Don't assume anything. You might be thinking that the subcontractors have the same understanding of requirements and same knowledge about the system. But that is often not the case. So please try to be explicit, state your knowledge, your understanding of the problem, rephrase your college point of view and maybe you will find the missing points between the knowledge of you and another person. I was once in a few week long project writing an API. It was obvious to me that it was for a fat client. The developer working on the iphone part, consumer of the API, found it obvious that it was for thin client. We were pushing the design of the API in different directions. We realized our different visions few days before deadline (just in time). We both assumed and never verified our assumptions. For both of us, our points of views were obvious, and that's how we always dealt with things in such situation. Until we didn't. So don't assume and if you do, go ahead and verify.
Overcommunicate. When something important happens, decision is made, feel free to announce it on many channels. Mark the decision in related ticket. Mention it on the standup, write on irc/Campfire/Flowdock. Note it in the Git commit message. Don't be afraid of repeating yourself, of communicating same thing multiple times. It doesn't take much time and you will make sure everyone involved is notified. This is especially important in remote and asynchronous environment when we can't relay on daily visual clues and spontaneous, ad-hoc communication happening between coworkers. We even write on irc channel that we just started working or that we are no longer working and away from keyboard. It's great to know whether you can just shoot a question and expect an answer from your coworker or whether you should just ask it and not wait for an answer because nobody else is there working at the same time as you.
Consider going fully transparent. I am sure ticket tracker, project documentation, code, are all open for all your developers and everyone can read and edit them. How about emails or phone calls? Is everyone in your team having access to them? This might sound crazy but opening those channels can greatly improve communication in your project. If we work for company FooBar, we have foobar@arkency.com alias that sends the email to everyone involved in the project. We ask our customer to send emails to foobar@arkency.com instead of single developer or project manager. Whenever we communicate about FooBar project, we add foobar@arkency.com to the CC. It's almost magical to be able to track every email and refer to it in our conversations. To be able to find the decisions even if everyone involved in the communication is currently on vacations ;) We don't yet record phone calls with our customers (rather we create short documents that summarize them) but we do record stationary meetings when we discuss multiple topics with the customer in a conference room. Not as a primary source of documenting the decisions (that should be always written to make it easy to find and digest) but as a wonderful backup in case we missed to write something in self-explanatory way.
Split communication with all stakeholders across your entire team. Instead of having one person (PM?) dedicated to communicating with the rest of the stakeholders (clients, subcontractors), make it responsibility of entire team so they are more engaged. We do it by treating communication efforts same way as developing new features. Whenever there is something to discuss, we create ticket in our ticket tracker and one of the programmers will complete such task same way as they implement code features.
InfoQ: Do you have additional suggestions for developers who want to learn more about managing projects but who don't want to become project managers?
Robert: Don't be afraid of pushing for changes in your company towards more friendly environment for you. Do you want to work remotely at least sometimes, to stay more with your family, to avoid the traffic, to spend time in the environment you like? Talk to your colleagues and check if they have the same needs. Push together for the changes that will let you have that. That project that you are working on, it can't happen without programmers. And you have the right to remain happy in your job.
Managers often try to make developers work after hours (this is even sometimes glorified in the media) and we don't always have the power or the skills to avoid it. Go for the skills and use them to your advantage. To work smarter instead of more. You don't have to become project manager for that. By acquiring proper management skills you can help the customers that you cooperate with, choose tasks more wisely and spend the budget better. That can result in your better rates and in having more time for yourself. I wish you that.
About the Book Author
Robert Pankowecki is Ruby on Rails developer, working remotely for more than two years. At Arkency he’s worked on number of web projects in collaboration with small startups as well as large corporations. The creator of active_reload library which made your Rails apps faster in development mode. Founder of wroc_love.rb conference and one of the leading speakers at Lower Silesian Ruby User Group