Learning Report

The Software Delivery Lifecycle

The framework at the core of the Managing Design & Development module is The Software Delivery Life Cycle (SDLC). Into this life cycle fits the entire process for developing software and throughout the semester we learned where each critical function resides.

In the past I have worked in companies with an Agile and Waterfall SDLC. Both companies had hugely different corporate structures that reflected how they produced there products. For example, I worked at an early tech start-up with a Lean, Agile methodology as well as a long established semi-state company with a Waterfall structure. The main difference between the companies was the organisation of the teams and projects. The agile start-up had multi-disciplinary teams sitting and working together. Similar to how Iona had it’s teams organised. The semi state had project teams with members separated from each other (on different floors) and ‘staffing resources’ allocated to projects as they were required. The Agile process focused more on collaboration and performed in sprint Quality Assurance testing and iterative releases every few weeks. It resembled what Kent Beck describes as ‘Extreme Programming’ in his article ‘Embracing Change with Extreme Programming.’ Essentially, small releases with defined test cases to validate production and no large releases which require vast amounts of testing and increase the chance for errors. The Waterfall company I worked for was the opposite. It had huge six month long releases where things often went wrong after ‘go live’. Feedback was slow to be acted upon and miscommunication was a hallmark of the process.  Having experienced these different structures first hand, I was eager to learn more about the theory behind efficient design and development management. I had a basic knowledge about ‘Lean’ methodologies from books like ‘Lean UX’ and ‘The lean Start-up’ but knew relatively nothing about the early innovators and pioneers of managing design and development.

Dr. Winston W. Royce’s paper, Managing Development of Large Scale Software Systems completely opened my eyes to what the past can teach us. Even though we work in a modern, Agile development world, the stages of software development have not altered much. The theoretical Waterfall method outlined by Royce’s 1970 paper conveys clearly how initial system and business requirements inform analysis, program design and coding. His was one of the first clear explanations of how a Waterfall system should perform. Royce emphasises the importance of requirement analysis and early involvement of customers to ensure an optimized user experience and better product. I was motivated to map out my current working process in Aer Lingus based on the clarity displayed in his graphics. Starting simply, and elaborating more and more as the system takes shape. 

Research, Design and Analysis

Planning was big part the module. A Product Owner I once worked with could often be heard complaining about the lack of adequate research time before coding began. He could often be seen shaking his head saying “A goal without a plan is just a wish” and “we are wishing this product into life.” What he meant by this was the business alone should not be dictating what was built without gathering the necessary user requirements. The importance of clear planning with adequate user and design research cannot be stressed enough in the context of the SDLC. Research is critical to facilitate a smooth SDLC, and mitigate delays in development. The IDEO cards exercises are a great tool for defining user requirements early in the process. Testing early and often is critical for ensuring your team develops the right feature that will provide both user and business value. My preferred methods of early testing are sketch prototyping, user interviews and usability testing. I experimented with sketch prototyping for a new mobile sharing feature I was working on and shared my sketches and findings with the class. I find the best way to paper prototype is with Sharpie markers and luminous yellow highlighters to indicate buttons. Using this low-fidelity method has the added benefit of appearing experimental to users being tested. As a result both designers and testers don’t feel they are validating something finalised and so are honest with their feedback. Designers benefit from not having invested a long time designing high fidelity computer generated designs and get fast relevant feedback without feeling too precious about their designs.

Bill Moggridge in his article, “Expressing Experiences in Design”outlines the importance of design and how the experience of the user defines the product. His contention in the article is that experience is the most defining factor about a product. In today’s SDLC landscape User Experience Researchers and Designers are highly valued members of an Agile development team. User research, prototyping and testing is fast and relatively easy to perform at any stage of the cycle. Early, pre-development testing is great for a product, however it is important that the testing is relevant to the objectives and value proposition of the product. Researchers should not allow irrelevant data to skew design and development decisions. For example, Saul Greenburg in his paper “Usability evaluation Considered harmful” warns that usability testing, while a critical function of the SDLC, should be focused on the users emotions. He advocates an innovative, human centred approach to testing how users are feeling when using your product as opposed to how they perform specific tasks.

