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.