Abstract: Learning to Experiment
The best organizational changes in my career have happened as a result of emergencies. Support for the process of experimentation only seems to become enabled whenever the status quo has completely broken down. In those moments of crisis rebuilding with better has been possible, but why do we wait? In this report I share our experiences with experimentation at Hunter and encourage you to develop a culture of continuous improvement and continuous experimentation that will get you to where you want to be without having to be in a crisis mode.
Today I am the director of a new software development department and we continue to utilize Mob Programming as well as many other practices. This report is about my journey through software development and specifically the experiences I have had with the process of software estimation. We are currently a department of 27 with 6 full time mobs; each team does not estimate software but instead practices pure Kanban and delivers vertical slices of software daily. Hunter is not the first place I had dropped the practice of software estimation for a project. Back in 2007 I was working in an Environmental Chemistry and Military Contracting organization that had a more traditional waterfall environment. During that time, we created a Gantt chart of how each project would go until one day there was an emergency that prompted us to do things slightly differently. I have come a long way and experienced many iterative steps through my software development journey. Let’s start with where we are today and work our way back discussing practices and insights we discovered on the way.
View the Experience Report Lessons Learned from Your Experience: - Experiment with process and technical direction now, don't wait until it is too late.
- Emergencies can give you space to experiment when things are dire.
- Artificial constraints like estimation can get in the way of your team developing their skills.
- Dedicated learning time for a team is a prerequisite.
