DevOpsDays Vancouver 2017
DevOps Days returned to Vancouver this past weekend at UBC Robson Square. As a friend of DevOpsDays, our Founder Amin gave a talk on estimating slowly during agile development, and the dangers of incorrectly estimating too quickly.
You can download the presentation deck from Amin’s talk.
00:05 – Intro
How’s everybody doing?
Ok, so, my name is Amin. I’m from A.Y. Technologies and I want to talk about Estimating Slowly.
Couple of Best Practices for Agile Companies to slow things down a little bit. We need that!
Ok! Projects fail, and there are many reasons they fail and this could be anything from being late, to completely going to garbage.
Those failures can add up and can cause companies to fail as a result of each individual failure.
We used to do waterfall. It was painful. It was very time consuming. Not efficient at all, and it wasn’t good with change. You had to go through the whole process to bring any change to the system.
And that was not working well, so we started agile.
01:00 – From Waterfall to Agile Framework
And it was so useful, you could do things faster and more efficient. You can get things done in less time. Speed of things [projects] was improving so much. We enjoyed it so much that we tried to Agile everything!
Anything you could think about it we made it agile and it became the buzz word.
And when it became a buzz word, everything was about the speed. We actually devoted everything in the process to gain more speed. Make it faster, develop faster, get things done faster. Along the way we lost something. It got us to here. We had no idea what we were doing because we started with how we wanted to do things. We started projects so fast that we didn’t care about What we are doing or Why we are doing those things.
We wanted to get things done as fast as possible. And that cause bugs!
More bugs means more failures which means more risk to each project and more risk of failure and more risk to our companies.
02:13 – Why to Slow Down
So, that’s why I think we need to slow down. We need to slow down and figure out why we are doing things that we are doing?
Why are we starting this project or that proof of concept.
And when we start with what and why we are doing things, that’s when we figure out that not everything is worth doing.
And when we understand the projects, we can estimate them better. We can estimate them more accurately to reduce the final risk that we are taking with each one of them.
And when we estimate things correctly, then we actually get value from that. When you “Guestimate” you reduce the value of your work, and you gonna stop estimating all together cause you are not getting the value.
And when you slow down you are going to see things more clearly. You are going to see the corner cases and you are going to estimate them into your project before they become bugs that you will get at the end of the project that are going to add more time and cost more money to each company.
03:15 – 6 Helpful Tips
So I’m going to share 6 helpful tips with you. I know that you all probably know them but sometimes we forget. Sometimes we forget and I want to remind us that these are the things that we have to spend time on, and we need to pay attention to.
The first one and the most important one is the definition of done. We all know that we have to have a definition of done for each of the tasks that we are doing but sometimes we forget. Make sure that you have a definition of done. Make sure the team knows it and make sure that you enforce it.
Estimate for QA as you would for a feature. QA is part of your development. If you don’t estimate for that, you are going to end us with higher risks of failure. That could be manual testing or it could be automated testing, but just estimate them.
Small Features! we all know that small features are easier to estimate and easier to get done. But sometimes we don’t do that. We as human are much better in estimating smaller tasks that bigger tasks.
As human, we are so bad with estimating things accurately in hours, but we are good at comparing things. So start using your user story points and don’t make your story points equal one hour or two hours or a day. Make it actually something that you can compare with.
Acceptance criteria, it takes time but it’s not a time wasted. It’s actually a very useful time. Put that in your user stories.
04:43 – Conclusion
And at the end of it, compare your previous sprints and adjust as you go. The process itself should be agile. You should make your agile process more agile by making the iterative loop and getting the feedback from the system. And that’s my info and Thank you.