What are estimates for?

Estimates are all about time. During one of last retrospective I realized that for some people estimates, and their role, are not that well understood. If not perceived well they can create pressure. Because what happens when we estimated the amount of work needed wrong? What happens when what we declared is significantly different than what we actually needed to fulfill our task?

Estimates are provided by developers and mean the most probable time when a given task will be finished. The most probable, not exact. Exact time can never be provided, at least not in software development.  This is something that both managers and developers need to remember.

Sometimes due to various reasons developers are afraid that breaking the estimate will cause troubles. When during the work some unplanned task shows up a question arises – should I take more time and work on the proper solution or do the task using duct tape and deliver my code on time? For me the answer is obvious, but as I lately learned not for all. Take all the time you need to rethink and redesign the solution, and implement it in the proper way. Ask yourself a simple question – what will satisfy your product owner or client – desired functionality that is working as expected or piece of crap delivered on time?

If your manager will be mad explain what is happening and why you have a delay. If you care about transparency and visibility of your work you manager will trust that you do all you can to deliver the code. If not, well then I’m sorry but the company should change the manager… Otherwise sooner or later the team will simply leave.

If you are a manger please remember what estimates are. If you create pressure on the team, the estimates will quickly become surprisingly high. People will start to add significant safety buffers just to be sure that in the worst case they will still manage to meet the deadline. In 95% of cases they will actually finish before time, but remain silent – wasting your time and money. Of course this will be the less professional part of the team – the more professional will be already working for some other company where the word ‘estimate’ is well-understood.

Advertisements

Agile By Example Light – subjective summary

IMG_20140510_135308798_HDRFor me Agile By Example Light which took place May 10th 2014 was really important event. Mainly because for the first time I had a chance to be a speaker on a bigger agile event, which I consider quite an achievement for such a newbie as me. I had more than a few presentations before, however speaking on such event is a bit more complicated and stressful experience. You’re not speaking in front of your colleagues anymore, but strangers who paid to be there and have certain expectations. Not in front of beginners, but in front of scrum masters, agile coaches or generally speaking experts with lots of knowledge and experience. That’s tricky…

First things first. The topic of my presentations was ‘Agile Games’ so I gave some examples of games I played with different teams and a bit of theory of games psychology, but not to much not to bore people. How it went? I think really not bad, could have been worse, much worse I guess 🙂 I really wanted the topic to be interesting to the audience and was a bit afraid that it might be too simple, however there was quite a lot of questions during and after the presentation and also a few people questioned me directly for details at the after party, which is even better. I hoped for negative feedback, but didn’t get any, which I think was more of politeness than my prodigious show.

The event included six presentations including mine and a little game called Ball Point Game. Everything very was well prepared and going smoothly, so big congrats for the organizers. Also the location was awesome with astonishing view on Warsaw city center.

Now let me briefly go though all the presentations done by other speakers.

Paweł Lipiński – Agile Bullshit, what’s really important in Agile?

Paweł did awesome, provocative and sarcastic presentation about marketing and hype around Agile and for me he got to the point well. Agile, Scrum etc. are just methodologies – a bunch of rules, which are not that complex to be honest – why we try to make it a kind of a religion? With all the coaches, masters and gurus the industry made Agile a mystical Holy Grail of software development with some convoluted, psychological aspects that were revealed only to the chosen ones (preferably with appropriate certification of course 🙂 ) leading people to forget that what really matters is common sense and hard work.

Marcin Kwieciński – Understand your boss

Marcin focused on showing people the other perspective on the everyday work – boss’ one. “Remember that each boss has a boss too” – good to have this in mind to understand some of your boss decisions and actions.

Agata Czopek-Rowińska – Lean Startup in practice

Agata described her work on mobile, educational application for children in mid school, which was a great example of application the Lean Startup principles – iterative approach, hypothesis validation, minimum viable product, testing with potential users (the children) etc. It was so nice to listen about such an interesting project with a positive influence on kids education. Even though I didn’t learn anything new as I know Lean Startup quite well, the general overview was extremely positive.

Michał Ślizak & Danuta Bemowska – Stakeholder jungle – a survivor’s guide

Really valuable presentation for all people who are thinking about introducing Kanban in their team. Michal and Danuta described their team before and after the transition giving a measured benefits such as increase in lines of code delivered per day and decrease in number of bugs. As I have seen transition from Scrum to Kanban done by 5 teams in my previous work the presentation didn’t give me any new knowledge, however I strongly appreciate its value for people who never witnessed it.

And last but not least.

Jacek Wieczorek – Agile Bootcamp. How to use Agile, to teach Agile.

Description of interesting and innovative approach to the process of training new scrum masters in the company. Instead of some standard theoretical in class trainings, “junior scrum masters” were working in a scrum like process – having all meeeting like planning session, retros etc. – where their tasks were for example join 5 teams retrospectives or facilitate planning meeting with one team. Of course junior had their mentors (like Jacek) who were not only helping them, but also performed a role of product owner in the training process. As for me this idea seems absolutely great!

Thank you

At the end I wanted to say a big thank you to Piotrek Burdyło, who gave me a chance and invited me for the event. It was great and I hope to have another chance to give a presentation in the future. It was really challenging, but also I felt so honored, to speak in front of such an audience and to be in a group of such experienced and professional speakers.

Photos by Agile247.pl here:
https://www.facebook.com/media/set/?set=a.863272843699964.1073741829.786798948014021&type=3