Developer Oriented Project Management

by Robert Pankowecki

Developer Oriented Project Management

In this video, Robert Pankowecki discusses strategies for managing IT projects in a way that prioritizes the needs of developers, fostering an environment where they can thrive and feel engaged in their work. He emphasizes the importance of creating a supportive structure that not only meets client needs but also aligns with the professional growth and happiness of programmers.

Key Points:

- Developer-Friendly Management: Pankowecki highlights the contrast between traditional project management methods, which may focus excessively on client demands, and more developer-oriented approaches that encourage programmer satisfaction and productivity.
- Techniques for Improvement:

- Small Stories: Breaking tasks down into smaller stories (ideally 1–2 days in duration) enhances clarity and allows developers to mark tasks as complete frequently, improving morale.
- Unassigned Tasks: Allowing developers to choose their tasks promotes a dynamic workflow and ensures that critical client needs are prioritized effectively.
- Prioritized Backlogs: Developers are encouraged to pick priority tasks directly from the backlog, fostering a sense of ownership while still allowing for collaboration on more complex issues.
- Integration of Roles: By adopting Agile methodologies, developers can step into leadership roles, taking on responsibilities such as client meetings and task prioritization. This empowers them to manage projects more independently and gain valuable business insights.

Significant Examples and Anecdotes:

Pankowecki shares a specific instance from his experience at Arkency, where they adapted their project management style after working within a client’s less effective framework. This revealed the value of their own practices, prompting a deliberate shift towards more developer-friendly processes.

Conclusions and Takeaways:

Pankowecki concludes that effective project management in the tech space should create a culture of collective ownership, where developers feel free to innovate and shift between tasks. This approach not only contributes to individual growth but also enhances overall project outcomes. By focusing on small deliverable tasks and clear communication within teams, companies can cultivate a more agile and responsive work environment, benefitting both developers and clients alike.

00:00:13.559 Hello everyone, I think it's time to get started. You've been waiting for it, I think like one year or so, at least. It's my pleasure as one of the organizers to welcome you to the Third Edition of Wroc_love.rb. I hope you are doing okay and that you are going to enjoy this show.

00:00:41.920 This conference was organized by the guys wearing these white badges. You can approach them with any problems you have, and you can thank them if you think we are doing a good job. Now, I'm going to step back from my role as an organizer and jump into the role of the speaker.

00:01:11.520 Today, I'm going to talk to you about developer-oriented project management. My name is Robert Pankowecki, and I work in Arkency. I like helping people, and today I would like to assist you in the process of creating software in your company.

00:01:34.320 You might be wondering why I even give this talk; what motivated me to start discussing this subject? There's an interesting story to share. Customers usually come to us with the idea that we should help them with some software project, and the technical responsibilities are on us.

00:01:58.560 However, we had an interesting situation some time ago. A customer wanted not only our help in developing the product but also asked us to join the team of programmers already working on his startup. This project made me realize the differences between how we handle our projects compared to how our customer did things.

00:02:34.959 Initially, in our customer's workflow, there was one person responsible for merging pull requests and another doing manual deployments. This experience highlighted many differences in our approaches and made me see what we do at Arkency that makes me a happier person.

00:03:00.560 Today, I'm going to talk about techniques that contribute to making me a happier and less stressed programmer. I’ll share small stories about unassigned tasks, integrating them into your daily job, and managing large features when we often prefer smaller ones.

00:03:15.239 So, let's start with the first technique: the story of size one. This is a simple idea. Instead of estimating the size of the stories, just break them down into sizes of one, meaning they should require about four hours of work, up to a maximum of two days.

00:03:30.439 Each story must bring value to any stakeholder in your project, whether that’s you as a programmer, a user of your software, or the customer itself. The story must also be divisible, meaning if you can break it into smaller parts that still bring value, you should do so.

00:04:01.879 I really enjoy working with small stories. You can pull them from the backlog, finish them, and mark them as done. This is extremely satisfying compared to larger stories that take a week or more.

00:04:22.840 When tackling larger stories, you often feel mentally burdened, constantly aware that the story is not finished, resulting in stress for both programmers and managers. The clarity offered by small stories makes it easy to track progress; a high-level overview provides instant insights into what’s done.

00:04:51.880 Moreover, achieving closure every four hours when a story is completed provides a psychological lift. It creates a sense of accomplishment.

00:05:01.600 The most significant benefit is collective ownership. Small stories make it easier for programmers to work on different parts of the system without the burden of long assignments. This fluidity means developers can learn from one another by interacting with different code sections.

00:05:34.400 People learn only by reading someone else's code and fixing issues as they arise. Working with small stories also enhances mobility within the company because programmers can shift focus to projects that may need immediate attention.

00:06:11.000 Another advantage is that small stories minimize the risks of not delivering. If a developer encounters an issue while working on a four-hour task, it’s manageable, allowing another programmer to quickly step in if needed. This adaptability is challenging with longer stories.

00:06:46.880 In the spirit of Agile, small stories allow for gradual feature delivery. Instead of pushing a massive codebase into production all at once, which could lead to major issues, we can deliver smaller components daily, receiving feedback more rapidly.

