Accelerate (Jan/Feb/Mar 2022)

[tomcudd]

Schedule

Accelerate Book

• Now-Jan 21: Intro, Preface, Chapters 1-2
• Jan 22-Jan 28: Chapters 3-4
• Jan 29-Feb 4: Chapters 5-7
• Feb 5-Feb 11: Chapters 8-9
• Feb 12-Feb 18: Chapters 10-11
• Feb 19-Feb 25: Chapters 12-13
• Feb 16-Mar 4: Chapters 14-15
• Mar 5-Mar 11: Chapter 16, Conclusion, Wrap

I'll add questions/comments/discussion reminders on each Thursday to talk about what we have read so far.

[tomcudd]

Now-Jan 21: Intro, Preface, Chapters 1-2 (Accelerate, Measuring Performance)

• Reading the foreword, introduction, and preface, does it seem possible that speed and stability are intertwined in successful organizations?
• Has anyone taken the State of DevOps survey? If so, do you remember what jumped out at you about the questions?
• Do you believe improvement is possible for every organization? Do you see potential for organizational improvement in your current situation?
• Can you think of examples of traditional non-software companies using software to improve service and/or customer experience?
• Does the difference between a maturity model and capability highlight any programs or efforts you see inside your organizations?
• Has measuring output versus outcomes affected your roles? (ex: lines of code completed or story points in a sprint)
• How quickly can you deliver code to a production or live environment in your personal projects? At work?
• How quickly can you recover from issues that are released into an environment?
• What kind of work do you consider strategic versus software or services that can be outsourced?

[tomcudd]

I always struggled with the idea that stability improves with speed in technical operations until I thought of how importance speed is in riding a bike. Going really slow means it is difficult to control.

I have taken the state of devops survey every year it has been out and it is really interesting to see the changes in tech reflected by the questions. People seem to understand better what organizations need to do just to keep pace with their competition or get left behind. But they don't know how to excel and succeed beyond their competition.

Maturity models are like a straight project plan where once you cross the goal line, you've won and can stop. Capabilities highlight being able to have a skill and improve on that skill. "We've implemented automated deployments, now we're done" versus "We've automated code delivery, now we're going to work on automated testing, then we'll..." and so on.

I talk about outcomes all the time. I may not get a ton of story points done each sprint, but the work I do has led to measurable success for the projects I'm on. And I can go on for days about queue theory and the problem with making technology workers "maximize productivity" versus creating the right amount of slack or "spare capacity" in a system.

I think HR software is a good example of a service that needs to be pushed out of most technical organizations. It's not a keep factor that would contribute to the success of an organization (unless you're building HR software).

[CuriousCurmudgeon]

Thanks for putting this together @tomcudd.

I do agree that speed and stability are often intertwined. Assuming you have good tests and good monitoring (and those are big assumptions), if you're deploying frequently, the delta of each change is smaller and easier to debug. My nervousness about a deployment increases exponentially based on how long it's been since the last deployment.

I'm torn on the idea that improvement is possible for every organization. In my time consulting I've seen some dysfunctional teams. I've seen small improvement in most of them during my time there, but I also know that some of them backslid after I left. I definitely see potential for improvement in my current situation. They were in very bad shape when I joined, with no meaningful tech team and nothing automated. There is still a lot of low hanging fruit to pick.

The idea of non-software companies is kind of an oxymoron these days. Software has eaten the world. We're surrounded by non-software companies that use software to manage their entire business. A huge chunk of the consulting world is helping these companies become more efficient through software.

I didn't even realize that I think of capabilities over maturity until it was put in front of me. At this point in my career, the entire concept of something ever being done is alien to me. That brings its own mental challenges though. You still need the mental wins that come with accomplishment while still accepting that there is more to be done.

I wasn't expecting this book to make me think about my conflicted relationship with story points. I use them, but I'm also very quick to caution that you shouldn't use them for measurement unless you have a completely stable team over a period of months. And my experience is almost exclusively with small organizations, so the idea of management trying to compare velocity across teams isn't something I've dealt with. I shudder at the thought though.

