Chapter 8. What To Do Next
We’ve covered a lot of ground up to this point. I’ve shared with you fifty-nine lessons about software engineering and project management that I’ve learned since I began programming five decades ago. These lessons fell into six domains: requirements, design, project management, culture and teamwork, quality, and process improvement. There are certainly other vital aspects of software development that I haven’t addressed here, including coding, testing, and configuration management. Now I have just one question for you:
What are you going to do differently after reading this book?
If you worked through the First Steps and Next Steps in each chapter, you should have a list of your project team’s or organization’s issues in those six domains. Perhaps you analyzed each problem to understand its root causes and impacts. You might have identified the benefits that addressing those issues could provide. I hope you’ve written down many ideas of practices that could address those issues and add value for your projects and their customers.
Whenever someone undertakes a learning experience but doesn’t do anything differently, they get no value from their learning investment. I want you to get a high return from the time you invested in reading this book. That means you need to select your next actions. As we work through some thoughts about how to do that, keep one final lesson in mind.
Lesson #60. You can’t change everything at once.
No matter how many points of pain, improvement ideas, or desirable destinations you identify, people and organizations can absorb change only at a limited rate. I knew a highly motivated, twenty-person project team that tackled seven major improvement activities simultaneously. Priorities weren’t clear; resources were spread thin. Despite their enthusiasm, this team accomplished little on their change journey. Also, changing too many things simultaneously—a multivariable experiment—makes it hard to tell what alteration produced the observed outcome.
All individuals have the power to improve their results at their own pace. However, a management-imposed, large-scale change initiative can overwhelm those affected. Trying to change too much at once can make it hard for people to get their project work done as they try to understand and conform to the new direction. It’s easier to manage the rate of change with a bottom-up change initiative. Although grassroots efforts can work well at the team level, they hit a ceiling beyond which it’s hard to influence related groups without management assistance. As Mary Lynn Manns and Linda Rising (2005) explained in their book Fearless Change:
The emphasis in bottom-up change is on participation and on keeping people informed about what is going on, so uncertainty and resistance are minimized. Based on our experience, we believe that change is best introduced bottom-up with support at appropriate points from management—both local and at a higher level.
As with personal growth, software process improvement is a journey, not a destination. It’s a cycle, not a straight line. There are many ways to depict a change cycle. Perhaps the best known is quality improvement pioneer Dr. William Deming’s Plan-Do-Check-Act, also known as the Shewhart Cycle (Praxis, 2019; American Society for Quality, 2021d). Figure 8.1 shows a similar improvement cycle that I prefer over Deming’s.
Figure 8.1 A typical process improvement cycle has four steps: assess, plan, do, and verify.
Step 1: Assess. Take stock of where you are today—the results your projects currently achieve and how well things go. Identify the biggest problem areas and greatest improvement opportunities. Completing the First Steps in the preceding six chapters constitutes an informal assessment activity.
Step 2: Plan. Decide where you’d like to be in the future—your objectives for both business and technical improvements. Map out a plan to get from here to there. The Next Steps in this book suggest some starting points for charting your course to a more desirable future.
Step 3: Do. Now comes the difficult part: doing something different. You’ll need to learn about practices and methods that could yield better results, try them out in pilot activities with a receptive team, and adjust to make them work in your environment. Don’t be afraid to keep what works and discard that which does not.
Step 4: Verify. Allow the new techniques to take hold, and then check to see whether they’re providing the results you hoped for. It takes time to change directions; have patience. The learning curve is unavoidable. Better business outcomes are a long-term, but lagging, indicator of how well your project approaches work. Try to define some interim metrics that could indicate whether whatever you’re trying seems to be paying off.
Remember, change is a cycle. There will always be something else to work on. Return to the assessment step at the end of each cycle to examine your new situation and then select the next round of change activities.
Prioritizing Changes
Focus is a keyword in any change initiative. You might think of more changes that you’d like to make than you have time for. You need to prioritize to focus your energy for the maximum benefit. Then you must carve out the time to actually implement each change.
There’s never a convenient time to work on process or quality improvement activities. Unless you deliberately set time aside, there will never be idle periods when nothing else is going on. But if you don’t take the first steps to make changes—as individuals and as organizations—you won’t make progress. Everyone should spend some fraction of their time learning how to boost their performance. Choose the most pressing issues from your list of possible improvement areas and begin working on them tomorrow. I’m serious: tomorrow!
Revisit your notes from the First Steps and Next Steps in each chapter of this book. Where would it be most rewarding to see some improvement, to reduce unpleasant outcomes? What changes could deliver the greatest business value for your organization? Which changes seem to be the most achievable with a reasonable investment of time and money?
Once you’ve identified the top problem areas, you’ll need to select possible solutions that have a high chance of paying off. The dozens of practices described in this book offer some ideas. I’ve provided many references to other sources where you can learn more about those practices that appear promising. As you prioritize your actions based on their importance, urgency, and cost, begin by addressing changes you can make quickly or those that will have the biggest impact soon. Look for the low-hanging fruit, the quick successes—and celebrate those successes. It’s motivating when the team sees that they’re making progress and beginning to reap the benefits. It proves that change is possible in their world.
Reality Check
As you consider actions that yield better results, keep in mind a philosophy I adopted as a consultant. Before I give a client advice, I run a little mental check to confirm that the action I’m proposing satisfies two criteria:
1. It must have a high probability of solving the client’s problem.
2. It must be practical and achievable in the client’s environment.
This reality check ensures that I’m giving sensible advice, not suggesting something that’s inappropriate for the client’s projects or culture. I suggest you apply that same filter to any changes you recommend for yourself or your organization.
Think about which changes the organization might be ready to accept and which ones should await some cultural evolution before tackling them. Chapter 5 pointed out some characteristics of both healthy and less-healthy software engineering cultures. Because cultural change takes longer than implementing new technical practices, leaders should start steering the culture in the preferred direction early on. That will lay the foundation for teams to absorb larger transitions later.
I suggest you take a systematic approach, even at the personal level. When I began a new development project, I would always identify two areas of software engineering or project management in which I wanted to improve. It could be unit testing, estimation, algorithm design, peer reviews, build management, or anything else. As I worked on each software project, I would allocate part of my time to reading about my chosen topics. I might take a training course or attend a conference. I would hunt for opportunities to apply what I’d learned, recognizing that it would take some effort to determine how to make it work effectively. I do the same thing now with my hobby of recording songs. With each song, I try to learn more about playing something on the guitar, recording and production techniques, and using the vast array of features in my recording software. That way, each song I produce is better than the previous one.
Recall from Lesson #55, “You don’t have time to make each mistake that every practitioner before you has already made,” that the learning curve isn’t a smooth, continuous transition. You’ll experience ups and downs as you wrestle with the topic. But you’ll get there.
Action Planning
Change doesn’t happen by itself. Prioritizing issues and selecting improvement actions aren’t enough. If you’re serious about change, you must treat it as a project with goals, plans, resources, status tracking, and accountability. Depending on the scope of the change you’re exploring, you can create action plans for yourself, the project team, or the organization as a whole. Anyone who’s responsible for leading an organization-wide improvement initiative would find the book Making Process Improvement Work helpful (Potter and Sakry, 2002). Simpler—yet still structured—approaches work well at the individual and team levels.
Figure 8.2 shows a simple action-planning template. Look into the future just one week, about a month, and about six months. List the new technical or management practices you want to try in each of those time frames. Describe the situation you think you could apply them to and the benefits you’re looking for. Perhaps you’ll need more resources to help you learn how to apply these new practices, such as training, tools, books, or consulting assistance. Some practices apply only to your personal work, but others affect multiple communities, so consider whose cooperation you might need for each change. It’s also helpful to consider barriers that might stand in the way of successfully implementing something new. Then try to identify allies who could help break down those barriers.
Figure 8.2 A simple action-planning template helps you plan improvement actions for the near-term, mid-term, and longer-term time frames.
Doing some planning greatly increases the chance that you can implement changes successfully. There’s a trap to watch out for, though. Look back at the change cycle in Figure 8.1: Assess, Plan, Do, Verify. I’ve seen too many organizations do a thorough job of assessing their current reality, targeting an improved future state, and planning how to get there, only to stall out at the Do step. That’s the hardest part, forcing yourself away from project work to implement items from your action plan and carry them through to completion. Regardless of one’s good intentions, improvement action plans that don’t turn into actions aren’t useful. So, beware of the temptation to take the easy path of continuing to work the way you and your team members always have. That’s not a route to better business results.
Your Own Lessons
Every seasoned software professional has accumulated a set of lessons from their experience. This book contains many of my lessons; I’m sure you have your own beyond these. Consider having your team put their heads together and pool their key insights along the lines of this book’s lessons. Think about how you could share those lessons across your organization to accelerate everyone’s learning process. Your next step would be to choose practices based on those collected lessons that could give your team better results.
Building a learning, improving organization begins with individuals who have internalized the value of gleaning pearls of wisdom from their experience and sharing them with others. I hope you’ll take this opportunity to put into action selected bits of what you’ve read here. Invite your teammates to join you. It might be a fun journey.