Chapter 2. Defining the Software Development Process
Defining the software development process always sounds straightforward until you actually start trying to do the work. Many tasks are involved with any software or systems lifecycle, and a well-defined process must provide guidance on exactly what needs to get done and who is responsible for completing each task. Years ago we focused entirely on the software development lifecycle (SDLC), and that was not a bad place to start. But today’s systems have many more moving parts and take much more effort to manage than just sitting a business analyst down with the Cobol developer who needs to write the code. Before we dive into agile application lifecycle management in Chapter 3, it would be helpful to review how we used to design software development processes before all of the buzz around agile, scrum, and DevOps. Some of the process engineering techniques that we employed were actually quite good, and as the old adage says, “To know where you are going, you must first know where you have been.” This chapter helps you understand the basic skills of how to define the software development process. This will make it much easier for you to define processes that meet your requirements while applying all of the principles in Lean and agile.
2.1 Goals of Defining the Software Development Process
The goal of defining a software development process is to clarify exactly what needs to get done in developing a new software system. Most software development processes are described in terms of phases, and we provide some examples of how to approach defining your software development process using this technique. In the past, traditional software development processes usually focused on requirements, design, programming, and testing. Back then we described deployment and operations in a runbook that specified all of the procedures required to operate and support the system. IT professionals by and large were quite good at producing documentation and tailoring processes to the needs of the organization. Your goal in defining a software development process is to provide just enough guidance to avoid costly mistakes. Another important goal is to ensure that there is clarity around the tasks that each stakeholder is responsible for completing throughout the entire software or systems lifecycle.
2.2 Why Is Defining the Software Development Process Important?
Defining the software development process is important because it helps clarify what each stakeholder needs to accomplish throughout the software or systems delivery lifecycle. The well-defined software development process helps avoid costly mistakes by clarifying the tasks that need to be completed and enhances communication between each stakeholder. In a time when so many technology professionals are specialists and many organizations suffer from silos that are insulated from each other, a well-defined software development process can be very helpful in providing clarity as to what is going on during the software development effort. Without a well-defined software development process, your team risks having a lack of clarity as to what they are expected to do on a daily basis. They also won’t have a clear idea of what is coming down the road that may affect them.
We have heard IT operations directors describe just how difficult it is for them to anticipate the requests that come in at the very last minute from development managers trying to implement new features required by their customers. If the IT operations director has some visibility into the software development process, then there is more opportunity to clarify the upcoming requirements without the usual fire drill that affects so many IT organizations. We explain how to create a well-defined software development process that helps your team respond to change and avoid costly mistakes without having to be bogged down in unnecessary bureaucracy. Remember always that too much process is just as bad as not having enough. But a well-defined process also helps us avoid mistakes caused by missing steps or failing to communicate. The software development process helps us right-size the amount of ceremony that we have in our approach to getting the work done.
2.3 Where Do I Start?
Getting started with creating an effective software development process begins with defining the high-level tasks that need to be accomplished to get the job done. This typically begins with understanding the business goals of what you are trying to accomplish and the high-level requirements necessary to deliver the business value. You then identify the stakeholders who will need to be involved with delivering your system. From there, our approach is to interview each stakeholder and ascertain what tasks he or she needs to accomplish. The software development process identifies the work each stakeholder must complete and should always start with collaboratively defining exactly what needs to get done. You won’t get all of the tasks defined the first time, and that’s fine. In the beginning of a project, there are usually some initial activities to define goals and also evaluate the technologies that are to be part of the proposed solution. Technology professionals are usually in an exploratory mode at this point, and there may be little need for a formal software development lifecycle. Pretty soon the project goals and the solution strategy will begin to take shape and then you need to start introducing some structure into the software or systems development effort. My experience is that it is usually best to start with a very Lean process that grows with the project itself. Start by creating a draft task list with roles and responsibilities and then review and update your process as needed.
2.4 Explaining the Software Development Lifecycle
Years ago it was popular to create a software development lifecycle that defined all of the tasks involved with developing software, including requirements gathering, design, development, and testing the application code. This approach to an SDLC was often associated with the waterfall lifecycle and had a limited scope and focus. I remember working on a large team to create my first SDLC and all of the revelations that I had when I learned about the work that all of the other technology professionals were doing as part of this effort. I was a software development programmer back then, and I got the opportunity to work with a group of industrial psychologists interviewing a large group of technology professionals in order to document their jobs and look for opportunities to eliminate duplicate roles and positions. This was back in the era of downsizing, and I certainly had some mixed feelings about participating in an effort that we all knew up-front would result in a lot of people losing their jobs. In the end, most of the people who wanted to stay with the company were able to do so, and lots of other people took lucrative buyout packages and either retired or went on to their next opportunity. This company handled downsizing well and has stayed profitable to this day.
The software development lifecycle was certainly flawed back then. Most organizations wrote SDLCs that did little more than sit on a shelf and collect dust. The basic problem with the SDLC was that there was no way to actually execute the delivery other than a manager following up on each and every task on a day-to-day basis. This wasn’t very efficient, and I recall thinking that as soon as I became a manager, I would find a way to handle managing an SDLC better. It wasn’t long before I got the chance.
The software development lifecycle does indeed provide clarity on what needs to get done by the technical team on a day-to-day basis. But trying to manage the execution of an SDLC without the right tools is simply impossible.
We will discuss automating the execution of the SDLC later in this chapter. It is also helpful to use industry standards and frameworks when defining the software development lifecycle. One of the most popular standards is the IEEE 12207, which describes software lifecycle processes (see Figure 2-1).
There are times when the standard must be followed very closely in order to ensure compliance with either regulatory requirements or contractual agreements. There are also other times when you can use the standards as simply guidance to ensure that you don’t skip an important step in your process. Whenever we read a standard, we always find some task or function that we realize we should have thought of, and the standard helps me avoid missing a key control. Even if you are not required to adhere closely to the comprehensive guidance provided by ISO 12207, you will find that the guidance contained therein will help you realize what you forgot to include in your software development process.
One of the issues that often comes up is how to handle a software development lifecycle when no software is being written. This is precisely where the SDLC focuses more on a system development lifecycle instead of a software development lifecycle.
2.5 Systems versus Software Development Lifecycle
Purchasing software that has been written by a vendor, or even reusing code written by another group within your organization, is a little different from developing the software yourself. We have seen many organizations stumble when they purchase commercial-off-the-shelf (COTS) software applications. Many organizations fail to realize that anything more complex than a word processing package requires a robust software or system lifecycle. Just because you buy the code doesn’t mean that you are not responsible for ensuring its successful procurement and implementation. The systems development lifecycle should include requirements, evaluation, configuration, testing, implementation, and support. In addition, an essential aspect of vendor management is involved. You need to ensure that you have evaluated the vendor organization to confirm that they have the ability to deliver the functionality as promised. This is often called a vendor risk analysis. When procuring a system from a vendor, testing is very important, and often the configuration effort requires skilled software developers just as if you had actually written the code in-house. One of the biggest mistakes you can make is to trust the vendor to install, configure, and test the application, as their goal is to sell you the product, and ultimately you have the responsibility to ensure that the application delivers the functionality as promised and actually meets the needs of your business. ISO 15288 describes the common lifecycle processes that you should consider in your systems development lifecycle (see Figure 2-2).
Understanding and defining requirements is an essential aspect of any software or system lifecycle and often one of the most difficult aspects to manage.
2.6 Defining Requirements
Whether you are developing a software system or customizing a COTS product, understanding and defining requirements is essential. Much has been made of the fact that we often do not understand our requirements, and that is certainly true. Unfortunately, many technology professionals have taken the approach of not even trying to develop good requirements documents, and that is often a very serious mistake. Just because requirements are not well understood or may change does not change the fact that we should do our best to define the requirements that we do understand in a pragmatic and Lean way.
2.6.1 Managing Complexity and Change
Managing requirements as part of a software development lifecycle should focus on managing the complexity of what you are trying to design and implement. Well-defined requirements helps all of the stakeholders understand what we are trying to build (or procure and customize) and then respond effectively to changes as they occur. Defining requirements means that we also have version control to help handle changes to the requirements that we all know will be required as we learn more about the system we are trying to develop. Managing changing requirements also requires that the appropriate stakeholders be kept informed and be allowed to offer input when necessary. If you suddenly increase the rate of transactions, your database engineers or systems administrators may need to make changes to the infrastructure to handle the changing requirements. Although it has become popular to say that we cannot define all our requirements up front, mistakes in requirements definition can result in serious defects, including security risks as well as increased cost and delays in project delivery. Requirements definition should include traceability to test cases to ensure that the requirements have been met. I have long been an advocate of using test cases to augment the information in the requirements document. Clearly defined test cases can provide much of the same information as a requirements document and tends to be easier to keep updated and current.
Maintaining the history of changing requirements and documenting the approvals authorizing changes in requirements is also essential and can prevent many problems that could potentially impact the project downstream. One of the most important issues is whether or not the requirements are valid and verifiable.
2.6.2 Validity of Requirements
The requirements defined as part of any software or systems lifecycle need to be relevant, valid, and verifiable. This is precisely where many IT professionals exclaim that “we don’t really understand our requirements” and that is often indeed true. But the issue is not whether you fully understand all of the requirements up front (and very often you cannot). The real problem is being honest and clear about what is indeed understood and what still needs to be determined. We have seen many situations where everyone in the room was pretending to understand what was required for the system to be developed and implemented. Based upon the high-level discussion and the lack of specific details, we would sometimes come to the conclusion that we were all pretending that we understood the requirements. Being honest about what we know and what we do not know is very important, and sometimes technology workers find themselves in the uncomfortable position of thinking that they cannot admit their ignorance. W. Edwards Deming said it best when he pointed out that we need to “drive out fear,” and defining valid and verifiable requirements is one of the most important areas where everyone needs to be comfortable with what they do not fully understand. This is where we have often found that it can help to talk about testing requirements.
2.6.3 Testing Requirements
Every requirement should have a matching test case to ensure that the requirement is verifiable and that it has been met. It is sometimes difficult, and not entirely necessary, to have a one-to-one relationship between requirements and test cases, but every requirement should have at least one test case that verifies the requirement has been implemented as expected and as desired. This corresponds to verification and validation, which answers the questions: Does the feature meet the specification? and Is the specification correct? Whenever it is difficult to understand requirements, it is often a good idea to figure out how to test them by writing test cases with the relevant stakeholders. This is usually how we handle situations where we suspect that everyone in the room is pretending that they understand the requirements.
Testing requirements is important. But there are many kinds of requirements, and creating a topology of requirements is very important. Let’s take a brief look at some of the different types of requirements and how they fit into the software or systems lifecycle. The first type of requirement describes how the system should function.
2.6.4 Functional Requirements
Functional requirements describe the desired behavior of a system typically in the form of use cases that meet specific business needs. Use cases explain how the system should work and function on a day-to-day basis. Most requirements documents describe how the system should work including information that is to be input, behavior such as calculations, reporting, and other key features. Documenting functional requirements can be very challenging especially in terms of maintaining a consistent level of detail. While functional requirements explain how the system is used, non-functional requirements describe how the system should behave in a number of important ways.
2.6.5 Nonfunctional Requirements
Nonfunctional requirements may include performance and response time, capacity reliability, and security. Designing good functional requirements obviously affects many other stakeholders and is a key consideration in defining the software or systems lifecycle. There is a broad array of nonfunctional requirements, and almost anything outside of user functionality can be described in terms of nonfunctional requirements. In many organizations, it has become popular to describe use cases in terms of epics and stories.
2.6.6 Epics and Stories
In agile software development there is often less of a focus on developing comprehensive requirements documents, and instead user stories explain the desired functionality. Groups of user stories can be organized in terms of epics, which is a reference to the long poems that are commonly found in Greek mythology. Finding the right level of detail for documenting requirements can be experienced as a balancing act. If you are designing a complex trading system, then defining your requirements may need to be quite detailed and precise. Other times the agile approach of defining requirements in user stories can be quite sufficient. Either way, change is inevitable, and any requirements management process must contain a well-defined process for managing the change that is certain to be required.
2.6.7 Planning for Changing Requirements
Much has been written about the fact that requirements are almost certain to change over time. Change is not bad, but it does need to be managed. The fact that requirements cannot be completely understood up-front or that they will inevitably change over time is not a valid reason to skip documenting them. The decision to have an exhaustive effort to document and manage requirements should be decided based upon the risk of getting a requirement wrong or missing a key requirement all together. Designing the software for a life support or missile defense system requires well-defined requirements. You need to right-size your requirements definition effort based upon the needs of the business. You also need to consider the lifecycle of a requirement.
2.6.8 Workflow for Defining Requirements
Requirements management should be automated using an automated workflow tool. There are many good requirements tools on the market, and once again, it is a matter of finding the right fit for your project and your organization. Some requirements need to be reviewed by multiple stakeholders and perhaps even funded by a business unit willing to pay for the work required to implement a particular feature. Your software development lifecycle needs to strike the right balance in terms of the amount of process required for your requirements tracking lifecycle. Requirements tracking is very close to test case management, and many organizations prefer to focus on driving their development effort to a robust test-driven process.
2.7 Test-Driven Development
Test-driven development (TDD) is a methodology that has become popular in agile development, but actually could be used in any software development lifecycle. The basic premise is to define the test and automate the test case before even writing the application code. By definition, this means that the test case will initially fail because the code itself has not been written. Focusing on writing automated test scripts is a very effective way to develop self-validating quality code. In my work as a build and release engineer, I always focus on writing scripts that automate my own application build, package, and deployment. At least half of the code that I write tests the automation itself, because if any step fails, I want to know immediately so that I can quickly and easily address this issue. In manufacturing this is known as “stopping the line” and refers to a worker stopping the manufacturing process immediately when something is wrong, simplifying the effort to fix and resolve problems. Test-driven development should be a key consideration in creating any software development lifecycle. Ensuring that systems are testable is very important, as is also ensuring that they are designed properly.
2.8 Designing Systems
Systems design is a key function within the software and systems development lifecycle. Just like defining requirements, designing a system can range from a complex and exhaustive effort to one that is brief and agile. Defining the design for a system depends largely upon the architecture chosen and the related standards. Your software and systems lifecycle needs to ensure that you have sufficient coverage for systems design to mitigate risk and ensure that you can meet your users’ requirements for performance, reliability, and security. The choices that you make in systems design will also directly affect your organization’s ability to implement new features and scale to meet growing user demand. The design itself, just as every other feature, must be verifiable, which is where testing along with verification and validation become essential aspects of your software and systems lifecycle.
2.9 Software Development
Software and systems development is evolving to be largely influenced by the technology stack itself. Java J2EE developers work with integrated development environments (IDEs) and tools that largely facilitate their own productivity. This technology stack may be quite different than the approach used by C#/.NET developers or other technologies that come with a well-defined ecosystem such as Python or Ruby. Skilled software development professionals may try to achieve proficiency in multiple technologies, but there is so much to learn that they often specialize in one specific technical competency or another. Unfortunately, this can also lead to silos and hinder effective communication. Database analysts, systems administrators, and middleware administrators all have their specialized terminology and technical approaches, which can make development and support difficult to effectively manage. The DevOps approach of sharing technical knowledge, effective communication, and collaboration is essential for harnessing the knowledge within each of these technical areas.
2.10 Testing
The test phase of any software or systems lifecycle is normally viewed as a tollgate that must be passed before the application can be approved for promotion into production. The fact is that testing should occur throughout the entire software or systems lifecycle. But that does not remove the need for an official testing phase, usually performed by QA or another testing organization. The testing process has many phases, and your organization may handle testing in a very formal way, depending upon the risk of a defect being found in the application, along with compliance and related audit requirements. One of the areas where I have seen testing handled in a very formal way is developing software for a nuclear power plant facility.
We discuss unit testing as part of build engineering in Chapter 6 and as part of continuous integration in Chapter 8. Systems integration testing is also an essential aspect of any software development lifecycle, along with QA and user acceptance testing. As with any part of the software development process, the amount of formality required in testing depends largely upon your requirements and the risk and impact of a defect found in production.
2.10.1 Testing the Application
Application testing is a key step in any software development process. Testing should be continuous through the entire development effort. Unit testing is only the beginning and often has very limited coverage. Functional testing is also essential, although limited by the application interface. In Chapter 20, “QA and Testing in the ALM,” we cover testing in greater detail and explain how QA and testing should integrate with the application lifecycle. The entire SDLC should be integrated with the application testing process. This includes tracking requirements to test cases and automating as much of the application testing as possible. Although application testing is essential, testing the software development process is also an essential, although sometimes overlooked, aspect of establishing a robust ALM.
2.10.2 Testing the Process Itself
The software development process usually consists of many steps and considerable complexity. Although most folks are well aware that the application needs to be tested, care should also be taken to test the software development process itself. This would include testing the requirements, the architecture, and the infrastructure. It is also essential to test the application deployment pipeline, and this is a fundamental aspect of implementing DevOps to support the software development process. Testing is an important part of any software development process. Building quality in should obviously start at the beginning of the lifecycle, and continuous integration is one of the best ways to make that happen.
2.11 Continuous Integration
Continuous integration (CI) is discussed in more detail in Chapter 8. For the software development process, CI provides an important point at which code may be integrated during the development phase of the lifecycle. By integrating early and often, CI tames cognitive complexity by making it much easier to detect potential problems when integrating code, which often comes from two or more different developers. If you do not integrate early and often, it becomes very difficult to understand code issues and, more importantly, how to fix them. Continuous integration relies heavily upon compilers to identify code conflicts by assuming that the code will not compile if it not compatible. The fact is that code also needs to be reviewed by the engineers who are best equipped to identify any defects or other opportunities for improvement. This is discussed further in Chapter 8.
Much of the value of continuous integration is also related to continuous deployment.
2.12 Continuous Delivery and Deployment
Continuous delivery and deployment are closely related to continuous integration. We will distinguish between continuous delivery and deployment in Chapter 9, but for now we refer to continuous deployment as a methodology that allows us to deploy to production as often as desired. By deploying more often, you implicitly reduce cognitive complexity in several important ways. The first reason is that smaller and simpler deployments are inherently less risky because there is much less that can go wrong. If something does go wrong, then the problem will be easier to diagnose and then fix. If necessary, it is much easier to back out the code. Deploying more often also allows you to get better at doing the deployments and automate each and every step.
Continuous deployment is essential for ensuring that the customer receives all of the desired and required features and fixes successfully. We will discuss continuous deployment (and continuous delivery) in Chapter 9. It is also essential to define the phases of the software and systems lifecycle.
2.13 Defining Phases of the Lifecycle
Most technology professionals find it useful to define a software or systems lifecycle in terms of distinct phases. What is important is that you consider what phases make sense for you and your organization. I have seen lifecycles that were defined with many phases and others that were very brief. The first thing to consider is whether you can take an existing lifecycle that is used by others or if you have special needs and would be best served by creating your own custom software or systems development lifecycle.
Most SDLCs start with defining requirements and establishing a design architecture. Software is then developed and tested. Some lifecycles can be just that simple, and others may require far more rigor. Your goal is to find the right balance in defining a lifecycle that will actually be used to guide everyone in understanding their own commitments in the software or systems delivery lifecycle. Pragmatism is essential, as the best lifecycles are useable and can be tailored to guide everyone to understand their own tasks and deliverables.
Process maturity is an important consideration when defining an SDLC. Typically in the beginning of a project, your process can be loosely defined. As the project progresses, process maturity becomes essential. Get close to a deadline, and your process needs to be very well defined, repeatable, and completely traceable. Process maturity is among the most important considerations when defining a software or systems lifecycle. Don’t forget that the best processes are iterative in nature.
Whether your process is agile or waterfall or some other methodology, taking an iterative approach will greatly enhance your chances of success. Process maturity is essential, although sometimes not a prime focus in the agile world. Similarly documentation is also occasionally overlooked. You need to take a pragmatic approach to deciding just how much documentation is required.
2.14 Documentation Required
It has become popular to minimize the importance of comprehensive written documentation. The agile manifesto notes that working software is more important than comprehensive documentation. But sometimes documentation is absolutely required, including when there are regulatory requirements, as described further in Chapter 16. Our view is that documentation should be as complete and comprehensive as possible. I also always encourage draft documents to be circulated for comment as early as possible.
Some technology professionals find it very difficult to write documentation. The best approach that I have found is to get rough drafts completed as quickly as possible and engage a cross-functional team to review, edit, and improve the documentation. This approach exemplifies the principles and practices found in DevOps.
2.15 DevOps
DevOps is a set of principles and practices that help improve communication and collaboration that we discuss in more detail in Chapter 12. DevOps puts a strong focus on interactions between the development and operations teams, along with QA, testing, and information security; but really, DevOps has a much wider focus. The fact is that all stakeholders represented in the software development process need to have excellent communication and collaboration, and silos within the organization are the root cause of many problems and issues. DevOps practitioners need to ensure that all of the stakeholders within the organization are able to effectively communicate and collaborate together. This book focuses on DevOps throughout the entire ALM. DevOps best practices deliver the capability of ensuring that changes to systems can be implemented as often as desired while also ensuring that systems are reliable and secure. Much of the day-to-day work of DevOps is on creating fully automated deployment processes and tools. But DevOps has a much wider focus, and the DevOps approach can help the entire organization make better decisions.
DevOps has a fundamental goal of promoting excellent communication and collaboration with all stakeholders.
2.16 Communicating with All Stakeholders
Whenever I assess an organization to baseline their existing practices, several common themes always seem to be apparent. The first is that too often corporate divisions begin to act as if they are separate companies. This creates a dysfunctional “siloed” mentality that can be very destructive. The organizational structures may be very much needed, but the teams must also be able to communicate and collaborate effectively.
Poor communication often manifests itself in teams and team members lacking a clear understanding of what they need to accomplish and, more importantly, how their work affects the other team members. Dysfunctional behavior can include groups working against each other, which is usually a consequence of a lack of trust between the most senior managers who may be competing with each other through corporate politics.
The biggest problem that we often see is a sense of fear where team members are afraid to speak the truth and engage in open and completely honest communication. Deming said it best when he coined the phrase, “Drive out fear.”
One of the important functions that needs to have very effective communication is the forward-facing group that handles support of your production systems.
2.17 Production Support
Production support is an essential function that is often overlooked. Responsible for maintaining continuous service, the production support engineer is often also responsible for updating the software and systems. The challenge of supporting production systems is that there is often only a brief transfer of knowledge as the system comes online and is supported by the production support group. The DevOps function plays a key role in engaging developers early in the process by training and collaborating with their production support counterparts.
Production support engineers should have strong technical backgrounds, including experience as software developers. One model for this role is to rotate developers into production support roles for six to nine months and then return them to development work.
Skilled production support engineers should play an active role in creating bugfixes in addition to supporting and maintaining production systems.
2.18 Maintenance and Bugfixes
Maintaining code and creating bugfixes require a creative balance between moving ahead and getting essential quick fixes deployed. Focusing too much on short-term fixes tends to create too much technical debt, which refers to making short-term choices that will need to be “paid back” in the near future.
The agile ALM can help put the right perspective on fixing short-term bugs that are affecting our customers. It is also essential to find the right balance between having too much ceremony and keeping your processes as Lean as possible. As any hands-on practitioner will tell you, the beginning of a software or systems development effort usually begins with very little process and few IT controls.
2.19 Lifecycle in the Beginning
The beginning of any project is a time when roles and responsibilities are forming. I believe in keeping the development process very loose in the beginning. It is almost impossible to figure out how structure is needed in your development lifecycle until you have a very well-defined idea of what you are building and who is involved with the software and systems delivery effort.
My own approach is to use agile principles when defining the agile ALM.
As the project progresses, the agile ALM must mature, which means that additional IT controls should be established and the lifecycle itself must evolve.
2.20 Maintenance of the Lifecycle
The lifecycle itself requires a considerable amount of care and feeding. You need to ensure that you have a change control process in place for evolving the lifecycle itself. Too often there is a lack of structure to support updating and evolving the software and systems lifecycle.
We discuss creating a mature agile ALM in Chapter 4, “Agile Process Maturity,” and defining agile processes in the non-agile environment in Chapter 14.
Right-sizing your processes is fundamental, and another critical success factor is establishing the efficient exchange of knowledge.
2.21 Creating the Knowledge Base
One of my strongest goals is to create an environment and culture where learning and sharing are core values. Like many technology professionals, I love to keep learning and often try to pick my assignments based upon how much I can improve my own knowledge and skills. The most successful organizations have a strong learning culture and an actively improving knowledge base. But this doesn’t happen by accident, and facilitating a good culture is exactly what strong technology leadership is all about. My approach is to facilitate cross-functional learning sessions where different stakeholders can share what they know and also learn from others.
The journey to being a knowledge organization takes considerable effort and what Deming called consistency of purpose. If you want to be successful, you need to realize that improving culture and behaviors takes time and effort. Continuously improving your process is likewise a long-term commitment and a journey that can take years to accomplish.
2.22 Continuous Improvement
Continuous process improvement requires a commitment to honest communication and a willingness to change and improve over time. I usually find that the best time to make improvements is right after an incident has occurred. Mistakes are not always bad, especially when they result in us learning and improving the way that we do things.
It is always a good idea to start by assessing your existing processes so that you first do not fix what isn’t broken and so that you can demonstrate progress by improving on your baseline processes.
2.23 Conclusion
Defining the software development process is a balancing act. Having too much process is just as bad as not having enough process. This chapter introduces some of the issues you need to consider when defining the software development process. The rest of the book continues to describe strategies for creating an effective and pragmatic agile ALM.