A modern approach to PM (Project Management) with fixed amount of time for your project. 1-day project to N-days optimizing process, sharing informations and with some useful R&D timeframes.
Project management is for sure something not very easy to handle, your scheduling is always in a hurry and time is always running against you.
There are tons of approaches to reach your project goal with a good performance, but I learned so far that if you grab a book like this, start reading and learning the concepts proposed inside... well you will not go so far with your project.
The most important thing, if you are a PM, is to be able to be smart. If something is going wrong, you have to be able to handle it as soon as possible, but you know you are not a dev (or you are not a dev anymore, because you cannot be PM and dev at the same time) and you have cooperate with your colleagues to have all the information you need.
A project is a complex system composed by lot of figures that need to stricly cooperate. The first thing you need to deal with is to create a collaborative team, you have to trust in your devs and they have to trust in you.
You have to start dealing with the thing that you are a big and unique team, like it happens during a football match (probably other people tried using a militar approach in order to try to help you speaking about this, but I'd prefer to use sport).
PM is like a coach, devs are the players. The project is the match.
Once your team overall structure is designed, you can stop working as a technician. What? Yep you listen very well, now you have to act first as a mix between a sociologist and a psicologist.
You have to start working with your colleagues, teammates, friends. I know it's not very easy to have different people working togheter, they are different, with different approaches, you have to start learning a lot about them in order to prevent and handle any possible problems.
Every people saying that a problem inside a project is only connected to a non-well written process is telling you half the truth. You have to work with people and process are schematic closed approaches to a problem, each man can approach them in different way and only a differing shade can collide with the normal approach of another dev creating caos.
If you decide to be a PM you have to know about this, you have to know a lot of your devs. You need all the information about their relevant and less relevant job skills. You need to know if is there any friendship in act and if someone is not looking good with each other.
Yep, I know I'm asking you to be more addicted in your team before starting doing something.
How to do it? Invite you mates for a pizza, a drink, a bowling game... everything that help you to stay with them and them with each other is interesting to you.
During these events try to stay with all the people, you will reduce any possible risk of jelousness, and you will learn a little from all your devs.
This process has no an expiration date, feel free to set it weekly, monthly... but you need to do something like this. Most relevant part: you haven't to do it during luch, it's working time and there you risk people will talk about their job. You have to create a team during extra working time and people are not allowed to talk about their job. These are the three fundamental rules:
- scheduled on extra job time only;
- scheduled with a fixed recurring time;
- you and them are not allowed to speak about job;
As I said before this need to be a never ending process, you will never stop this kind of activities or you will start loosing control and information about your group of devs.
Once you are a little more addicted to your team you can start manage it in a good way.
If you feel something is going wrong try to communicate first with your mates, say them are free to raise their hands and underline any problem they are experiencing. It's not a personal failure and you have to help them to start the right feelings to approach an issue, a bug, an unxpected problem in this way. Fix it as soon as possible and move on.
But write down about this problem, note it and during post mortem analysis ask your devs how to get rid of this in the future, how you can help them not to fall again in a trouble like that.
So what are the best attitudes a PM should start working on:
- stay inside the team;
- learn about your colleagues;
- be predictive, as soon you smell something is going wrong try to ask devs to help you;
- be cooperative, you are not a media agency, time is fixed, so shut up and don't swear asking your team to boost up. You are stressing them;
- help your colleagues to learn and let them to work on topics they prefer in order to collect the max from each one;
- be aware that problem and issues exist and you, and only you, will have to deal with them to fix (devs will have only to warn you about them);
- keep your project under control, upgrade your schedule daily (or if you can every 4hours) and check the progress against the expected one;
- be proactive, you can manage the team in order equalize the task progress;
- schedule and share all the events connected to the project with all your devs;
- generate a clear daily report (it's your bible during the post mortem meeting);
- ask your dev to stay always updated with the technology (please browse Github explore!!);
- if the project is in trouble, speak with your team and find a solution togheter;
In little words you are not alone, you are inside a team. If your striker scores you will win with your team too. If something is going wrong, say your teammates that's time for a little timeout. Figure out what's going wrong and patch it as soon as you can. As it happens in soccer, you have the 66% of the possibilities to achieve a positive ending for your project.
In the next paragraph we will try to figure out some ways to help you to avoid to fall down in the 33% of insuccess.
Bullring Development is not for sure something totally new, it can be consider as a mix of different development methods, trying to extract the best from each of them; for this very reason you will be familiar with some of the concepts that I'll try to explain over there.
The main idea is to revamp the actual project management approach trying to fix at least one parameter of the well known triplet: time, cost, quality.
Our purpose is to fix time. Each project will be always max 30 days long.
But before going a little deep.. why did you named it bullring? I traveled in Madrid this year and I visited a famous bullring in the city. It's a small circular ring where the bull is under pressure and need to win to stay alive. And for sure it's not easy at all for it. It's a bit cruent concept, I know, but any dev company need to win over its project to stay alive (economically speaking off course). And also devs hate red color of bugs listing software as bull hates red color too.
First of all you need to a good number of devs. I know this is the first huge problem... but I will hurt you much when I'll start speaking about their level and skills... So please wait a little more before start swearing!
The method is strongly focused about these two important concepts:
- when you ask for an estimate a dev will consider a 8h full working day;
- this never happens in real life due to several factors;
So the first idea is that the time you can expect the best working effort by a dev during a day is less than 8h and it stricly depends on his skill.
We are not so far from Pareto's concept, but revamped in a way that probably split is no 80-20, but something like 60-40.
You can try to disable mail, phone, etc, but it will sound a bit too much complicate and ineffective... they have to collaborate, talk, discuss and find information so it's not possible at all to reach 8h/day of full work on the project.
The ideal day approach should follow a path like this (assuming that your working day is 9am - 6pm).
9am - 9.15am Junior dev - github, delicious scouting for new and interesting things Senior dev (team leader) - project meeting (a kinda daily scrum)
9.15am - 9.30am Junior/Senior dev - team breifing about today task
9.30am - 1pm 2.15pm - 5pm Junior/Senior dev - development
2.15pm - 2.30pm Senior dev - quick project meeting to figure out issues or dependancies
4.30pm - 5.45pm Junior/Senior dev - debug & release feature
5.45pm - 6pm Senior dev - release meeting
You will have noticed that I always deal with Junior/Senior dev duality. The main concept behind bullring is that each team is always composed by minum 2 devs: a senior one and a junior one. It's not extreme programming, but the main idea is that collaborating they can increase both their expertise, the junior one in coding and team working, the senior one in coding and project/resource management.
Stealing a web common word it can be considered like a kinda P2P development method.
A team is the basic unit of a bullring based project, the number of dev is not fixed, but the basic setup is composed by:
- a senior dev;
- a junior dev;
Assuming they can provide a real full working value of 1.18 ratio (0.62 senior, 0.56 junior). I know is real pessimistic, but you know it's better to use pessimistic values in those cases.
Now I said that the amout of time is always 30 days so how to manage/create teams?
First of all you need to setup a plenary meeting where all the coders can listen to the project specs, ask question and going on.
Then you simply need to ask: can you try to provide me an estimate development time if you will work on this project alone?
Each dev will provide a value, if all the devs will stay under 30 days, it's quite easy, you will have 2 teams:
-
dev team
-
1 senior dev
-
1 junior dev
-
jolly team
-
1 senior dev
It's quite easy, with this setup you have an effective working value of 0.62 + 0.56 = 1.18. So your project is expected to end in 17 days. Any extra day will be used for deep testing of your solution.
But what happens when the estimate is higher than 30 days?
It's quite easy here too. First of all you have to figure out that a 30 days long project needs at least 6 days of full testing, so your real coding (ok debug is coding but now we will assume this like separate things) day amout is 24 days.
So let's grab the highest value in medium provided by coders... wait what does it mean?
If you receive these estimates:
- 32
- 36
- 35
- 38
- 52
You will have to grab 38 as worst value to start your assumptions.
So first of all you need to find the ratio to have a 38 days long project to be completed in 24 days.
38 / 24 = 1.583
This means that you need 1.6 times the basic number of teams in order to complete the project. We can't slice humans (it's forbidden by law), so we manage to round it to int number: 2. So your project will be composed by 3 teams:
-
dev1
-
1 senior dev
-
1 junior dev
-
dev2
-
1 senior dev
-
1 junior dev
-
jolly
-
1 senior dev
You will have a total working power of 2.36/day (omitting jolly team), this means that in the worst scenario you will complete the project in 16 days. And any extra day will be used to test and optimize the project.
Jolly team is an extra feature in bullring. You know... shit happens, and jolly team will deal with it allowing dev team to continue working on the project as expected in planning.
It's not a sleeping team that is used only when something is going wrong, is a full effective team that can help other team adding extra resources if needed, but as soon something odd happens they switch off and starting their main work purpose.
The important thing is that they need to stay always inside the project, even when their official turn is not started yet, in order to know the project and be able to work on it quite seamlessly.
How to compose it? It's quite easy every 3 teams you need an extra jolly member to your jolly team. Jolly member needs to be always senior devs.
First of all is free, it's an idea based on my experience, you can read this little manifesto, you can trash it or you can try to improve it using comments, for sure increasing the experience base the algorithm can be only improved.
But why this looks interesting to me? First of all you can provide a smart approach to the project. Try imagine you are your customer, are you most interested in dev group that is able to solve you a problem in 30days or one in 60/70 days? Or even much more?
I know it's marketing... but 30 days is an interesting value, and you know you can be more smart and appealing saying.. 29days...
So the first interesting point is merely economically related, I can work faster (off course using more devs) creating something that the customer can start testing due to incremental approach.
I know you are a bit worried about this... And if something went wrong? What happens if the customer is not satisfied by the delivery? Or something is not working as expected?
First of all you need to deal with, PM need to be the man (or the woman) that deals with this shits... you already know this. Best best approach is for sure to write down an exaustive project document where you state down all the deliveries, the ETA and if you have any mockup or graphical design attach it.
You will have to use them like proof of work, if you notice too that something is not going well... stop and go back to devs, you already know that you have a 6 days buffer during the last part of the project, but probably is better if you ask the jolly team to deal with it meanwhile the original team is working on the next task they will have to deal with.
Otherwise if you customer is changing requisites you have to collect them and help him/her to understand what is happening and why you will have to do two things now in order to proceed:
- figure out the new requirements and estimate its development time;
- define a new scheduling for the project, figuring out if the jolly team can take care of this within the expected timeframe or if you are needed any extra day to reach your goal;
I will never deal with economics, but for sure if you will collect new requirements you will have to ask your customer for extra costs for sure...
As mentioned before Bullring method is far to be considered perfect, it should be used as a kinda suggestion on how to try to manage a team for a project, it's not a dogma and it's not the mere truth.
And also every team work in a different manner like an organism.
So credits can be shared between all the people I worked with in my past and in the future and that will help me improving this method.
If you want to share your experience, ideas and going on... feel free to do it via issue!
This work is free of any charge, but if you want to donate for a beer or a coffee feel free to do it!
Bitcoin: 1BWmKKaDzyvVqNQgZNUWV7rcU91MMqPAXT