Speaker: Sven Peters Atlassian
2012-10-16 | 10:25 AM - 11:15 AM
It was a really good morning session. Sven explained these seven things and carefully covered each point with pros and cons about why we should check each one of them, in order to get a good and productive team.
1. It's Flow time: Define a productivity area/time for the team.
Interruptions cause a lot of disruption at all levels and its one thing its not seen as bad as it is. Some experts say that for each interruption we need about 10 to 15 minutes to get back to our full concentration and focused productive time. So protecting the team members of being interrupted its a key point to help the team to be more productive.
Following Sven's recommendations, some practical actions that we can take to protect the team are simple things like define boxed times to isolate the team from any external interruptions, during that time we can display some sign like "Non disturb period time" or "Restricted area" or any kind of creative message to make it public that its developing time only. During that time, if team members needs to discuss about anything, they can go to another meeting room or some other area. If some external support needs to be provided there is always one member of the team, with some distinctive sign like "ask me", who will be to one to be registering and managing any external needs. This member of the team can then crate new tickets and assign them to the most suitable colleague, or he can provide direct support if possible. This responsibility is roiling everyday between the team members.
2. Feed your brain:
Promote and encourage any kind of learning event is a key point to keep the attention of the team members in synch with the company principles. Organising coding sessions at evenings, or lunch time "brwon bags" sessions about short presentations or even watching conference videos are the perfect simple things to keep the "buzz".
One thing i experience though in some companies is that it is hard to keep those events over a long period of time. In my opinion, companies that does not support those activities are loosing the best resources in terms of return of investment in good practises. Which can be the big part of the RoI for any software project.
Its hard to understand why software companies are focused to work in a cartoon paper style instead of working for building real assets, bricks for the actual growth. I guess its the wrong combination of short view and the quick rewarding fashion.
3. Say: "Well done"
Like in life, the small things are the ones to be appreciated. Caring about details make astonishing final results, see for example Apple products and philosophy.
The appreciation of those things needs to be public, generous, real and honest. There is no point to request for approval of any kind of work recognition, it kills the point of the whole thing.
Colleagues job recognition needs to be the normal flow, not the exception. Colleagues respect and like to work with good colleagues, so a simple white board to make public the achievements could be enough to start encouraging people for the care of the small things, in order to build amazing craft.
4: Report robot
Cars have a nice (some cars more than others) dashboard which indicates at all time the car's performance.
Why software projects have at most just a manger collecting manual data into a spread sheet? Because nobody built the dashboard, so most of the software projects goes over speed, overheating, over budget, over implementation, under user expectations, etc .. until infinite. Of course, there is no way to know where is going anything without a dashboard, all what we do otherwise is guessing.
All data should be collected into a proper database, ready to be used and processesed as necessary for any manager who needs to know what is the actual state of the game.
Its the only actual way to make forecasting and arrangements on the way. One needs to know when the car has missed the road and is going directly to the cliff.
Make the data public on big screens its a good way to allow people to see what is the current situation of the project. Let people talk about that current state, let them take action to move the project as required. Let people take proactive or reactive actions when its the time for each one.
5. Eat your own Dog food
Lets eat your own dog food. The best way to understand the customer is by experiencing the same pain, see things in action, do not let your users complain in vain.
We should find the best way to get actual feedback, as soon as possible from the users. Take time to understand and take the proper actions for each situation. It does not mean that we need to react and redo our job for every customer complain, but we can have a wider and better understanding about each issue, and then take the proper solutions.
6. Do a special Day
On a given day, invite people related with the project to work with the team. Work all day in one of those usually forgotten tasks like documentation, testing, clean up code, re-design, re-factoring, clean up back log, ... eat healthy food, call old friends, ... :-)
These days should be prepared forehand, all should be setup properly in order to make the day smooth and productive, as those tasks are usually specially forgotten due to false reasons which prevent exactly to do that work.
7. Experimentation time:
Team members should have time to build and play on prototypes, add and test innovations, do prove of concepts, spec new interesting or silly ideas, ...
Those kind of thing extra motivate anyone involved in the project, specially if some of those things are finally implemented as part of the final product.
Contributing to open source projects is one of best inputs for anyone to learn about new things, it can be new management ideas, technical solutions, new tools, etc ...
One good idea by Sven, was the recommendation of doing one week of innovation after each Scrum sprint. Personally i see it as a really good idea, that can contribute positively to many aspects, like project results, personal improvement, team spirit and many more.
And as an over all summary, Sven recommended to measure, take metrics, for each one of the management ideas. The only way to check if an idea had a good or bad impact on the team / company is to measure it.
This of course involve to let managers or team leaders try and fail. Not all ideas will work and actually only few of them may succeed, but the only way is anyway try it. Make the ideas yours and apply as well as you know.
Overall, very good and interesting talk of Sven. For more details on this talk see svenpet.com/slides
Thanks for reading this post. More coming soon ...
Posted by Marc Andreu.
No comments:
Post a Comment