00:07:19.520 Additionally, small stories provide customers with better prioritization through granularity. Instead of having a large task, customers can select specific small stories that deliver the biggest value at any time.

00:08:02.640 One example is a project we worked on for three weeks, where we delivered multiple small stories each day, which included documentation and UI design. This setup was beneficial as it allowed us to adapt to shifting priorities as the project progressed.

00:08:43.640 The second technique I want to share is leaving tasks unassigned. You may wonder why. Imagine having three developers and ten tasks. By not assigning tasks, developers can pick the most important ones to work on. This flexibility allows for a more dynamic use of human resources.

00:09:37.808 When tasks are not assigned, it allows freedom and flexibility in creatively managing the workload based on current project needs. In our case, everyone works remotely and asynchronously, making unassigned tasks vital for achieving this efficiency.

00:10:32.480 Now, let’s talk briefly about project managers assigning tasks. It can lead to an inefficient workflow, as the assignments may not be prioritizing the most important tasks. If a project manager assigns tasks, it risks leading developers away from prioritizing the client’s most critical needs.

00:11:44.640 This brings me to the importance of collective ownership. When developers choose tasks based on interest and impact, it alleviates the challenge of only powerful or experienced individuals monopolizing interesting tasks.

00:12:26.559 Moreover, it's essential to ensure that team members know what to work on after returning from vacations or weekends. In our case, communication with clients is visible to our entire team, which makes it easier to determine priorities.

00:13:36.679 The third route in managing tasks is simply taking the first task from a prioritized backlog. This means that as a developer, when you look at the backlog and see the highest priority task, you start working on that immediately.

00:14:26.440 Surprisingly, taking a task doesn’t mean you have to finish it immediately. If you realize it’s too complex or you lack knowledge about the required technology, you can simply document your findings and obstacles in trying to complete it.

00:14:55.040 It’s fine to assign some tasks, especially if certain expertise is required, such as graphic design or sales. However, you must communicate clearly which tasks are assigned and which can be picked from the backlog.

00:15:23.640 In summary, we prefer small stories and unassigned tasks so that everyone can choose tasks from the backlog. However, when customers typically approach you with larger requests, we need to manage that effectively.

00:15:50.720 One approach is to extract small tasks upfront. If you notice one big task, you can take time to break it down into smaller deliverable tasks leading to the overall feature.

00:16:51.480 If you have a massive three-week-long task, you can treat it as a 'specification as a floating ticket.' This means keeping a high-level task visible, but as you dig in, you extract smaller tasks and then move the larger item down the backlog as it’s addressed with smaller pieces.

00:17:24.160 Ultimately, I shared four techniques that revolve around the assumption that your team desires to learn, improve, and grow together. This would enhance the overall project workflow.

00:18:02.200 We like small stories, unassigned tasks, and the idea of taking the first priority task. If you have large specifications, treat them as floating tickets.

00:18:34.080 These techniques can be applied individually, but they yield the best benefits when combined. By doing so, you can establish a culture of collective ownership, where it's easier for developers to jump across different projects rather than being locked into a single repeatable task.

00:19:07.440 We embrace more asynchronous work, appreciating clear communication within the backlog and solutions. This way, the product owner can prioritize effectively, and teams can collaboratively tackle different areas.

00:19:35.760 Unfortunately, long tasks in development without feedback can hinder learning opportunities that should occur at work. We want our workspace to be a place where learning is facilitated.

00:20:03.720 Lastly, if you're interested in the topic, I wrote a book about it. You can follow the link showing on the screen to sign up for the newsletter or just buy the book with a discount.

00:20:32.399 Thank you for letting me speak as the first speaker at this conference. Do you have any questions? If you do, please ask them loudly. Generally, people don't have questions right away. Ah, I see you, sorry for missing you.

00:21:46.760 I think it can be a problem to extract small independent stories since sometimes tasks may get intertwined. We tackle this by interleaving stories from different features, aiming to build smaller independent tasks as much as possible.

00:22:20.399 However, if there are dependencies between stories, we encourage communication and collaboration to identify potential problems. Tools like Pivotal allow us to visualize the connections between epics and see who is working on what.

00:22:58.240 Going back to how much time it takes to divide larger tasks, I don't track that explicitly. Typically, as I work, I naturally try to break down the larger story into smaller tasks, which streamlines the workflow.

00:23:34.120 It's more about the mindset of thinking in smaller increments rather than setting aside dedicated time to break down tasks. So, my practice is about converting big tasks naturally as I work.

00:24:01.680 The team I work with was eager to learn and take over methodologies to help improve their processes. So persuading others was pretty straightforward since they were already impressed and motivated to embrace the changes.

00:24:36.760 The biggest factor in convincing others is showing tangible results while working with the product owner and delivering effectively. Everyone appreciates a good process that yields better results.

00:25:01.680 The final thoughts I leave you with are that labels, like ‘Agile’ or ‘Scrum’, seem to lose meaning over time as implementations can vary greatly in practice.

00:25:50.240 Thank you all for your attention, and I’ll hand over to the next speaker.