Taggify just launched a new platform that allow get your own bidder within a few minutes! You can get 1 to N bidders and distribute your endpoints selecting the location based on supply and latency.
Other great features: Up to 12000 QPS per instance and with Real-Time access to metrics!
Bamboo is a conductive pipe with no intermediaries, programmatic media buying through Real Time Bidding!
More in: http://bamboo.taggify.net
There are many ways for lead a development team. Some of them require a work of long term, and other are more practical. The long term is not viable, because the members of a team in this sector is changing constantly.
I know three ways for lead a team that is succesfull if we combine them:
Leader with direct orders
This dictatorial way can be used when a project is in crisis, about to fall. In this case the team need a decisive leader and with personality. Also is helpful when must be a make radical changes. Sometimes the members resist to radical changes, or to new labor policies.
If you have member without compromise or enthusiasm you would up the team with this way. But this not good to long term, because some people can be desmotivated.
The coach leader
The coach leader is a technical referent that cooperates with all the team. He take desicions together with all members. Using this method, you should share the knowledge and generate feedback constantly . Each step is explained and discussed with the workteam, empathy and enthusiasm and promoting the personal growth.
The risk of this is the low productivity because the under control.
The director
Working of this mode the leader shows the way, directs the activities and monitors all process but doesn’t participating directly. Supports all their trust in your team. This is useful in teams with high degree of motivation and compromise. In short: direct and delegate.
The great disadvantage of this is that team feel that their leader is not actively part of the team and no commitment as equals.
You must combine this ways, depending of the circumstances. Anyway, be honest, listen of your team, delegate and respect regardless of the technique used, is the most important… for me 🙂
Many times is thought that when starting a new start up project, we must be quick in gather the requirements, quick in development process, quick in test process… etc. We must devote specially attention and time to the requirement process. This step is the more important, and this step is decisive for the success or failure of the project.
I thought some fast tips for starting a new start up project:
This few points seem fast, but it is a round trip with the customer of many meetings before starting the new project. In each meeting the customer will define new features and flows, and the original idea will mutate.
Mutate a started application can be very difficult, or not viable, for that reason define this points before of start is the best way of avoid the failure.
Define first… take five 🙂
In software engineering become independent the people of the processes is not an easy task. Even more in start up projects. We can know some methods and practices that we are likely to lead to success, but we are never entirely sure and that’s because every project and every workteam is a world in itself. However, we can always limit to the maximum the errors and failures following simple practices and processes that will help us not to trip over the same stones.
One of the advantages of having trained leaders in the workteams is that we can count on your experience. They will remember cases and situations that led to the triumph of their teams and recognize those practices that led to fail. One of the problems is that in the development market and start up solutions, the workteams are disassembled and technologies and processes become obsolete quickly.
When a challenge arises or a new project appears, the first thing we do is look for documentation about it. Seems that there is always someone who has taken the trouble to share and document information. We have to document in detail our successes and to apply it despite the time, techonologies and workteams. We analyze and write what led us to a happy ending, or failure to learn from it. But also for others who continue to the project, or who entering the team to have everything needed to adapt and continue working -which means cost savings when it comes to bring in a new member-. It’s very common to see people coming and going every day in the development companies, and is more common to see companies lose the control of their projects by this constant employees flow.
When making decisions in a team, forms of work are chosen or agreements are made, is important to write and document a methodical way. All agreed and discussed at each meeting must be captured to take it as reference and guide for our daily work. Is very easy that the words are carried by the wind, and the responsible persons are hidden behind this fact. When the agreement is documented we have a record and evidence that sometimes it helps to keep the wheels on the road.
This documentation of agreements and meetings is also valid for customers, they also must be able to refer to everything discussed and agreed in an easy way and anytime.
The customers want efficient and simple products, but mainly they want it fast and at low cost. Document takes time, therefore increases directly on the cost of the final product. Find the balance between a relatively detailed documentation and the time available to apply is one of the challenges of development of agile applications companies.
There are many methodologies to implement at low cost but in any case it requires a number of practices in the development process and a series of complaints from developers too :). In any case you will need:
This is how a policy of documentation in your workteam will allow you the projects become independent to the people, learn from your mistakes and repeat your success.
Now, as always for closing I leave a new auditory adventure 🙂
Articulate a developer workteam is not should a easy task. Again… in the start up projects all is fast and should be practice for get the final product to customer quickly.
First, we need choose a methodology for organize the work. All the team should know in details all process of work. The way most choosed usually is the Scrum. Why scrum? because es very easy of apply even the dumbest person can work with scrum methodology and not needed many roles. An simplified way of Scrum should be have:
A system of comunication is essential. Forums, internal messages system (chat), tracker system (fundamental) and a series of regular meetings. The meetings of team is particulary important, this allow to the all team analyzes, shares, talk about the problems or detours and take some decisions together. Any member of the team should can request a meeting for talk about contingences, new ideas or new challenges.
The motivation is the heart of the team. Many enterprises leaving aside this aspect, instead apply more control systems focusing the motivation in the member with the highest roles. But the point is that all the team must be motivated, with energy and especially considering what the customer wants.
This point has become the most sensitive for some development companies. They are dedicating considerable time and resources for obtain motivated teams. Is very common see games rooms, training events, special benefits, extensive and comfortable places of work with high technology in the development companies.
Personally, I think like any worker -in a ideal world- each member of the team must have a competitive salary, be heard and love what do.
For you… “First Circle”
In the market of the development of applications for start up business, the estimation of the projects is one of the most crucial tasks. It depends largely the success or failure of all the project. Detours, delays, incidentals and other external factors affect the development time and in the start up world there is not time for a complete planification of project.
However, it’s our duty devote time and effort required for find a way of standardize the estimation process. Why standardize? for reduce the effort whenever a new customer appears. The standardization processes allows invest the effort once.
There are many techniques for the estimation. But, I have some shortcuts for start up projects that usually consider:
Once we have define this, we create a small guide for follow each time we have to estimate.
And now… Fabiana Cantilo
