#5 “Sorry guys i need to do my homework” – Planing parallel projects.

Hi everyone!

Today i want to talk about the backlog and parallel projects.

It is common to encounter problems while working with two projects at once. At the moment we tend to structure our work so that it clashes with our ordinary school work. Handling scheduling gets difficult and our insight into our teammates situations regarding time spent on lectures, homework and other school-related activities tend to be vague at best. Many blame the schools scheduling and lack of communication for the problems. While I believe that the scheduling causes a lot of trouble I also think that there is a lesson to be learned here. When teams work with parallel projects the work in these projects tend to be prone to have problems with teammates prioritizing one project over another. In our case we have one project were we are supposed to create a space shooter while at the same time handle our ordinary school work. These are usually handled as two different projects. When planning time in these two projects we tend to forget to check how much time our team have to spend on school. Some weeks are more intense than others and this is often not taken into consideration when planning.

I believe that this is a mistake. There is a big risk of over scoping, create stress and get in to situations were teammates can’t get a good idea of how much work they can commit to in the upcoming sprint. The different minors involved in the projects all have different school schedules and different homework. If this is not taken in to consideration and visualized it is hard to get a grip of the team member’s respective workload.

One way to lessen this problem is to have your team pull work items from the backlog. This allows team members to commit to the amount of work they believe to be realistic for the current sprint instead of forcing them to do more work than they are committed to. I also believe that it is important to visualize the total amount of work hours of each team member in their parallel projects. Instead of dividing school and the project you can make a combined backlog of both projects in one overarching backlog. By doing this it becomes easier to plan school and project work in one and the same sprint plan.

 

Current planning method

School 20 Hours (Not visible while planning)

Project 20 Hours

New planning method

School & project 40 hours

 

While it can be helpful to put school activities in to the backlog I believe that the main purpose of this should be to visualize the workload, not control the school work items. How team members handle school is their business alone. But don’t let it influence the project to much. All team members are still obligated to commit to the project. The important part is to help each team member visualize the current workload and make it possible to consider the work load from parallel projects while planning and committing to work items. If you don’t visualize your school work you skip out on visualizing 50% of the total amount of time spent working.

 

Example

Team member X need to study math for 5 hours.
Fix an assignment that takes up 8 hours
Take care of upgrading a failed assignment that takes 2 hours
and go to lectures that take 10 hours.

Suddenly you see that team member X has a workload of 25 hours. These non-visualized 50% of your work time is already over 20 hours. If you had visualized this it would have been easier planning around it knowing that you might need to put down 5 hours extra in school this sprint. While this might not be an issue if it happens now and then it adds up over time if X continues to have a heavy work load. This often creates stress, waste and overworked team members. In this particular case you would have had 15 hours left to fill a 40 hour week. This makes it easier for team member X to see the situation for what it is and commit to the correct amount of work that X feels is realistic. At the weary least this planning method should help visualize the workload of the team members and thereby help team members understand each other. This can lessen tensions in teams that feel an imbalance in the workload. The team is also able to make better estimate what can be done in the project.
Planing in one backlog might also contribute to help the team members optimize how they structure their work. Some of the things you are working on regarding school might actually be something that another team member might be able to help you with. The team might also be able to structure time so that they can solve both the project and school assignments more efficiently by working and planning together. This is done by optimizing the amount of use they get from working together. They might schedule working with the project for 3 hours, go on lunch for one hour and end by helping each other with math for one hour before going to class.

I believe that this also makes it easier for the whole team to balance (in the case of our project) the amount of art, code and sound that interact with each other. If an artist commits 9 hours to school work and 31 to the project while a programmer plans to work 17 hours on the project within the same sprint you can see that there might be too little code to make use of the art. This way you can plan around this to make the best of the situation. This lessens the amount of waste by avoiding to many asset imbalances.

While there are many good things with using the backlog in this way I also believe that it is important to not go overboard. Don’t let the documentation take up to much time. I believe that the most value you get from planning in this way in our particular situation comes from visualizing what needs to be done in and outside the project. It is also not supposed to force anything on the separate project. It is meant to help the team balance two parallel projects and make it possible to make better estimations and sprint plan commitments.

There are thousands of ideas on how to visualize and communicate.
Find which one works best for your team.

#4 Preparing for the end means preparing for a new beginning

Working within a project has a powerful effect on team members. As a project draws near you come closer and closer to the defining moment when it ends. It is both a cheerful experience if the project is brought to completion, but also a time of loss. In a project we build up an identity and a role. We create a structure and purpose that is tightly connected to what we do. It is our routine and objective. The more time spent working on a project the more embedded the project tends to get in our daily lives. When it is gone there is a risk of losing one’s sense of belonging. This is often referred to as project depression or post project depression.

