-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathessay_on_continuous_delivery.txt
18 lines (8 loc) · 2.97 KB
/
essay_on_continuous_delivery.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Please share a critical piece of advice that is supported by a personal story that would help a capable friend manage the transition to continuous delivery. (300 to 400 words is ideal.)
Your friend has been tasked with transitioning her company's software development efforts to continuous delivery. She's extremely capable, but she's nervous about leading the transition. Please share a story from your own experience that will provide her with a critical piece of advice that will help her to be more successful.
---
Ever since I started in software development, I have worked with skilled and highly educated colleagues. They have been product owners, project managers, architects, testers, sysadmins and programmers. All of them have had special expertise within their own area of responsibility. Having all these roles on a project, you would think that every aspect of a software project would be covered and that we would succeed every time. Yet our projects failed, as unfortunately most software projects do.
At some point, I was asked to be tech lead on a smaller project. The project sponsor wanted to follow the project closely, so we formed a close-knit team around her. I chose seven other people for the project and asked for servers to host the software we were going to build. To cut a long story short, the project was amazingly successful. We delivered a very valuable product, and with fewer errors than anything I had been involved with before. Adding new features was easy, and the project sponsor was extremely satisfied when she saw her ideas running in production soon after they were born. We were practicing continuous delivery.
The reason we were able to deliver high quality software with great value continuously was not that we were superhuman developers. I realized that the main reason for our success was that we only had three roles; the sponsor, the users and the "techies". I found out that any roles involved in a project that do not directly contribute towards the goal of putting valuable software in the hands of users as quickly as possible should be very carefully considered. We were not being continually measured by project managers or being pushed beyond our limits. Architects were not telling us what kind of products or patterns to use. Testers did not obstruct our changes from getting into production. Sysadmins were not trying to prevent changes that could destabilize their servers. We had to take responsibility for the testing ourselves and we worried about the infrastructure because we were the only ones who could be blamed. We delivered software incrementally to fail as early as possible so that we could correct errors before they got out of hand and get a feel for what the users really wanted.
Technically skilled people are used to solving challenges. The more freedom and responsibility they have, the more creative they will be – as long as their goal is known: to satisfy the sponsors through early and continuous delivery of software valuable to users.
----