Sadly, all of our deployments at my current role are still manual. I've implemented some simple CI, but have not gotten around to any CD. The good news is that manual deployments are simple, but they're still manual. I have to go out of my way to deploy code to any environment. Recovery would be a pain though. The DB migration system the previous devs chose does not support rollback scripts. Luckily, we are a startup with almost no data, so that hasn't been an issue yet. It will be at some point though.

[tomcudd]

Jan 22-Jan 28: Chapters 3-4 (Measuring and Changing Culture, Technical Practices)

• Do you believe intangibles like culture can be measured?
• What values do you recognize and find important in an organization?
• Think of examples of pathological, bureaucratic, and generative organizations (either worked at or heard about). What do you remember about those places?
• What about places with great communication flow? Do you notice its ability to impact organization/team performance?
• Did you see collaboration and high levels of trust in those same settings?
• Do you believe that changing the behaviors through expected practices can influence an organization?
• Have you been part of a continuous delivery process before? What do you remember about it?
• Think about the 5 key principles of continuous delivery (build in quality, small batches, automate repetitive tasks, pursue improvement, everyone is responsible). How do you see these principles in action?
• What do you think it takes to implement configuration management, continuous improvement, and continuous testing?
• Will implementing continuous delivery improve culture? Have you dealt with pushing back implementing modern software delivery practices?
• Does continuous delivery make the work "feel better"?
• What benefits do you see from capabilities such as: version control, automated testing, managing data, centralized development, and information security automation/tests?

[tomcudd]

My favorite part about these chapters is the idea that you can "fake it til you make it" when it comes to technical practices. It's like the idea of doing the practice actually changes the way you think about the work. I've worked on projects that cover the whole range of generative to toxic cultures. It is interesting to see how communications dry up in a difficult environment. More open and trusting teams seem to be able to perform better.

[tomcudd]

Jan 29-Feb 4: Chapters 5-7 (Architecture, Integrating InfoSec into the Delivery LifeCycle, Management Practices for Software)

• Why do you think organizations would perform better if they are building custom software internally versus modifying software initially created by someone else (outsourcing, acquisitions, development partner, etc.)?
• What does a loosely coupled architecture mean to you or your organization? How does this affect how testable and readily deployable your codebase is?
• How does the makeup and layout of a team affect the architecture of the software being built?
• Do you have the option to choose what tools you use to complete your work? How does this choice compete with the standardization many organizations enforce?
• How do you see opportunities to build Information Security practices into the development process?
• How does limiting the amount of work in progress lead to increased throughput?
• Do you know what work is "in flight" and highest priority at the moment?
• Are you able to take application performance data and monitoring systems data to make decisions about what work you should be focusing on?
• How should code moving towards production be approved as ready?

[CuriousCurmudgeon]

Why do you think organizations would perform better if they are building custom software internally versus modifying software initially created by someone else (outsourcing, acquisitions, development partner, etc.)?

I was the one building custom software as a consultant for many years. The big issue is that you have built-in brain drain. It doesn't matter how good your documentation is, you're leaving with a huge amount of implicit knowledge about how the software works. All the quirks and oddities that you "just know" and never think about. Even in the best case scenario where they have devs you are handing the project off to, there is still lost knowledge. And I worked with companies who didn't have a real plan for hand off at all.

Do you have the option to choose what tools you use to complete your work? How does this choice compete with the standardization many organizations enforce?

I'm currently a solo dev. That means I have complete control, but within reason (i.e. don't throw it all away just because I don't like it). I am already thinking of standardization in the future though. I don't know what the break point is where standardization is counter-productive. For small orgs, standardization is valuable, but a certain point the diversity of the teams skillset and the problems being solved means standardization has diminishing returns.

How does limiting the amount of work in progress lead to increased throughput?

My experience with high WIP has been that it's caused by the work being poorly defined or involving too many pieces outside of the team's control. With poorly defined work, you end up thrashing from task to task while trying to get clarification on whatever the blockers is. It's work that probably shouldn't have been started at all yet or broken down in a way so that a subset of the work could be completed while getting clarification on the remaining work.

