Broken down to its barest and simplest components, software development goes like this: Gather requirements, write code, deploy. Depending on the process model used by a team of developers, there are other steps (like design, testing, and maintenance). The process also can determine how must time is devoted to each step, the order in which they are done, and the priority. There are a ton of software development philosophies and process models out there. We are just going to touch on two main ones in this post.
The “waterfall model” is a sequential approach to software development. Originally introduced as an example of a flawed process, it is actually in use at many technology companies. There are many critics of this process, but it has worked very well in certain environments. This model usually involves more documentation, more upfront design, and longer release cycles that contain large sweeping changes. It can be successful in environments where a small group of talented developers and architects are driving a large pool of less experienced developers with a higher turnover. That being said, it can also stifle developers, turning gifted software engineers into commodity coders. The longer release cycles can also lead to the dreaded software death march.
In 2001, a group of developers wrote the Agile Manifesto that is summed up as follows:
Uncover better ways of developing software by doing it and helping others do it. This approach places value on the following:
- Individuals and interactions trump processes and tools
- Working software trumps comprehensive documentation
- Customer collaboration trumps contract negotiation
- Responding to change trumps following a plan
In other words, “while value exists in the items on the right, we value the items on the left more.”
Agile is almost more like an anti-process than a process. In the 1990’s many developers noticed that with a “heavy process” approach to software development, you spent more time dealing with the process and less and less time actually writing and testing code. Around this time people started coming up with lightweight and agile methods for development like Scrum and Extreme Programming. These methods focused on shorter release cycles that were not sweeping version changes, and allowing developers to manage and adapt the process to their strengths. These methods are not for every environment, such as large teams that need to be managed or even small teams unable to manage themselves. But these methods can let a small team of talented developers pull off some really great stuff. This new iterative, rapid release model is evident today where the preferred model is no longer “teams of consultants and developers to service your software” and is just simply “software as a service”.
Next in this series I’ll cover what the Scrum process can look like and how we use it at Knotice.