The exercise on researching and finding examples of business requirements was a great way for the class to get a good overview of different methods and types of requirements. The example I showed was for an urgent ‘Hot Fix’ that was required for a product I am currently working on. Due to the urgent nature of the ‘bug’ the requirement was just one line. This short, one line Business Requirement Document (BRD) illustrated that communication with clarity, not excessive detail, is the objective of a BRD. In this case, all that was needed for the design, development and testing team to understand what needed to be done was one sentence, “As a user I do not want to see the location services modal alert message on app start up.” The issue was a faulty location services Application Interface (API) that was using excessive battery in the background and leading to users deleting the app. We needed the modal removed immediately. 


Development & Quality Assurance

A process for development that interested me during class was the Rational Unified Process (RUP). In order, the process outlines Analysis, Design, Code and Test as the four stages. The system relies on strong communication between team members in every stage of the flow. Once development begins, a great tool for keeping team communication open is The Daily Stand Up. This was well demonstrated during the module. Each member of the multidisciplinary team, including Developers, Quality Assurance Engineers, User Interface Designers, User Experience Designers, Business Analysts, Scrum Masters, Project Managers and Product Owners all meet once a day for about 15 minutes. Each team member gives an update on what they did yesterday, plan to do today and if they have any blockers preventing them from doing their work. The team are standing up, deliberately, to ensure the meeting is fast. The purpose of the meeting is not to spend time solving big issues that arise, merely to communicate clearly what everyone is working on and what issues have arisen. The team can then schedule further meetings as required. Daily stand up is often a feature of an Agile SCRUM methodology. 

Philippe Kruchten in his article, “Voyage in the Agile MemePlex” explains how context is key for training and learning to be an Agile team. There should be no dictatorial edicts for how a team functions. For example, a short meme such as “iteration must be three weeks long” is meaningless without an explicit context for what will be produced in those three weeks. Teams need to decide themselves how they will function and find there own rhythm. This is a process that takes time. 

Another development practice we learnt about was the creation of User Stories to plan development releases. A collection of User Stories under a similar theme is known as an Epic. An epic breaks up a large piece of work into smaller User Stories. In class we practised estimating the size of each story using the planning poker method. This is where each team member anonymously states a size for a story and at the same time everyone shares their estimation. A discussion is had and a size is then agreed, usually an average. Story Sizing, Estimation (or Grooming as it is sometimes referred to) is a meeting where the entire development, design and QA team go through each story and assign a size to it. The size is a numeric estimation, and a measure on complexity, not on how long it will take to complete. For example, in a project I worked on a user story titled “As a user, I want an iOS tab navigation in my app,” was estimated as an 8. The sizing followed the Fibonacci sequence. While implementing a less complicated story could be sized by the team as a 3. The 8 is reasonably high because it involves more complexity, development, testing and investigation. While a smaller sized story, for example a 1 or a 3 might be far less complicated to develop and test.

Planning a new feature this way has many benefits both for the team and the business. The team gets an early understanding of the project and also to discuss the complexity from a development, design and testing perspective. This greater understanding also fosters a sense of ownership, teamwork and pride in the product. Once all the stories have been sized the total value is added to the epic, which is then added to the release. A follow on meeting from grooming is the sprint planning session. At this meeting, two week sprints are planned. The Business Analyst adds each story to the relevant sprint, and each member of the team adds tasks to the story. For example, a design review, a code review, development or testing tasks.

To ensure processes are continuously improving another tool we used was The Retrospective. Retrospectives take place at the end of a Sprint. They are an essential tool for assessing a teams performance. The process involves each team member contributing their feedback on the sprint. A common method is Start, Stop, Continue. Each team member outlines what went well that they would like the team to continue, what didn’t work well that should stop and some new suggestions to start in the next sprint.  

In my experience a sprint is usually a two week cycle, with three sprints making up a release. There is also one week of ‘regression’ testing where a product is tested to make sure all new features are working as expected and haven’t broken any existing functionality. Quality Assurance testing is a key function of a software team and is focused on testing what is being developed. In some Agile scenarios, testing happens in the sprint alongside development while in some Waterfall situations it happens after development.