Limiting WIP actually forces you deal with these issues instead of just shrugging and grabbing another piece of work.

[tomcudd]

Feb 5-Feb 11: Chapters 8-9 (Product Development, Making Work Sustainable)

• Do you see Agile sold and implemented in your organizations as process changes or culture changes?
• Which Lean methods (small batches, visible work flow, seek/incorporate feedback, create and change without pre approvals) do you find in your process? How do they affect your work and the outcomes of your work?
• Organization performance is closely tied to allowing developers to come up with ideas and create something based on the data they have. What do you think this process looks like? What is an example of the type of idea/work you can do when allowed to work like this?
• Have you had deployment processes that are simple, low stress events, or complex, anxiety-inducing times? Do you believe where work is on this spectrum has an impact on your ability to be productive and efficient? Can this impact job satisfaction?
• Burnout can clearly affect someone's individual health and work, what do you think the impacts are to organizations who don't protect the well being of the employees?
• While overwork and lack of individual control have an obvious impact on burnout, how do you see organizational value conflicts affecting your work?
• What can an organization do to protect people's well being? What can you do to improve culture, balance, and impact as part of a team?

[tomcudd]

Feb 12-Feb 18: Chapters 10-11 (Employee Satisfaction, Leaders and Managers)

• Employee satisfaction and loyalty clearly have an impact on an organizations performance, so how do you see that affecting individuals contributions and team efforts?
• Can you see how characteristics like continuous delivery and DevOps can improve the quality of an employee's work and efforts?
• If you didn't have a clear understanding of your organization's objectives, how would that impact your day to day work?
• Inclusive teams with diversity in tech are also have better outcomes and and are part of high performing organizations. I didn't have a question for this - I just wanted to point out how critical it is to be aware of this information.
• What kind of leader inspires you to do the best kind of work in your field? Do you see the transformational leadership qualities in the managers and leaders you respect or admire?
• How can managers support and encourage positive DevOps capabilities in their own team and across many teams?
• What ways do you see managers building trust in an organization?
• How can managers promote and encourage collaboration across teams?

[tomcudd]

Feb 19-Feb 25: Chapters 12-13 (Science The Book, Intro to Psychometrics)

• What kind of primary research information do you need to draw conclusions about your work?
• Have you considered trying to gather internal information from your organization using Likert-Type scales to quantify your data?
• If you are in a smaller organization, what qualitative information can you gather to influence the work?
• What kind of analysis could you run with information from the teams and organizations you are a part of?
• How can you prevent "spurious correlations" from popping up in your research?
• Do you need to devote time and effort to gathering information from your organization versus using contents of books and research already completed to meet your goals?
• If you decide to collect your own details and information, what can you do to remove bias and leading from questions?
• Can you use existing platforms like Net Promoter Score to gather what you need?
• What constructs do you need to create to gather details about abstract concepts like organizational culture?

[tomcudd]

Feb 16-Mar 4: Chapters 14-15 (Why Use a Survey, The Data)

• What kind of results do surveys provide compared to system data?
• What is missing when only analyzing system data results?
• Do you inherently trust system data more than survey data?
• What does survey data measure that can't be gleaned from system data?
• Why was it important to target potential survey takers who were already familiar with DevOps?
• Why is it difficult to target survey takers to professionals using DevOps methodologies already?

[tomcudd]

Mar 5-Mar 11: Chapter 16, Conclusion, Wrap (High Performance Leadership and Management, Conclusion)

• Do you think the focus on digital transformation misses ways to update management and leadership in organizations?
• How can management connect with digital efforts as they rapidly change?
• Does the recent remote models allow for the same information sharing that happened when you sat leadership teams and technical teams near each other?
• Does the "Spotify model" of organizing teams meet the needs of changing technology structures?
• How can managers and leads better serve the teams they are supervising in a DevOps landscape?
• How does healthy experimentation and learning co-operate to advance a team's goals?