Just as it is important to focus on the start of a project with a kickoff or some kind of bonding experience were you get to know the team, It is also equally important for the people involved to get a clear visible end. They need to know what will happen. This way they can prepare themselves and be ready to let go of the old project so that they can start on a new one. Just as the old project was a big part of their lives, the old teammates that they shared the experience with was as well. Parting ways can be both painful and bittersweet.
What happens in either way is that the project that they have worked on and the project that they will move on to will be compared. Both from a structure and team standpoint. When team members start comparing what was before to the new rules and team members there is often negative reactions involved if there was no clear end to the last project. It becomes difficult to accept that this is something new and not the same comfortable routine that you are comfortable with. There is a risk of power struggle were the old ways are proclaimed superior to whatever new structure that is presented. This conflict is far from the beneficiary situation where you bring with you knowledge and experience to a new work place. Instead it is a defense mechanism because of fear of losing one’s place. Creating a clear end to the earlier project can mitigate this. In a sense it works like a day of mourning. Not that it has to be a painful experience. It can be a happy party. The important thing is that it clearly communicate the end of something and a beginning of something new. This understanding, even if unconscious, will help many adapt to new projects, rules, structures and teammates. In a sense it is a good bye.

Our projects are nearing their end. It is time to take what we have done and reflect upon it. At this point people are starting to prepare and form new teams. This leaves some left behind and some moving on to new teams. This will affect their work. They might try to get a grip of what will happen and lose focus or they might think that whatever they do doesn’t count anymore. It is important to make things crystal clear and plan on what’s going to happen. Are you staying as a team? Are you parting ways? Are there still things unresolved that is in need of being taken care of? And how are you going to end the project? With this knowledge in mind you prepare the team so that they know and are prepared when the project ends. It is easy to lose pace at the end if you don’t give the team a clear sense of momentum and direction. These are the last miles before you reach the finish line, that doesn’t mean that the race is over. The time to leave the project mindset is not until you cross that clear, well communicated and visible finish line.

Preparing for the end means preparing for a new beginning
Be prepared when you cross out in to the unknown

Good luck & Gods speed

#3: Backlogs and the push/pull method.

When I started thinking about how my team could get the most out of our backlog I came to think about the problems surrounding how it is utilized. The traditional way is for the management to push items from the backlog. You can think of this like a manager holding “work” in his hands and giving it to a team member telling him to commit to creating this work item until the deadline.

The other way around is for the team to pull things from the backlog. Compared to the last example the team gets to look at what needs to be done in the backlog and then plans out how much they can commit to create under a given time period (example, a 2 week sprint).

Both methods have benefits and disadvantages but when it comes to small companies, or let’s say university teams trying to create a space shooter. I find it best to use the pull method. But like any agile method or process the pull method demands that the team takes responsibility and is self-organizing. If not you will find yourself in a situation where everyone is sitting and doing nothing while they wait for someone to take the initiative of organizing the work processes.

In my team I found that we had big problems using the pull method when the team as a whole lacked the motivation and routine to using it. On the other hand I find that the pull system has been a big improvement since our group become better at handling responsibilities. As a producer I found that one of the best methods to improve our work was to give decision power to my leads so that they could self-organize and create a good workflow. Many problems that needs to be fixed is taken care of as they arise instead of having to go through the process of asking the team about every detail first. Even If not entirely self-organizing it became clear that the team seamed more involved and interested in the project as they got to manage their own work. It also made work easier to manage on a week to week basis. Some weeks you have more time than others. Many times we have actually been able to go way beyond our weekly sprint plans. Many times I think that this is because the team thinks that what they work with is interesting while they also feel that the work items aren’t forced on them. We priorities the work and then take the parts that are most necessary and then chose in accordance to what has to be done and how much time we have. In the case that the team finds that we have made an error in our priorities everyone in the team can stop the process to correct the error. If the problem is small enough the problem is fixed on the spot without stopping the process. A lot of this would not be as easy if we used a push system were I take chose what needs to be done in the backlog and then give the work items to my team.

In conclusion I find that in my team as we got organized and motivated enough to make use of the pull method we improved greatly. Morale, efficiency, quality and communication is becoming better. I won’t say that all of this is solely because of the pull method. It is a combination of many things. But the pull system is a good approach for small teams that can handle it. Sometimes the push method is just better. But in the majority of the time as soon as you got a team that works and everyone pulls their own weight then you know it’s time to change. It is also worth noting that sometimes this change between push and pull can actually change someone from doing nothing into taking up phase and start working. Don’t be afraid to try. But don’t forget to plan as a team.

Good luck

#2 The Silent Hero