The Quality, Scope, Time and Cost exercise was an excellent, in class, group exercise. It perfectly illustrated where trade offs have to happen in a project. For example, you might have the money and scope right, but not the time to implement your plan so the quality of what’s released will have to be sacrificed to reach a deadline.  I loved this quote “How does a project get to be a year late?... One day at a time.” (Brooks Jr., 1995) from Lecture 5. I also like the concept that adding more team members to a project that is running late will not serve to speed up delivery. More people adds more complexity and ‘ramp up’ time. The best teams are those that are intrinsically motivated and are given responsibility to deliver to the best of their ability. Both in the Iona case and in The Soul of a New Machine this was evident. For example in Iona;

“Product Development is team-oriented. Teams have strong software engineering capabilities
but also have product management, project management, customer service, business and other skills represented. Each team has significant autonomy...teams are ultimately responsible for product success, measured in market share and revenues.”

This snippet was taken from the Iona Development Team Guide. The multi-disciplinary team members are motivated to succeed. Each team has significant autonomy and are not micromanaged. They possess skill, talent and the motivation to enable high quality software delivery. Autonomy is not something that can just be given out to any team. Trust between management and development is earned over time and builds deep bonds with the company. Staff can align to the vision of the company if they feel valued and that they are an important part of the value the company creates.

Tom West’s Team were similar. While he had some potentially manipulative methods of motivating through fear, he got the results required from his team. West was an excellent motivator and had an initiation devised for new hires whereby they would ‘Sign Up’ to work on the project and forsake any obstacles to the projects success including hobbies, friends and even family. This had the effect of intrinsically motivating them. The employees felt there was an inherent pride in getting the new machine built and shipped. 



As a part-time student in a module with full-time students, it was a unique opportunity for me to share knowledge with, and to learn from, my peers. This required putting aside any assumptions I had about design and development from my industry experience and approach the learning with fresh eyes.

I learned as much from the group work as I did from my own reading and research. I particularly enjoyed watching the individual video research assignment presentations. I learned a lot about the subjective nature of research through each persons individual style. It was a great way to see a lot of research performed in a short space of time. I think companies would benefit hugely from having multiple teams performing parallel usability testing to ensure the chance for bias is diluted and a rich variety of feedback is ascertained.

I thought that the class exercises and learning through doing method was excellent. It had the two fold effect of encouraging teamwork, a key function of any team, creative thinking and problem solving. One key theme that reverberated throughout the course was the need for good management structures, planning and leadership.  In the article “From Organization Design to Organization Designing” it is argued that developing a design ‘gestalt’ (an organized whole that is perceived as more than the sum of its parts) and strengthening the capacity for organization designing is crucial for a company in our increasingly knowledge and experience-based economy. Designing the perfect process for a team to thrive takes time and understanding. Communication and team composition are the core requirements for a seamless relationship between design, development, testing and delivery. 

One aspect I thought would have been beneficial would have been mini stand up meetings within our table groups. Once we started working on the Iona case group work, we ended up giving updates on our progress in an ad-hoc fashion anyway so it would have been good to formerly tie it in using a stand-up meeting.

After this module I feel confident in identifying processes and practices involved in software design and delivery and able to apply context and relevance to different methods in the future. I discovered that describing complicated software life cycles and frameworks is best done using a graphic aide and that if a system sounds and looks complicated, it generally tends to be complicated. Through covering historical and emerging management approaches to design and development I now have an overview of where we, as designer and developers, have come from and how the process is evolving into the future. I have learned that there is no defined process that works for every situation. Managing design and development is a fluid practice and should be constantly assessed for optimization at each stage of design and development. 

The case studies and readings were excellent at highlighting real world problems and solutions. While software production evolves, people are inherently the same. A common thread will always be how people are managed and motivated. Designers and developers are creators and seek to be intrinsically driven. A good manager knows that there is creative pride in the work that comes from an SDLC and needs to mobilize employees to produce great work that they can be proud of. 

This module deftly introduced the skills and tools to facilitate the collaborative processes of design, development and quality assurance and I thoroughly enjoyed the experience.