An Erasmus+ project
Since the universe we live in is extremely complex, it is not surprising to have a complex pro-cess like developing software. Some processes like pressurized carbon turning into diamond hap-pen by themselves. On the other hand, the process of developing software is highly intellectu-al.
When software products succeed, meaning they meet the needs of the users, people’s lives change for better. However, when software fail, bad things happen. The pursuit of developing good software requires discipline considering the process of software engineering involves solving complex problems. Numerous rules and standards that are not only from technology point of view but add to that the most complex organism on the planet called human.
Since most of the intellectual and creative aspect of software development comes from hu-man, teamwork is a necessity for software intensive organizations. The ability to unite a team and consequently the teams within an organization is crucial in developing a successful project. Leader-ship and management are at the core skills that raise unity as well as productivity towards devel-opment of high quality software.
A predictable software functions smoothly without errors and delivers the expected function-alities. Businesses, consumers and governments buy software systems as products. Customized software development, software products range in size from millions of lines of code in large-scale business systems to a few hundred lines of code in a simple app for mobile phones. (Sommerville, 2019)
Ian Sommerville proposes these three fundamental questions for finding product vision:
Some may believe that costumers are responsible for the product’s vision. This may be practi-cal for large enterprises but it is impractical in small software companies. In startups, the source of the product’s vision is the founder’s original idea as a solution to a problem that potential custom-ers have. This vision develops further long before a product manager is appointed.
PMs are responsible for managing the product vision. During development process, proposal for changes by developing team and costumers are inevitable. PMs have to compare the proposed changes against the product’s vision and the current working pipeline that the team is working on. They have to ensure that there is no “vision drift,” in which the vision is gradually extended to be-come broader and less focused. (Ian Sommerville, 2019)
Once the product manager takes the lead in developing the product vision. Market research and customer information brings even more changes. As Ian Sommerville states in his book called engineering software products, “I believe all team members should be involved in vision de-velopment so that everyone can support what is finally agreed. When team owns the vision, eve-ryone is more likely to work coherently to realize that vision.”
“Much of our society depends on processes that work because their degrees of impre-cision is acceptable. Wheels wobble, cylinders shake, and brakes jitter, but this all occurs at a level does not meaningfully impede our use of a car. When we build cars, we fit parts together with a degree of precision fit for their intended purpose. We can manage many processes be-cause the accuracy of result is limited by our physical perceptions.” (Schwaber, 2015)
In software engineering, a process is not a strict predefined systematic plan. Rather, an adapt-able approach enabling the people doing the work (the development team) to choose the appro-priate set of work actions and tasks. The objective is to deliver software in a timely manner with sufficient quality to satisfy the buyers as well as users.
A process is a collection of activities, actions, tasks that are performed when a product is to be created, in this case software. An activity serves the purpose of achieving a broader target (e.g. communicating with costumers) and is applied regardless of the domain, size of project, complexity of effort, or the degree of precision. An action (e.g. architectral design) consists of set of tasks that produce a major work product (e.g. an architectural design model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.
Complex problems are those that behave unpredictably and the ways in which they behave are impossible to predict. In other words, a statistical sample of the operation of these processes will never yield meaningful insight into their underlying mathematical model. Furthermore, at-tempts to create a sample is only possible through summarizing operations to such a degree of coarseness as to be irrelevant to those trying to understand or manage these processes. In Figure 1, the vertical axis resembles requirements complexity and the horizontal axis represents complex-ity of technology. The intersection of the two kinds of complexity defines the total level of com-plexity of the project. (Schwaber, 2015)
Software development process consists of three dimensions. Users, developing tools and de-signers. Users as the most decisive factor in this process require certain functionalities that design-ers must understand. Developing tools enable designers or engineers to deliver the functionalities users expect. Among existing Software Development Life Cycle (SDLC) models such as Waterfall, Scrum, etc. All of them follow six steps namely as requirement analysis, specification analysis, sys-tem design, development, test and implementation.
Technology involved in software development is advanced and often unreliable so that one can define the process of software development as the application of advanced, often-unreliable technology to solve business problems and achieve competitive advantage. Add to these the third dimension, which is the most complex organism on the planet, people. The complexity of develop-ing software raises even higher. (Schwaber, 2015)
What happens when we are building something that requires a degree of precision higher than that of averaging? What happens if any process that we devise for building cars is too imprecise for our customers, and we need to increase the level of precision? In those cases, we have to guide the process systematically, ensuring that the process converges on an acceptable degree of preci-sion. Laying out a process that repeatedly will produce acceptable quality output is defined process control. When defined process control is not achievable because of the complexity of the interme-diate activities, something called empirical process control has to be employed. (Schwaber, 2015)
“It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” (Ogunnaike and Ray, 1992)
In any software business, managers need to monitor processes, which gives them the possibil-ity of predicting failure. As describes in engineering software products, by doing so, not only they can take measured steps and raise the odds that a project is likely to deliver the software on time but also they can finish the project within its budget. Traditionally, managers draw up a project plan consisting of a set of milestones, deliverables, and deadlines. The “grand plan” for the project shows a set of milestones (achievable goals), deliverables (what the team will deliver), and dead-lines (when a milestone will be reached).
An advantage of scrum is that it facilitates empirical process control. The reason for that is de-veloping a successful software in the first attempt using empirical process is much cheaper than the cost of reworking an unsuccessful attempt using defined process controls. The problem with up-front project planning is that it involves making detailed decisions about the software long be-fore implementation begins. Inevitably, things change, new requirements emerge, team members may change and above all, business priorities evolve. Redoing a finished work leads to project be-ing too expensive or too late to deliver.
Developers of agile methods preferred incremental planning to plan-based management that consists of wasteful and unnecessary activities. Agile methods focus on plans that can adapt chang-ing circumstances. At the start of each development cycle, decisions are made on what features should be prioritized, how these should be developed and what each team member should do. Planning should be informal with minimal documentation and with no designated project manag-er.
This informal approach in agile methods lacks the broader business need of progress tracking and assessment. Senior managers do not participate in detailed discussions with team members, alternatively, they want someone who can report on progress and take their concerns and priori-ties back to the development team. They need to know whether the software will be ready by the planned completion date and relevant information in case they need to update their business plan for the product. (Sommerville, 2019)
Scrum the name derives from a rugby term used when teammates surround the ball and try aggressively to move downfield. Jeff Sutherland and his team develop the Scrum methodology in early 1990s. Furthermore, Schwaber and Beedle have developed the method during the recent years.
The need to for a more proactive approach to agile project management led to development of Scrum. To separate itself from traditional approach, Scrum named the link between the devel-opment team and the organization ScrumMaster and Product Owner.
“Scrum hangs all of its practices on an iterative, incremental process skeleton.” (Schwaber, 2015)
In Figure 4, the lower circle indicates an iteration of development activities occurring one after another, usually for one week to one month, leading to an increment of product. The upper circle resembles the daily inspection that occurs during the iteration. The goal of inspection is to allow individual team members to meet and inspect each other’s activities and make appropriate adap-tations. The process of iteration is driven by requirements and project funding and as long as there is funding the project can continue.
| Terms | Definitions |
|---|---|
| Product back-log | A list of features, improvements and fixes that Scrum team has not completed. |
| Sprint | A short period (two to four weeks) during which a product in-crement development takes place. | Scrum | A daily team meeting where progress is reviewed and up-coming work is discussed. |
| Potentially shippable product in-crement | The output of a sprint with high enough quality to be deployed for costumer. |
| Velocity | Estimate of how much work development team can do in each sprint. |
At the heart of the solution is the development team. Their work centers on delivering the result of each sprint (roughly between 2 to 4 weeks). Once the product backlog is ready for the next sprint, the team mutually commits to develop the product backlog into a potentially shippable product at the end of the sprint. Once the team commits, the time starts and the sprint becomes a time box in which the team can do whatever it takes to meet its commitments.
Scrum’s productivity stems from doing the right things first and doing them very effectively. The responsibility of maximizing efficiency is not for ScrumMaster and nor for Product Owner. The development team is also responsible for its own efficiency and their ability to manage themselves in meeting the objectives. (Schwaber, 2015)
To put things in perspective, the responsibility of self-management is a positive strategy con-sidering the survey made by Warden and Nicholson in 1996, which targets the motivation in IT staff. “IT is not a close-knit community of like-minded professionals. Many negative attribu-tions are made about other groups lacking the motivation for quality. Senior managers are ac-cused of paying lip service to quality, while starving it of resources in pursuit of profit. Software developers are accused of focusing on technical excellence, completely disregarding custom-ers’ need for a quality product. Customers are accused of demanding levels of quality, which they are not prepared to pay for. These are among the most common criticisms but there are many others. Each group within the profession makes negative attributions about other groups.”
Development team consists of software engineers and testers also known as Builders-as Evans describes in her book achieving software quality through teamwork- whom are people who speci-fy, design, and build and test the software. This includes the development team. The people in this group includes business and system analysts, software architects, designers, software engineers, programmer, developers, technical writers as well as testers. They are stakeholders for quality because they build quality into the product. They wrestle with difficult problems as they create new products.
ScrumMaster’s role is facilitating scrum projects. Why such as name? Since the responsibilities differ from Project managers, the difference in terminology comes as a symbolic one. ScrumMas-ter’s authority is indirect and largely shines by guiding the team within Scrum rules and practices. The main responsibility of ScrumMaster is to make sure that Scrum is followed throughout the de-velopment process and within the Scrum team. ScrumMaster fundamentally is a team coach who guides the team in the effective use of Scrum practices and guidelines. “While Scrum is easy to learn and adapt but many fail to make a good ScrumMaster” (Schwaber, 2015)
ScrumMasters are the champions of agile who make sure that Scrum works smoothly. They take care of scheduling ceremonies and carrying them out all the way to the end. ScrumMasters are also actively ensuring that the demos are as effective as possible when it comes to impressing the costumers. Moreover, ScrumMaster pays attention to newly added user stories and makes sure that new user stories do not impede user stories of higher priority and that Product Owner will notice the
Product owner is responsible for ensuring that the development team always focuses on the product they are building rather than diverted to technically interesting but less relevant work. In other words, PO is a team member who is responsible for identifying product features and attrib-utes. The product owner reviews work done and additionally, helps to test the product. In product development, the product manager should take on the role of a product owner role. (Sommerville, 2019)
POs are close to the team when capturing ideas. They are the main role behind prioritizing items on the backlog and they can approve user stories sometimes during the Demo. It is essential that the Product Owners attend every ceremony that they are expected to be in and make them-selves available for consultations. The expectations for availability of this role should be written out in the start of the project because these people are usually hard to reach. (Vanderjack, 2015)
POs rely on collaborative activities, because of their responsibility to capture ideas and creating sprint plans with the development team and ScrumMaster. Activities such as creating personas, transforming them to epics and finally generating user stories from the mist of ideas are effective practices in Scrum teams. The result is clear descriptions of the software requirements to plan first and following sprints.
For writing the right user stories, the Scrum team needs to understand the target users and customers. User stories tell a story about the users using the product. If you do not know the users and what problem we want to solve for them then it is impossible to write the right stories and the team ends up with a long wish list rather than a description of the relevant product functionali-ty.
Personas offer a great way to capture users or costumers with their needs. They are fictional characters with imaginary names and pictures. Moreover, relevant characteristics such as role, ac-tivities, behaviors, attitudes and a goal (a problem that should be solved or a service to be provid-ed).
This template is designed by Roman Pichler is simple yet effective. It includes picture and name on the left. Description in the middle and goal on the right. It is important to create the primary character whom the product is mainly targeting. Once the personas have been developed, the next step is to derive Epics from the persona’s goals.
The purpose of epics is to capture functionalities as coarse grained, high-level stories according to Roman Pichler. Starting from the primary character, write all the epics required to meet the per-sona goals. Epics are sketchy ideas and do not include detailed technical requirements.
Epics need to capture user’s interaction with the product and the steps in which different steps are taken to be able to interact with the product this requires initial visual design of the product. Furthermore, nonfunctional qualities (e.g. systems integration and performance) are within the context of writing useful epics. Use of diagrams, storyboards and sketches can be major progress at this stage.
The goal of this phase is to gather enough user stories for the next sprint to deliver enough functionality and in time, therefore it is not required to derive as many user stories as possible. One of the advantages of using this approach is reducing the items in your product backlog.
Ideally, the product backlog should address the key risks; you may start pre-writing user stories and have a larger inventory of detailed items since your backlog is unlikely to change significantly during the incremental development of the product.
As a rule of thumb, stories should have three qualities before the development process can start. Moreover, in the final stage of generating user stories, the team needs to make sure each story has clear, feasible and testable characteristics. Such qualities help to fit stories that are small enough for the development team to carry them out during one sprint, implying the user interface design, test, and documentation work can be carried out.
Professional software develops by project teams ranging from two to few hundred people. It is clear that many people cannot work on the same problem therefore there is a need to split into number of groups and each group being responsible for developing part of the final system. When small groups are formed, communication issues are reduced and the whole team can get around a table and discuss the issues regarding the project. (Sommerville, 2019)
Overview – In this workshop where we will break into teams and guide everyone along each step of the process. You will create a story mapping on the walls and layout your user stories with priorities and business values to determine your first sprint plan.
00:00 – 00:05 ~ break into teams of 5 to 9 people and choose a Product Owner who will collect product vision from trainer.
00:05 – 00:20 ~ First, Product Owner reads the product vision statements for the team. After that, the team starts to place the personas on a wall with work-flow/activities/goals. Constructive discussion is the key at this stage! (Note: The goal is to identify features, modules and activities. For instance in case of a Game you might have Characters, Land-scapes and Marketplace.)
00:20 – 00:30 ~ Identify features or modules on the high level!
00:35 – 00:40 ~ Identify features or modules. (Note: At this stage try to add features/modules horizontally. You can add detailed sub-features vertically during each sprint.)
00:30 – 00:45 ~ Write user activities and workflow
00:45 – 01:05 ~ Write any user stories for each activity that users have with the product.
You can use this format:
As aNote: It is recommended to put the cards horizontally rather than vertically!I want to So that
01:05 – 01:25 ~ Mark Cards with Business Values (High/Med/Low) and the effort required to accomplish. You can get creative with the scaling but here are some suggestions:
01:25 – 01:45 ~ Discuss and assign Priority (MoSCoW).
01:15 – 01:30 ~ Determine Release 1. Break down the cards and create the first release (MVP)