When times are hard and there is a lot to do you sometimes find a light in the tunnel in the form of a silent hero. Like Sam helpt Frodo in the lord of the rings a friend or colleague sometimes jumps in to carry you through the storm. Whether family members pulling through for you during hard times or friends comforting you through a though part of your life. I don’t know what we would do without our silent heroes. I will never be able to thank them enough for pulling through during hard times, or helping me realized that I could become more than I ever thought I could be. I’m even eternally grateful to that girl, whoever she was, who told me I was brave for standing up for myself.

Problems are like holes. When you fall down a hole of trouble it is easy to find yourself face down in the mud soon to be buried in work. You can be sure that when you are immersed in your own problems deep down in that hole it becomes difficult to think straight. All you do is either sitting still in silence looking up at the light wishing you never fell down that hole, or you claw yourself back up. Sometimes someone passes by and if you are lucky, that someone stops and offers you a helping hand. Whether you manage to crawl back up or find a hand reaching down to help you, you often find yourself doing one big mistake. The natural thing to do after getting up from a hole of trouble is to watch your feet.

Where am I going?
What am I doing?
Where is the trouble?

While this is important there is something we usually miss. If we rise our heads a little you will be damn sure to find some holes around you. Sometimes with someone in there shouting for help and sometimes with someone sitting all alone in silence wishing they never fell in there. This is alarmingly common and one thing we are good at in Sweden is to shut up and hide when we fall down in to our holes. Another thing is to stay away from those scary holes even if someone is in there. But be sure that when you walk up to those holes and offer your hand, a comforting smile, or a shoulder to lean on. The next time you find yourself in a hole there is a much bigger chance that someone out there will reach down to help you up.

When among others. Try to rise your head high. Watch out for holes and pick people up along the way. Believe me, this works professionally and in your ordinary life. People will remember kindness.

Be sure to repay that silent hero who once saved you.
Remember how much it meant to you.

#1 What the hell do you do when you start losing team members?

Dear readers, my name is Kim Ohlsson and I’m going to write about the project that my team Onmoraki and I are working on. We are supposed to create a space shooter game in based on one of the concepts created in the earlier course. We are supposed to plan our game the first two (2) weeks, go in to production for seven (7) weeks and finish with a PM the last week. As the producer of the project I it is my responsibility to manage the project so that we as a team can make a product good enough to pass Uppsala Universities “Game Design 2” course on Campus Gotland.

The first weeks

The first few weeks my greatest challenge has been to solve the planning of a project with a diminishing number of team members.

We started out with five members.
1 Producer
2 Artists
2 Programmers
0 Game Designers (We were one of the groups that didn’t get one)

In the first week our lead artist tells us that she is leaving the school, so we started replan and rescope the project. In the second week our sound lead (and new lead art) informs us that he is also leaving. So when the 2 weeks are done and we are supposed to present our plan for the project, we are still replanning and rescoping.  At this point we have.

1 Producer
0 Art
2 Programmers
0 Game Designers

 

As a producer I need to find a quick solution to this. So as a team we need to:

The challenge                                                             The solution

·         Find a solution to how to make the game without artists.	·         Change the art style in to something more manageable for our team. In this case geometrical figures and effects.
·         Find some way to manage the sound tasks.	·         Outsource the sound tasks to one of the programmer’s friends.
·         Be able to work without to many delays.	·         Dedicate time for the whole team to discuss sound and design to avoid future problems and have a clear goal.
·         Focus on the programing as it is our bread and butter.	·         Let the producers time between management, sound and design.
·         Keep up the morale.	·         Be extra vigilant and ready to call a break if you notice that someone might need one.
·         Have a plan.	·         Have as much communication as possible with regular short meetings.

 

The idea is to be able to give quick feedback and ask quick questions on daily standups 09:30 every day. This is modified by the producer (me) depending on how the lectures are scheduled. Then depending on day and school assignments we divide the day in to whatever need to be done at the moment. Our goal is always to reach our sprint goal of the week.

If you find yourself in a small team or one were only a few work efficiently then I think that communication is key. Every resource needs to be cared for and humans are the most valuable resource you have. Take care of them and keep their morale up. The difference between a happy team member and an unhappy one makes the difference between passionate work and a half-assed attempt to pass the course. Talk to each other and dare to speak up, but don’t be a douche. Find something positive to commend and try help each other aspire to your goal. But for the love of God, don’t shut up about things that really need to change. A team will never become a team until you get out of the inclusion phase. The more time that pass the harder it gets to resolve the problem. The only way to solve this is by communicating.

As it stands right now our team structure looks something like this.
Simplified communication mind map

This is somewhat of a temporary and hasty solution, but it works for now. Be ready to react to whatever happens next. And always be ready to change.