00:00:16.830
Hi everyone, thanks for coming. I'm Vaidy.
00:00:22.360
This is Leena. We are longtime colleagues and have built a significant amount of software together.
00:00:27.550
I've got a confession to make: we're process geeks, and the impact of that has been felt by our own team quite a few times. Let me give you an example.
00:00:39.270
We have daily morning company-wide stand-up meetings, and Leena and I would very excitedly talk about topics like continuous delivery and continuous improvement during these meetings.
00:00:45.550
Things were going great until a colleague of ours asked whether we had noticed that the number of folks in the stand-up was steadily decreasing. It turned out that people were showing up to work just after the stand-up would finish. We wondered why we were discussing such interesting topics every day.
00:01:05.049
Recently, we met a friend who mentioned that process talk sounded to him like a trip to the dentist. I suppose that also explains the mystery of the declining stand-up attendance. What we will do today instead is to share some war stories and include thoughts on continuous delivery and culture along the way.
00:01:26.350
Are there any neuroscience geeks here? Thank you! If time permits, we'll also discuss some of that at the end of the presentation. So, continuous delivery—most of you know it's a large and complex topic with many approaches.
00:01:48.880
In today’s talk, we will focus on three key aspects of continuous delivery: building quality in, making your build always ready to deploy, and continuous improvement. We will also discuss necessary practices related to these aspects and how they connect to team motivation—specifically, the three components of motivation: autonomy, mastery, and purpose, which are crucial for sustaining motivation in a knowledge worker.
00:02:14.110
Before we continue, we must confess—we don't have PhDs in this subject, but we do have a thesis we'd like to present: practice continuous delivery, and you will cultivate a great culture. Let's begin with the stories.
00:02:58.380
The first story takes us back to 2010, when we were operating a software consultancy in Bangalore. A customer approached us to build a product in the consumer space, specifically a utility product. We suggested kickstarting the process with a two-day brainstorming session.
00:03:19.290
We had our Scrum kit ready, complete with story cards, multicolored sticky notes, and plenty of sharpies. By the end of the two-day session, we had over 100 cards neatly laid out on the table and listed on an online spreadsheet.
00:03:31.650
The next logical step was, of course, to start the estimation process. Following Scrum principles, we decided to go with story points and estimate each of those hundred-plus cards over the next few days. Fast forward a couple of days, and we had our estimates ready—it was going to be a nice, long six-month project after which we hoped to have a beautiful product capable of scaling to a million-plus users. Fantastic, right?
00:04:06.360
I suspect some of you can already see where this is going. We also injected a few more milestones into the process—three milestones to be exact. At the end of each of these milestones, we would have a celebration before quickly returning to work on the next milestone. We planned to work in two-week iterations as part of this Scrum-based system and awarded the team story points as soon as they finished coding a story.
00:04:41.010
We just couldn't wait for the testing to be completed. Monthly demos with the customer were also scheduled. Things were going well until about four months in when the customer requested a demo for an investor, with just seven days left to prepare.
00:05:00.870
We asked for a couple of days to get everything ready, and by the day before demo day, the entire team was camping in the office, feverishly fixing bugs. Let's just say that weekend wasn’t our best in the last four years.
00:05:26.400
Most of you might be familiar with this kind of setup. We have already discussed Scrum, but there's another aspect we need to consider: the Water-Scrum-Fall model.
00:05:52.380
Let me explain the Water-Scrum-Fall model. In this model, the 'highest paid person's opinion' (or HIPPO) drives the engineering processes without much input from the engineering team after they have received the instructions.
00:06:03.170
The engineering team is often in a tight spot, having just completed a Scrum training course, while the operations team sits in a secluded corner, ready to pounce on anyone who might interrupt them.
00:06:21.150
This was genuinely stressful for us back in 2010 when things went wrong. We wanted to fix the problems, not just to regain credibility, but also to retain the motivation of our team.
00:06:33.180
But where should we start? The simplest answer in such situations is to address what we have control over. The biggest problem we had was the quality of the product we were shipping.
00:06:51.730
That was within our control, and we aimed to fix that first. Fast forward an additional six months, to 2011, with another customer and a different project.
00:07:16.360
While the Water-Scrum-Fall model still applied, we made some modifications to our practices. By the end of this six-month period, we noticed significant improvements, especially regarding the team’s confidence and the reduced number of weekends and late evenings spent working.
00:07:37.570
The quality of the product itself was markedly better, leading us to no longer track defects in a separate bug list. This was positive feedback for us.
00:07:50.080
Our customer was also easier to work with this time, likely because we were making updates to the staging server much more frequently than in the previous project, which allowed the customer to provide us feedback at least once a week.
00:08:09.130
Let's return to the practices we changed, as they were a crucial reason for the improvements we experienced. We implemented practices to build quality in. You may have seen diagrams depicting phases such as analysis, design, testing, and development.
00:08:34.570
Interestingly, after the testing phase, many assume the bugs are fixed, but building quality in means integrating quality considerations as you write your code.
00:09:05.170
You need to think of testing not as an afterthought, but as an integral part of the process. Extreme programming (XP) offers several good practices to support this, with test-driven development being one of them.
00:09:43.500
Test-driven development provides a suite of regression tests that give the team tremendous confidence to make substantial changes to an evolving codebase.
00:09:58.730
This confidence translates into the team delivering high-quality software. Implementing practices such as continuous refactoring and pair programming creates a cohesive set of practices that facilitate the shipping of high-quality software.
00:10:19.120
While we've discussed the value of building quality in and the resulting improvements for our customers, we started noticing behavioral changes within the team.
00:10:36.180
For instance, when we began shippable software, the development team used to check in with the customer for every small change in priorities or planning. Eventually, as we delivered work more frequently, the customer began seeking the team’s opinions and left the day-to-day decisions to them.
00:10:55.560
The team started to feel a sense of autonomy and freedom that any team would cherish when working with customers. XP fostered a sense of autonomy that we observed growing within the team.
00:11:25.490
You might wonder why we're discussing extreme programming when our topic is continuous delivery. In our opinion, continuous delivery is a superset of extreme programming practices.
00:11:43.750
Now, coming back to our earlier discussion on quality, team motivation, and successful products. We had a fantastic product that was of high quality, and the day came for it to go public.
00:12:00.630
We organized a grand launch party to celebrate the public unveiling. However, a month later, we found that there were only a few users on the system.
00:12:17.040
Despite our expectations, we kept waiting for user engagement, but it never occurred. The customer faced funding issues and subsequently failed to generate traction for the product.
00:12:36.600
So, the customer decided to put the product into hibernation, and even now, three years later, we’re still awaiting their return. Even after delivering a high-quality product, the harsh reality was that it did not achieve success, which affected the entire team’s morale.
00:12:54.390
As a consulting company, we didn’t own this product, but the disappointment of our team was visible. Let’s move on to the next story.
00:13:00.900
Autonomy brings short-term happiness to the team; however, creating long-term motivation requires something more. What can that be?
00:13:34.960
We need to provide an environment that allows the team to connect with the bigger picture, so they feel they are part of something significant. I will explain this through our next story.
00:14:01.780
Recently, we worked with a customer who envisioned a network of tablet devices installed across various cities, controlling them remotely from a central location using web services.
00:14:27.940
Although the original plan was to build the entire system, the customer opted to develop the smallest functional piece first to test the tablet with real users.
00:14:55.580
As you might expect, we encountered several issues early on. For instance, the USB power cable provided with the devices was too short to reach the power source.
00:15:07.840
After ordering a set of longer cables, things initially seemed to work. However, after a day of usage, we saw that the battery levels had dropped by about 50 percent.
00:15:36.540
It turned out the length of the cable caused a voltage drop, affecting battery performance. We directed end-users to turn off the tablets at night and added a high-priority item to our backlog to automate this process.
00:15:53.710
We also addressed some usability issues through user interface tweaks. None of these problems would have been discovered had it not been for our customer's willingness to test an early alpha version with users.
00:16:10.820
This early testing enabled us to iterate on the product rapidly and establish a feedback loop with the entire team, including those back in India.
00:16:39.200
As a result, we were able to realize our customer's early goals to implement the tablet across multiple cities, attract advertisers, and test their pricing model.
00:16:58.290
What’s crucial here is that the customer was able to iterate through multiple versions of the application quickly. However, there were engineering practices in place that supported this process.
00:17:20.230
One key principle of continuous delivery is to always have your build ready for deployment. This means that whenever someone wants to deploy, it should be as simple as the click of a button.
00:17:39.040
To achieve this, we made changes to our software delivery process, reversing our estimating approach. Instead of asking how long stories would take, we started asking, "What is the simplest thing we can do in a couple of days to receive feedback?"
00:18:04.430
Next, we established a real continuous integration system where the entire team checks into the main branch and works on small chunks. This allows immediate feedback on changes and ensures that everything works with existing systems.
00:18:25.360
The third key aspect is the build pipeline, a critical part of continuous delivery. The build pipeline ensures that the deployment process is risk-free and fully automated, as opposed to being a mundane, error-prone manual task.
00:18:45.840
This pipeline also allows for the early identification of bad builds, preventing them from moving forward. It verifies that the same build transitions seamlessly from testing to staging and production environments.
00:19:04.050
While there are numerous automation practices required to achieve continuous delivery, I won't go into the details today. However, I'm available for those who wish to know more.
00:19:29.210
Ultimately, with these practices in place, deployment transforms from an engineering decision to a business decision. The customer can deploy any version of the product with just a click.
00:19:47.350
In contrast to the previous stories, this one has a happy ending. The customer was pleased, and the engineering team was extremely happy not just because of the multiple deployments, but primarily because they could connect their day-to-day work to the bigger picture.
00:20:07.800
This connection provided the team a sense of purpose in their work, leading to heightened motivation among them. Additionally, they engaged not only with the end users but also with the entire ecosystem, including network personnel and other involved entities.
00:20:30.430
This created a feeling of pride in their work and motivated them to continue improving on a daily basis. We have spoken about the importance of building quality in and making the build always deployable, as well as the motivational implications.
00:20:50.090
Now, let’s discuss the third aspect of continuous delivery: continuous improvement, which is crucial not only for achieving continuous delivery but also for maintaining it.
00:21:02.160
To illustrate this, I'll share a story from Toyota. Taiichi Ohno, known as the father of the production system, was part of Toyota in the 1930s. One morning, an assistant ran to him and stated that the plans for a newly constructed factory had been stolen.
00:21:29.830
Despite the assistant's nervousness, he remained unfazed. He communicated that it didn't matter that the plans were stolen, as by the time a factory could be built based on those plans, they would have already refined and improved their current systems.
00:21:40.790
Thus, the gap between what they would build then and where they would have been would be significantly large, rendering the theft inconsequential. This is the power of continuous improvement.
00:21:59.910
From the waterfall and Water-Scrum-Fall eras to continuous delivery, we have been taking incremental steps towards our goals. Interestingly, we weren't even aware that continuous delivery was what we were targeting just four to five years ago.
00:22:31.160
People today come to work motivated to build exceptional products and see their work as a craft rather than just a job. When one perceives their work as a craft, the natural inclination is to keep improving it. This journey towards mastery is the third aspect of autonomy, mastery, and purpose.
00:23:06.790
As Ken Beck reminds us, perfection is not a noun but a verb. Thus, the question arises: is there a definite end to the process of honing one's skills? The answer is no; it’s a continuous journey.
00:23:30.160
To summarize the motivation aspects we discussed, we covered autonomy, mastery, and purpose. The intersection of these three components leads to engagement—a state where a motivated team is highly engaged.
00:23:57.940
An engaged team becomes more outcome-focused. They love their craft, understand their purpose, and consistently connect their work to the impact it has on end-users.
00:24:18.810
The main difference between this engaged team and one stuck in a Water-Scrum-Fall approach is that the engaged team prioritizes outcomes over output, focusing on the software’s impact on end-users and the business rather than metrics like velocity.
00:24:42.130
So this is our team picture back in Bangalore, and we believe the smiles on their faces reflect the high level of engagement they have in their work.
00:25:01.450
Now, let’s shift focus to culture in continuous delivery. Culture comprises shared values and principles within a team. We hold two core values dear: delighted customers and continuous software flow.
00:25:43.960
To identify the practices that will help us achieve these values, we should focus on those that support motivation. Specifically, we seek practices that empower autonomy, provide room for skills improvement, and help connect daily work to the bigger picture.
00:25:58.590
Continuous delivery is an excellent approach to foster such practices. It promotes continual improvement and is purpose-driven.
00:26:16.310
By understanding the purpose of our actions, we bolster feedback and autonomy, making continuous delivery a powerful tool in cultivating a strong culture.
00:26:38.890
If the persuasive power of motivation isn't enough to encourage your team to adopt continuous delivery, perhaps an understanding of neuroscience will.
00:27:04.970
Let’s discuss two parts of the brain: the prefrontal cortex and limbic system. The prefrontal cortex governs logical reasoning while the limbic system is responsible for emotions.
00:27:25.030
Remarkably, the limbic system tends to focus more on negative emotions. You may have heard the saying that people walk toward rewards but run away from threats, which is rooted in how our brains are wired.
00:27:48.520
If the brain is predominantly engaged in negative thinking, how can we maintain positivity in the workforce? This is where the seesaw effect comes into play: your emotional and logical brain either functions independently or not at all.
00:28:13.060
It's beneficial to create an environment where team members engage in creative activities, as this helps steer them away from negative emotional states.
00:28:38.450
Moreover, the prefrontal cortex requires a certain level of stress to operate effectively. Stress becomes detrimental when there's too much of it.
00:29:01.290
It's hard to think creatively in challenging situations, but when one is adequately stimulated, creativity flourishes. Hence, creating that optimal environment at work allows team members to thrive.
00:29:23.990
Continuous delivery aligns well with these principles. It ensures that builds are always ready, keeping the team engaged and maintaining an appropriate level of urgency while providing ample opportunities for incremental improvements.
00:29:43.230
As a result, teams do not harbor fear regarding potential failures since they're making small adjustments. This removes the looming threat, allowing creative strategies to flourish reinforced by the functionality of the prefrontal cortex.
00:30:05.360
Our discussion today has touched upon many aspects, but let's return to our thesis: practice continuous delivery for a strong culture. The question is, where do we begin this journey?
00:30:27.560
Embarking on this path requires persistence and the support of evangelists. To cultivate these evangelists, pose two questions: Why does your business exist, and if it didn't, what would be missing?
00:30:51.060
Crafting answers to these questions helps connect to the purpose: understanding why we do what we do, enabling the team to be more autonomous and improve consistently.
00:31:04.090
To conclude, I'll leave you with an inspiring quote from Jesse Robbins, co-founder of Opscode, who said, "Don't fight stupid. Make more awesome." Thank you very much.
00:31:22.570
These are four books we've found valuable in our journey, and I believe they might be useful for you as well.
00:31:24.490
You can find our contact information on the website, and we are ready for questions if you have any.
