The first Software Engineering Radio podcast featured in this blog speaks to a fundamental question within software projects, which is: how much do we know? If we know everything, we can plan everything. If we don’t know everything, then we need to go a bit more carefully, and figure things out as we go. This doesn’t necessarily mean that we don’t have a plan. Instead, we must be prepared to adjust and change what we do.
Waterfall versus Agile
In SE Radio 401: Jeremy Miller on Waterfall Versus Agile two different approaches are discussed; one is systematic and structured, whereas the other is sometimes viewed being a bit ‘looser’. In this podcast, I bookmarked a couple of small clips. The first is between 16:20 and 19:00, where there is a question about when the idea of agile was first encountered. This then led to a discussion about eXtreme Programming (XP) and Scrum. The second fragment runs between 45:40 and 47:21, which returns to the point about people. This fragment highlights conflicts within teams, the significance of compromise and the importance of considering alternative perspectives. This not only emphasises the importance of people in the processes, but also the importance of people skills within software engineering practices.
Following on from this discussion, I recommend SE Radio 60: Roman Pichler on Scrum. Roman is asked ‘what is Scrum and where does it come from?’ An important inspiration was considered to be ‘lean thinking’ and an article called ‘the new product development game’. It was later described as ‘an agile framework for developing software systems’ (47:50) which focuses on project and requirements management practices. Scrum can be thought of a wrapper where other software development practices can be used (such as eXteme Programming, and continual integration and deployment).
It is worth highlighting some key Scrum principles and ideas, which are discussed from 2:50 onwards. An important principle is the use of small autonomous multidisciplinary self-organising team (21:10) of up to 7 (plus or minus 2) people that comprises of developers, a product owner and a Scrum master. The Scrum master (24:15) is responsible for the ‘health’ of the team and remove barriers to progress. The team is empowered to make their own decisions about how they work during each development increment, which is called a sprint. A sprint (7:20) is a mini project that has a goal, where something that is built that ‘has value’ to the customer (such as, an important requirement, or group of requirements), and is also ‘potentially shippable’.
Decisions about what is built during sprints is facilitated through something called a product backlog (28:50), which is a requirements management tool, where requirements are prioritised. How requirements are represented depends on the project. User stories were mentioned as ‘fine grained’ requirements. In Scrum, meetings are important. There is a daily Scrum meeting (13:10), sprint reviews, and a retrospective (43:35). The retrospective is described as important meeting in Scrum, which takes place at the end of each sprint to help the team reflect on what went well and what didn’t go well.
Reflections
When I was an undergraduate, we were all taught a methodology that went by natty abbreviation of SSADM. I later found out that SSADM found its way into a method called Prince, which is an approach used for the management of large projects. (Prince is featured in the OU’s postgraduate project management module).
I was working in industry when Beck’s book about XP came out. When I worked as a software engineer, I could say that we applied a small ‘agile’ approach with a more traditional project management methodology. We used techniques from XP, such as pair programming, and continually kept a Gantt chart up to date.
At the time, none of us knew about Scrum. Our Gantt chart was Scrum’s burn down chart. We didn’t have a project backlog, but we did have an early form of a ‘ticket system’ to keep track what features we needed to add, and what bugs needed to be fixed.
One of the things that we did have was version control. Creating a production version of our software products was quite a intensive labour process. We had to write release notes, which had to be given a number, a date and saved in a directory. We built new installation routines, and manually copied them to a CD printing machine, which as asking for trouble. What we needed was something called CI/CD, which is the topic of the next post.