Keynote: Continuous Delivery – Rebecca Parsons
- 4 minsBefore joining ThoughtWorks, Rebecca Parsons worked as an assistant professor of computer science at the University of Central Florida where she taught courses in compilers, program optimization, distributed computation, theory of computation and computational biology. She also worked as Director’s Post Doctoral Fellow at the Los Alamos National Laboratory researching parallel and distributed computation, genetic algorithms, computational biology and nonlinear dynamical systems. Rebecca received a Masters of Science in Computer Science from Rice University and her Ph.D. in Computer Science from Rice University. You can find Rebecca on Twitter.
This is a live blog. Please excuse any spelling mistakes, grammatical errors and nonsensical sentences.
When ThoughtWorks started using Agile, they didn’t need it like they do today. The time to market demands have gotten allot tighter.
The big question is “What is is were trying to do”. Hypothesis driven development. You need a measurable target to work towards, with a measurable outcome. WE need to know what we are betting on, before betting the entire farm. If you only take the safe bets, you’ll likely not find the kernel of awesomeness.
“If you’re not failing, you’re not innovating”
The new normal is to not know what will happen tomorrow. We need to be prepared for change at an increasingly high level. This is hard for people to adapt to, from a mindset perspective. We no longer have an ambiguous definition of done. It’s binary. Getting the granularity right can help with our definition of done.
We need to experiment more often. Create a rapid cycle and be ruthless in our automation to allow this.
Create a balance between predictablilty and opportunities, grabbing those which can lead to great outcomes.
Evidence, not guesses.
But how can we do this?
Continuous design and delivery will give a rapid feedback cycle. Be having a continuously updated version of reality we have up to date expectations.
Architecture should be Agile, and increasingly is.
We spend longer reading than writing code. By having high quality code we can spend less time remembering what we were thinking. There are metrics that can be used to indicate quality. There is however inherent complexity, no magic number. Some code will always be complicated. Using metrics from the start can help you keep track of the effects of team moral, team cohesiveness and the effect of hierarchical change.
Where do you start? Where there is the greatest impact. Talk to the team and business owner for insights. Talk to the people affected by bad code quality.
Build an architecture that you can test easily and switch parts of without too much hassle. An easier to test system is generally better. Move from a mindset of maintainability to evolve-ability. If you are open to rapid change, you need to evolve rapidly.
The last responsible moment is to wait until the last moment to make a decision. What is the right time? When you have as much information about the environment, requirements and user experience. Not all systems had the same requirements.
Continuous Delivery is as much about risk mitigation as it is about delivering features rapidly. “Deployments should be boring. Celebrate the features”. To do this you automate and standardise everything you can. Remove the snowflakes, don’t introduce them by design. Automated tests are a large enabler of CD. Even the smallest steps toward CD have a huge impact on the team, especially the poor person who gets called at 3AM.
With continuous design, you need to figure out what the vision and characteristics of the user experience will be. Thinking about design as a continuous process is super important. Tweak and evolve the UX without putting of the user. This is more critical than ever. Companies used to dictate how the user interacted with the software. Today, Facebook makes a change and the user expects this to be reflected in their banking app.
Conway’s laws states that the architecture of an app reflects the architecture of the organisation. There is an issue…. organisations don’t like change. To scale effectively you need to standardise and optimise, but startups changed this with a rapid change mentality. An organisation can’t be standardised and open to rapid change at the same time.
