7 things estimates are and are not for

Estimation and estimates are for …

+ … deciding how much you can commit to in next iteration

+ … comparing estimated features and seeing which one is bigger

+ … deciding if you even want to push for this feature for that work needed

Estimations are not for…

– … evaluating your team speed

– … deciding to how much to bill your customer for the feature (especially when you later get angry that you billed to little)

– … treating them as deadlines

– … deciding that you spent enough on the story and now it’s time to cut corners.

Would you agree?

Share Button

Time to GO!

I got amazing preset – I live quite ascetic life, and it was long since I had something that beautiful in my possession (not mentioning that I would not buy something like this for myself).

IMG_20150326_174505

I’ve never played GO before – now I will definitely learn.

I got it because I (kind of) leave my position at NexwayLab and travel to the other end of the world. Kind of – because I will not be ScrumMaster anymore but we still want to experiment with remote work. So I leave and I stay. That’s why I was so surprised to get a good bye gift.

I really didn’t want to leave Backend Team because of amazing people there and because of whole this journey we took together. Everyone developed amazingly for the last 2 years. The amount of mutual respect and honestly is quite extraordinary. And if I there’s possibility that I contributed to at least 1%  of this development and awesomeness – I’m extremely proud.

My ScrumMaster to Developer-only role went smooth since I always tried to share everything I do to my team (you know – in most companies there’s this force to make specialized people). This means branching model, release process, retrospective and planning.

I’m in a process of installing myself in a new place and Backend team was on their own for a while. But I was not worried for a single time – I left them for longer before. And I would have last tips for any mature scrum team

1. PO is not an enemy. He want’s to cheat around sprint and points. Don’t let him – but don’t hate him either – he just tries to do his job.

2. Everything is renegotiable. Any rule you made before, any path you took before can be changed when you realize it was a mistake.

3. Stuff that works will stay or perish when they don’t work (assuming point 2 works) – If #2 is not possible because of politics and bad processes stays because they were written. Because of “I say so” from higher management – this is not a place where teams can achieve excellence, you can start to think about leaving.

Now more personal remarks:

– Thanks to Jon for being flexible in many cases. We clashed often. We had different opinions often. Jonathan was the kind of boss who could take all those blows when he wasn’t right. That takes a lot of guts.

– Thanks to Mariusz – for achieving next level of testing and showing to others how to do it. He took “test it as if you want to brake it” deep to the heart.

– Thanks to Marcin – for team spirint. For being available every time going this extra mile was needed.

– Thanks to Łukasz – for giving totally different perspective and contributing with experience we didn’t have before.

– Thanks to Michał – for bravely taking over my responsibilities. For fresh look on the team, and amazing experience he shares generously.

– Thanks to frontend team – this is less personal because we didn’t work together that much. But whole frontent is a bunch of cool people, with cool ideas. Stay awesome!

 

Share Button

Best book about programming and design…

… is not a book at all.

Recently, when visiting some other end of the world, with limited access to the web – I ended up reading whatever I had stored on my pocket app. Luckily I’ve got there one article from c2.com/wiki.

I enjoyed it and can recommend to all of you (beginners could have little bit hard time, but give it a try nevertheless). This is a living book – with concepts and critique of those concepts (even OOP is contested ).

The site itself is super ugly and abundance of links could make it difficult to focus – that’s why I would recommend pocket app for reading (just save intriguing link for later).

Some of the most interesting topics:

ArrowAntiPattern – the anti-pattern is as boring as it can be, but the discussion is very interesting with lots of links to continue.
AvoidExceptionsWheneverPossible – I was surprised that someone argues that exceptions are a bad idea. (Btw: golang doesn’t have exceptions.)
ShieldPattern – again great discussion
Mentioned before: ArgumentsAgainstOop.

And more. Fell free to link in comments to articles you find most interesting. This wiki is huge and I’d appreciate if you share your path.

Share Button