Continuous Improvement: Seeing the Invisible
You've probably heard that You can't improve what you can't measure and, over the years, teams have used various techniques to make the invisible visible. From value stream mapping to burndown charts, making things visible is a core component of the continuous improvement process. Brandon says that even with all this visibility, much of the data surrounding how your teams work is either not captured or not visible, and thus represents a great opportunity for improvement. Imagine your management team tells you that your velocity is too low. Why is it too low, and what can you do about it? Brandon shares one team’s surprising answer to that question when they analyzed previously invisible data. How do you know what the highest risk areas of the system are for enabling the most cost effective regression test strategy? You'll get that answer, too. It's all there, tucked away where no one can see.
Outline/structure of the Session
This is just a straight up talk. It has been given several times to positive reviews. It is typically given as a 60 minute talk but I can trim some of the interactivity out of it to bring it in on point to a 45 minute talk.
In this session we define the concept of "Data Exhaust" and how it's not only applicable to "Big Data" problems, but also is an important concept in continuous improvement initiatives.
We follow up with seven examples taken from real world projects where we captured previously invisible data and turned it into insights that helped our team improve their productivity. The following are the seven examples:
1) Tracking developer build times to make the business case for new laptops
2) "Amazon for Code", a Git plugin for reminding you to change commonly overlooked files such as "properties" files in Java
3) Defect Density Heatmap for identifying buggy code (another Git hack)
4) Using yesterdays weather to improve predictability rather than trying to get better at estimating
5) Using test run output to identify slow/brittle tests so that they can be fixed or deleted.
6) Using a key logger to identify amount of time really spent coding. (The developers requested this not the managers!)
7) Using Git to generate test plans from code change history.
Think about data exhaust. There is a treasure trove of data out there we can learn from and use to make better decisions and improve our processes/productivity. Maybe we'll even get better tools out of it in the long run!
Team members and leaders who want to see innovative ways of making better decisions using previously unseen data.
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Tim Gifford - "DevOps" on Day 1 with Operations First DeliveryTim GiffordLean/XP/DevOps CoachLean TECHniques
schedule 2 years agoSold Out!
DevOps lore tell legendary tales of “Unicorn” companies. We’re told these mythical companies continuously deliver software to production with nary a blemished aura or mussed mane. Can it be so? Is this but a fairytale?
In this talk, we will dispel the fantasy and show you how to get similar results. Spawning the first unicorn is the most difficult, so I will show you the specific steps, tools, techniques and architectural patterns of Operations First Delivery to create your first “Unicorn” project.
Dave Nicolette - When you don't need TDD and whyDave NicoletteConsultantNeo Pragma LLC
schedule 2 years agoSold Out!
Ideas similar to test-infected development or test-driven development have been around quite a while - at least since Alan Perlis wrote about interleaving small amounts of design with small amounts of testing in the 1968 Proceedings of the NATO Software Engineering Conference. Yet, even today, there are endless debates about whether such an approach is useful. Some consider it a baseline practice for any professional developer. Others consider it extra work that adds no value.
There's certainly more than one way to achieve a goal. What are the goals, when we write and deliver software professionally? Let's identify the various stakeholders of a software system and enumerate the needs of each. Then, let's walk through several popular ways of building software - TDD and others - and see how we can meet those needs using each approach.