You tell me the problem, not what to do…
“A problem shared is a problem halved”. When it comes to working your way through the challenges that you face every day, it’s a great help to be able to draw on a network of supportive individuals that you can work with to find a solution. There are many of them. Of course you might expect certain help from them, but you also need to give something back.
|Ally||Can help you||Expectations in return|
|Team Members||Assist you with regular tasks
Be a sounding board
Credit – given both publicly and privately
Senior Management Members
Assistance with his/her tasks
Willingness to go the extra mile
|Support Staff||Willing performance of day-to-day functions
|Gateway People (Secretaries, Executive Assistants)||Provide you with access to crucial information and people||Appreciation
|More Experienced Colleagues||Provide expertise, perspective, contacts, knowledge||Respect
|Clients||Provide inputs for new product development initiatives
Provide preferential status
Willingness to go extra mile
|Vendors||Provide extra assistance
Provide preferential status
Can’t come up with more examples at the moment. What do you think?
If you are watching football you can find lot’s of stats available about different aspects of the game: personal info about each player, movement of the whole team, shots and much more. Here is one example about shots that Belgium made in second half (picture is taken from here)
But for some reasons it’s not always a case in software development and often focus shifts towards # of errors with common tools: Jira, Bugzilla and etc. Those teams who work according Scrum use burndown charts and velocity.
But is it enough to make conscious decision in the future and decide on further product improvements?
So, should we learn from football and think of more things to consider in a daily teams’ life? Some examples from the top of my head:
- Maximum capacity
- Time that user spends with your solution to solve his problem
- Growth of technical debt
- Where users spend most of their time
- Response times
- Users behaviour patterns per page, per component
What do you measure?
p.s. from previous post: one of the Scrum Master responsibilities is to radiate information.
p.p.s. Can you go even more crazy than that? Castrol Rankings Index
….Army that defends the country can be of three types: own, allied, hired or mixed. Allied and hired armies are useless and dangerous as you can’t use them as solid foundation, such armies can be as dangerous as enemy during a war – they will use your resources during a peacetime, but will not sacrifice their lives in times of danger.
Allied armies are dangerous as stronger partner will use the victory for their benefit, not yours….
Of course it’s not about war, but about building strong and successful company. Even though i made several points for myself keeping in mind context of a fast growing company working on a complex product.
- Keep unique and core knowledge or experience inside the company
- Spend effort on educating and training your team
- “Hide” core functionality behind APIs
- Outsource repetitive, mechanic, support or experimental activities that your team is not interested in. Give your team time to focus on core things and building API