High level estimate for any project

Posted on Leave a commentPosted in management, quick thoughts

Set up a dart board. Each point on the dart board represents $1M (1-20). The rings represent the following:

  • The bulls eye is $100k
  • The ring around the bullseye is $300k
  • The next ring out is .6x
  • The outer ring is .8x

Take three darts and aim for the bullseye. Average the scores of the three shots. This is your “high-level” estimate for each project.

p.s. originally read it somewhere and found it reviewing my notes 🙂

Vacations – good period to verify your team

Posted on 3 CommentsPosted in management

Summer time is a great time to relax and re-energize yourself. Overall output reduces a bit due to team members leave (good that it is temporary J).

There are various ways how teams decide to use their vacation:

  • Whole team goes for a vacation
  • Only part of the team goes for a vacation at a time

Not all managers accept first approach. And it’s a bit dangerous in case if team works on something sensitive that might require instant attention. I personally also think second approach is much better because:

  1. You still have a chance to solve accidents in case they occur, a bit of risk management
  2. Gives you (Scrum Master, team Member, Manager) a possibility to learn a lot about the team
    • And you can find out a lot of things during a relatively short period (2-3 weeks of vacation)

What we learned:

  1. Documentation and knowledge sharing must be improved
    • We identified that some team members have unique knowledge about some parts
    • It is not possible to find it out anywhere – no documentation or some hints at all
  2. Scrum Master can learn more about people and a team as a whole
    • It is very interesting to observe what people are really doing when there is a bit more spare time (no heavy load). Some people will spend time on learning, some on social media, others will go home earlier. It doesn’t mean that you must take actions, but this information can be a good insight in helping the team to improve

These are very obvious items (especially the documentation and knowledge sharing). But the best part about this is that all issues become more visible and obvious for team members. And it leads to team’s self-organization (maybe with some help of Scrum Master J) in order to solve these problems when everyone is back.

p.s. learning is not always very easy

20% of Time for innovation

Posted on 4 CommentsPosted in management

Is it easy to spend 20% of time on innovation and stuff that developers really like to do? I think definitely not and the success is not guaranteed …

  • When can a developer take his time?
  • What restrictions are there about what can and can’t be done in that time?
  • How do people manage their schedules? Should they manage it?
  • Is this time should be tracked?
  • How is it decided what people can work on?
  • How do you stop someone’s project if it’s deemed not useful? Who deems it this? Is there a committee? Peer review?
  • How do projects “graduate” from 20% time?
  • How is overall success of the program judged? $$? Customer value? Engineer happiness?
  • Should developers form a team, or should it be single projects?

But despite all these difficult questions probably it’s worth trying … What do you think?

Time boxes?!…

Posted on Leave a commentPosted in management, process

Why timeboxes? Today I completely understood the reason of timeboxed meetings in Scrum. Apparently its as simple as framework itself… 

It is especially easy to notice when you observe new teams. Most new teams do not fit into planning time box. Not experienced scrum master and product owner will make all effort to continue planning and fit maximum into upcoming sprint. If you notice such behavior – stop it right now and start working on those things that team managed to plan. Based on experience, if team doesn’t make it into a time frame it means that they are not capable to understand and commit on this at the moment. Leave it for now and let the team to learn!

All time boxes are need to understand your capacity, that’s it.

p.s. picture is taken from here – http://blog.3back.com/tag/time-box 🙂

Agile Day

Posted on Posted in management

When everybody is talking about Agile frameworks everybody tries to focus on various practices related to planning, development, requirements split and etc.
But all this means nothing when you forget about personal responsibility and time management.

All talks about commitments, time boxes, reviews and retrospectives is nothing when you are not able to manage you time.
Keep in mind following things:

  • Don’t be late to meetings
  • Have agenda for you meetings and keep them according that agenda
  • Don’t organize meetings if you are not sure you really need it
  • Respect other’s people time