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.

People are the core of any SDLC - Lecture 3.

Themes from these three readings:

Brooks Jr., F. P. (1987) No Silver Bullet Essence and Accidents of Software Engineering. Computer, 20, 10-19.
• McCracken, D. D. & Jackson, M. A. (1982) Life cycle concept considered harmful
• Gladden, G. R. (1982) Stop the life-cycle, I want to get off.

Essence and accidents of software engineering

  • The central question in how to improve the software art centres as it always has on people. Software construction is a creative process, the difference between poor design decisions and good ones lies in the design method employed. Structures that are faster, smaller, simpler and cleaner and produce less effort will win out with employees.
  • A firm should develop ways to grow great designers and a culture of innovation. They should Identify top designers and leaders as early as possible. They should be engaged and their careers need to be ensured with personal development plans and mentorship.
  • The silver bullet is to grow a culture of innovation where software designers can flourish productively. Where they feel a sense of pride in the work and see themselves aligned to the company for the future. 

Lifecycle considered Harmful

  • Organisational analysis
  • Systems evaluation
  • Carreers and mentorship programs
  • Feasibility analysis
  • Project plan
  • Logical desig
  • Any form of lifecycle is a project management structure.
  • The life cycle concept perpetuates our failure so far, as an industry, to build an effective bridge across the communication gap between end-user and systems analyst.
  • Heavy end-user involvement in all Phases of the application development process--not just requirements specification, but design and implementation also.
  • The life cycle concept rigidifies thinking, and thus serves as poorly as possible the demand that systems be responsive to change.

Managing Development of Large Scale Software Systems. Lecture 2.

Royce, W.W. Managing Development of Large Scale Software Systems

In this article, Dr. Winston W. Royce describes, based on his nine years experience, his views about managing large software developments. His area of work, spacecraft mission flight systems is obviously a hugely critical field where lives would be at stake. As such, his process requires serious focus and testing to ensure validation.  I found this article to be very insightful. My initial reaction to the publishing date, 1970, was that this system would be outdated. However, after reading the article and observing the carefully crafted diagrams of the process it soon became clear that there are many similarities with current Software Delivery Life Cycles.  For the purposes of easy assimilation I've listed the graphics in order here. I've also attempted to illustrate my current production process in Aer Lingus. 

 love the simplicity of the above framework.  Good analysis might be all that is required for a successful project to be coded. Good analysis means less changes mid development.

he above graphic shows the full elaborated process. Below I've outlined our current work flow as an Agile team. The user stories, or the nucleus of a story, comes from the backlog and is refined  through Business Requirements, Content, User Interface and Development input. The solidified user story is then designed, prototyped and usability tested. If it fails testing it is further refined and re-tested. Once validated through testing it is passed into production.

Share Flights with Whatsapp

Using Paper Prototyping to illustrate quickly a concept for increasing revenue on the Aer Lingus iOS app.

From the quick paper prototype we agreed that through a screenshot a user should be able to share a date range of available flights and prices.

Transformational Leadership at Iona

When changing from one organisational structure to another, nothing is more important than aligning teams to the new vision of the company. New leads were employed for each department and in some cases new teams were created from scratch. 

The Company is now evaluating the Scrum methodology and are seeking to understand how it would impact their working environment, work practices, management and organisational structure, and also their status as an ISO9001 certified organisation The same lifecycle model is also used by some of the company's largest client organisations.

The company's customer support queues are highly volatile (see figure below). The customer support queues fluctuate wildly over time and may sometimes halt new product development projects in order to address urgent customer demands.  External changes are significant drivers for both maintenance and main product releases.

In conclusion, the organisation appears to follow two very different approaches to managing production. On the one hand there is a sequential/linear process for managing and releasing new product versions; the NPD (new product development) approach. On the other hand there is on-going support and maintenance work which is highly responsive, crisis driven and reactive. The leap from the academic to the commercial world was tempting as industries like banking and telecommunications embraced networks and internets. From the beginning Iona attracted gifted technologists and programmers, many of whom went on to establish their own companies or lead innovations in other organisations

Business Requirements

Here is an example of a recent User Story with early business requirements. They are short an clear initially. A developer, designer or stakeholder can look at this and understand what's required. In this case, to integrate an existing SDK to allow deep linking from Facebook into our application. 

The below graphic from the lecture introducing business requirements quite aptly describes the relationship between business analyst, user and designer. The analyst here could also represent a research or data analyst, both of whom also contribute greatly to the user story creation. 

Story Grooming, the Cost of a Point

Working closely with the business analyst of the team, a seven week release plan was drawn up comprising three two week sprints and a regression week. The regression week is a week for quality assurance engineers to test everything from the release rigorously before it is published to the app store. It was agreed with the team that the new proposal, having four main tab sections, would be divided into four epics. My Trips, to encompass any day of travel flows and user interfaces, My Profile, Information and Book a Flight. Each epic was then divided into stories based on individual pieces of functionality. As the new navigation system has detailed specification in the iOS Human Interface Guidelines a lot of the functionality will be straight forward to implement. As no new features are being built the main body of work involves moving components and re-organising the layout. As such, several stories were created for introducing the new navigation component, that will be started in the first sprint. These initial stories will shape the framework for the following sprints.

The stories were created using a product management tool called Jira. Any visuals, user flows, prototypes and specification were attached. A Grooming session was planned. This 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 the meeting the first story called “As a user, I want an iOS tab navigation in my app,” was estimated as an 8. While implementing the Search Flights flow into the new navigation was only a 3. The 8 is reasonably high because it involves adding a new component. Re-housing the search flights section is only estimated to be a 3 by the team as the new navigation will already be built. 

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 gets 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 epics, which are then added to get the release points value. A follow on meeting from grooming is the sprint planning session. At this meeting, the two week sprints are planned. As the total release points were 63, the three sprints were divided into 21 points each. 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. 

www.planningpoker.com is a great tool for fast, efficient sizing of stories. Below is an example of a sprint sized.

Mobile Boarding Pass Time Lapse

I created a time lapse of people using the bag drop kiosk to check-in their luggage at the airport. After 20 minutes of time-lapse footage I checked the camera and realised I hadn't turned of screenlock so it automatically stopped after a few minutes. However, it worked long enough to record a group of three young people attempt to scan a mobile boarding pass using an Android device. They failed first time round and are recorded returning to the kiosk. I watched them personally and they ended up needing assistance. It transpired that because the user had the screen brightness turned right down there was not enough contrast for the kiosk to read the barcode. 


The Chaos Model - Lecture 4

Racoon, L. B. S. (1995) The chaos model and the chaos cycle. ACM SIGSOFT Software Engineering Notes, 20, 12.


"I believe that to truly understand software development, we must not only understand the flow of an entire project and how to write each line of code, we must also understand how one line of code relates to the whole project."

The Chaos model combines a linear problem solving loop with fractals to describe the complexity of software development. The linear problem-solving loop involves four different stages: problem definition, technical development, solution integration, and status quo. Fractals describe the structure between different parts of a project. The Chaos model differs from other models in that it imposes little organization on the development process, rather, it allows many organizations to evolve.  This allows the Chaos model to apply in many complex situations. 

 the Chaos life cycle which views requirements analysis, design, implementation, maintenance, and prototyping -- the phases of the life cycle -- in terms of fractals. I include prototypes in this list because prototypes are,identifiable parts of a software development project. A life cycle shows how phases change over the course of a project. While we usually view these phases as flexible concepts, defining them as fractals leads to some refinements and generalities that we normally overlook and shows that all phases occur throughout all of software development.