Definitions and Explanations
Formalism
As a development team grows, the number of communication paths increases exponentially, leading to more time spent on communication and a higher risk of errors [McC04, p650] This highlights the importance of streamlining communication processes or implementing effective limits in larger projects Efficient communication management is crucial to ensure project success and minimize misunderstandings as team size expands.
A typical approach for streamlining communication is to formalize the commu- nication in documents Different development methods have different levels of formalism, as illustrated in Figure 2.1.
Formalism in project development depends on the criticality of the project, as emphasized by Cockburn [Coc02, p162] When a failure could result in injuries or death, a higher level of formalism is necessary to ensure safety and reliability Conversely, if the consequences are minor, such as a few hours of lost work, the required level of formalism can be considerably lower.
Figure 2.1: Development methods have different levels of formalism The Water- fall model (see Section 2.2.1) is very formal, while Evolutionary Prototyping (seeSection 2.3.2) is very informal.
Iterative and Incremental
In "Iterative and Incremental Development: A Brief History" [LB03], Larman and Basili provide a comprehensive overview of the evolution of Iterative and Incremental Development They highlight that although some interpret iterative development solely as rework, it generally signifies ongoing evolutionary progress, emphasizing continuous improvement and adaptation in software development processes.
I have chosen to use the term "iterative development" to refer to rework, and "incremental development" to describe evolutionary advancement, as this distinction simplifies the understanding of these concepts By clarifying these terms, it becomes easier to differentiate between the process of repeated refinements and the gradual progression of development This approach enhances clarity in discussing software development methodologies aligned with best practices for efficiency and growth.
Sequential Development Methods
The Waterfall model
Royce presented what has later become known as The Waterfall model in his pa- per “Managing the Development of Large Software Systems” [Roy70] in 1970.
The software development process is divided into seven sequential, interdependent phases, as illustrated in Figure 2.2 However, Royce emphasizes the importance of iterative interaction between these phases, advocating for cycles that extend beyond the linear steps Based on Royce's experience, predictions and planning are often inaccurate or incomplete, making it necessary to revisit and correct earlier phases when issues are identified in later stages, ensuring a more flexible and reliable development process.
Royce's article was authored within the framework of government-contracting models, reflecting the constraints of that environment He was a proponent of incremental development, emphasizing the importance of iteratively building and improving software systems This perspective aligns with his belief that phased approaches can manage complexity and reduce risk in project management.
Figure 2.2 illustrates the traditional Waterfall model, a simplified development approach originally presented by Royce in 1970 Royce's article criticizes the rigid sequential nature of this model, highlighting its limitations He introduced this simplified version primarily to critique it and advocate for an improved, more flexible software development methodology.
As mentioned earlier, much of the argumentation for using the Waterfall model
Sequential development methods are guided by Boehm's Cost of Change Curve, as detailed in his book "Software Engineering Economics." This curve demonstrates that the cost of changing requirements or fixing defects increases exponentially as the project progresses toward completion Boehm emphasizes that making changes early in the project is significantly more cost-effective, encouraging thorough planning and using additional time upfront to minimize costly modifications later in the development process.
The Boehm's Cost of Change Curve illustrates how the cost of fixing defects increases exponentially the later they are addressed in a development project This graphical representation emphasizes the importance of early defect detection to minimize additional expenses By understanding this curve, project teams can prioritize early testing and quality assurance measures to reduce overall costs and improve project success (Source: Bec00, p21)
Incremental Development
The Spiral model
Boehms Spiral model [Boe88] is the classical example of an incremental method.
This approach enhances the traditional Waterfall model by shifting its focus from documentation to risk management In each development increment, the primary goal is to identify and address the most significant risks or sub-problems By prioritizing the resolution of these risks early on, this risk-oriented method improves project success rates and ensures more efficient and reliable software delivery.
The Spiral model is flexible and adapts based on the specific risks involved in a project, allowing it to incorporate various development methods When certain aspects like user interface and performance are low risk, but budget and schedule control are high risk, the Spiral model may resemble a sequential development approach Conversely, if user-related risks are high while budget and schedule are more predictable, the Spiral model shifts towards an evolutionary development style, emphasizing risk mitigation and iterative refinement.
Figure 2.4 clearly illustrates why the method is called the Spiral Model, showing how project costs escalate as development progresses A critical aspect of the risk analysis phase involves evaluating whether to continue or terminate the project, providing stakeholders with the opportunity to cancel if the project leader cannot demonstrate its profitability This approach helps manage potential risks and ensures informed decision-making throughout the project lifecycle.
Figure 2.4: Boehms Spiral model of the software process
Evolutionary Prototyping
The term "evolutionary" in relation to development was first introduced by Tom Gilb in his 1976 book "Software Metrics." According to Larman and Basili, this book was among the pioneers in thoroughly discussing key concepts like incremental design and evolutionary delivery, emphasizing the importance of continuous improvement and adaptive development processes.
Implementing a complex system successfully requires breaking it into small, manageable steps, each with clear success criteria This approach allows for measurable progress and provides the flexibility to revert to a previous successful stage if needed Gathering real-world feedback during each phase helps identify potential design errors early, enabling timely corrections and improving overall system performance.
Effective collaboration between the development team and users is essential for uncovering detailed project requirements through open discussions and cooperation This approach enhances user involvement, fostering a deeper understanding of achievable solutions, which ultimately leads to higher quality requirements and successful project outcomes [vV00, 55].
McCracken and Jackson, in their article “Life Cycle Concept Considered Harmful,” advocate for delivering a product early for experimentation or real-world use based on initial customer requirements They emphasize that development should be a collaborative process with the user, allowing insights into their environment and needs to inform subsequent adjustments This approach involves iterative modifications to the prototype, gradually evolving it into the final product.
This method suggests that a formal specification may be unnecessary, as the prototype itself can serve as a sufficient reference If reimplementing the product becomes necessary, the prototype provides an effective basis for the re-specification process.
Agile Development Methods
Extreme Programming (XP)
XP is a lightweight [method] for small-to-medium-sized teams devel- oping software in the face of vague or rapidly changing requirements. – Kent Beck [Bec00, p.xv]
The core of Extreme Programming (XP) revolves around enabling practices, as outlined by Fowler [Fow01], which help simplify project design decisions by focusing on immediate needs rather than future complexities [Bec00] Some argue that XP does not necessarily flatten the change curve but instead reduces the Cost of Change compared to traditional sequential development, enabling early detection and resolution of issues [Coc00] These practices enhance the likelihood of identifying problems early in the development process, allowing for quicker fixes and more adaptive design approaches.
The practices of XP are not new or revolutionary as Beck writes in his article
Embracing change through Extreme Programming (XP) is based on the insight that its practices work synergistically to improve software development Discipline in applying these practices enables teams to effectively adapt to evolving requirements, ensuring greater flexibility and responsiveness in project management.
Notice how for instance refactoring is made possible because of continuous inte- gration and testing, how testing and simple design is enforced by pair program- ming and so forth.
Beck outlines 13 key practices in his 1999 article [Bec99] and 12 practices in his 2000 book [Bec00], providing comprehensive guidance on effective methods This discussion covers only a subset of these practices, emphasizing the most impactful techniques For a thorough understanding of the method's principles and philosophy, readers are encouraged to consult the article for an excellent introduction and the book for an in-depth explanation of its rationale These resources collectively offer valuable insights into the core concepts underpinning the approach.
According to Bec99, writing automatic tests before coding is the core of XP, ensuring code is designed for testability Running these tests confirms that the code functions correctly before moving on to the next task Developers should verify that all tests pass prior to checking in their code, as failing tests indicate issues that must be fixed first.
In XP, both developers and customers are encouraged to write tests, enhancing clear communication of project requirements Customer-written tests at the end of each iteration help verify that the delivered functionality aligns with specified requirements These collaborative tests improve understanding, ensure quality, and foster shared responsibility for the software's success.
When I talk to people about XP, their first thought is often “ah, pair program- ming” I guess the reason for this might be because the idea of pair programming is quite extreme I imagine it can be quite hard to convince a customer that two programmers working with only one keyboard and monitor is an effective use of resources However, according to XP it is.
According to legend, "two heads work better than one," highlighting the benefits of collaboration in tackling complex tasks Programming is inherently challenging and intricate, as discussed in the article "No Silver Bullet" in [FPB78], which emphasizes its difficulty Therefore, teamwork and cooperation between two programmers can help manage this complexity more effectively and lead to higher-quality results, as supported by insights in [Bec00, pp100–102].
Pair programming encourages adherence to best practices, especially when team members are tired or stressed, as the partner can prevent skipping essential steps This collaborative approach ensures consistent practice enforcement, promoting higher quality code and team accountability (Bec00, pp100–102)
According to Erich Gamma [Fow00, xiii] the term was conceived in Smalltalk 2 circles but was soon adopted into other programming camps.
Refactoring is a disciplined way to clean up code and improve design without changing the functionality of the code Martin Fowler writes this in his book
Refactoring is essential to prevent code degradation over time; without it, software design deteriorates, making maintenance increasingly difficult and eventually impossible Regular refactoring ensures that code remains clean, manageable, and maintainable, safeguarding the long-term viability of the software.
Since XP is all about changing the code and design when you need it, refactoring is a crucial practice.
Instead of a lengthy requirements specification phase, XP employs what is called
During the initial phase of the project, known as "The Planning Game," developers spend approximately one month exploring requirements, collaborating closely with users and the customer to determine what needs to be built and how to develop it This phase involves gathering use cases and estimating the time required to implement each, ensuring a clear and structured approach to project planning Effective communication with stakeholders during this stage helps align development goals with user needs, facilitating successful project execution.
Customers prioritize their most important use cases to guide development efforts, ensuring the team focuses on delivering high-value features first Developers work iteratively on these prioritized use cases, enabling continuous progress At the end of each iteration, customers review the completed product increment to assess its value and determine the next set of features or improvements to pursue.
Like most other agile methods, XP focuses on releasing a small set of valuable features often Each feature delivered should be complete and tested In other
2 The pioneering object-oriented programming system developed in 1972 (Source: The FreeOn-line Dictionary of Computing). words, short iterations and valuable functionality delivered after each increment.
Software development is inherently complex, and human capacity to manage this complexity is limited To address this, Extreme Programming (XP) advocates the KISS (Keep It Simple, Stupid) principle, encouraging developers to implement only the simplest solution that works today If future requirements demand more, it’s best to wait and modify the design accordingly rather than overcomplicating the current solution This approach ensures maintainability and avoids unnecessary complexity in software projects.
To ensure clarity and address the informal nature of the requirements, XP emphasizes that team members should have direct access to customer representatives for additional information whenever needed Developers should feel comfortable promptly discussing use cases with users, such as by having quick, face-to-face conversations, to confirm their understanding This approach minimizes overhead and promotes effective communication, ensuring that the team accurately captures customer needs.
In continuous integration, developers must never commit code that fails tests, ensuring the repository remains reliable The code should always compile and function correctly to maintain a stable development environment Regular testing and adherence to this practice are essential for seamless collaboration and high-quality software delivery.
When working on your local code, it's important to make changes across the entire project to practice effective refactoring However, this approach can lead to increased conflicts with other modifications Implementing continuous integration helps minimize these issues by reducing the risk of complex conflicts, with the worst-case scenario often being the loss of an hour or two of work Most conflicts encountered during this process are typically easy to resolve.
3 Keep It Simple, Stupid See http://en.wikipedia.org/wiki/KISS principle
Scrum
Overview
The Scrum methodology is an incremental approach where each cycle, called a sprint, typically lasts four weeks Prior to each sprint, a planning meeting is held, allowing the customer to specify the features to be developed During the sprint, the team conducts daily stand-up meetings, also known as scrums, to coordinate progress and address issues At the end of the sprint, a review meeting is conducted to demonstrate the completed work to the customer, ensuring transparency and feedback Additionally, the team often holds a retrospective to evaluate the process, identify successes, and discuss improvements for future sprints, fostering continuous growth.
Schwaber illustrates the Scrum process flow with Figure 2.5, where the upper circle depicts the daily activities of team members, and the lower circle shows the development tasks carried out during a sprint, highlighting the interconnected nature of daily work and sprint-focused development.
Roles
There are three different roles in a Scrum project; the customer, the team and the scrum master.
Figure 2.5: Overview of the Scrum method.
The customer's role is to act as the representative for all project stakeholders, ensuring their needs and expectations are properly communicated Multiple individuals can share this responsibility, with key duties including funding the project and creating a prioritized list of desired functionalities This prioritized list, known as the product backlog, guides the development team's efforts and is essential for aligning project goals with stakeholder requirements Effective backlog management ensures successful project delivery and high stakeholder satisfaction.
Our development team is dedicated to implementing features requested by the customer, ensuring the delivery of high-quality product increments within each iteration As a self-managing team, they take ownership of transforming the product backlog into functional software, emphasizing efficiency and effectiveness The team is fully responsible for the success of every iteration and the overall project's outcome, playing a crucial role in achieving project goals and customer satisfaction.
Unlike traditional project leaders, who are often blamed for delays or unmet expectations, the Scrum Master has a focused responsibility: ensuring the proper implementation of the Scrum process Their primary role is to facilitate understanding and application of Scrum principles for both the team and the customer, supporting project success through process adherence.
He should help adapt the method to the company culture and make sure that it is being used properly.
He is also responsible for taking care of impediments so that the team can con- centrate on actually developing software.
According to Schwaber (2003), the Scrum Master role is not necessarily a full-time position, allowing individuals to be assigned to multiple projects or to contribute to the team as a developer.
Scrum Artifacts
Scrum, as an agile methodology, emphasizes minimal project formality to promote flexibility and adaptability However, maintaining transparency by allowing customers to track project progress is crucial, as it enhances their motivation and involvement At the same time, a certain level of structure is essential to facilitate effective team collaboration and focus on tasks.
The artifacts of Scrum are
The product backlog streamlines requirements by using concise, one-sentence descriptions for each feature, serving as a quick reminder for both customers and developers Unlike traditional detailed specifications, this approach simplifies communication while ensuring all stakeholders understand each requirement clearly This method aligns with modern agile practices, promoting efficiency and flexibility in the development process.
The Product Backlog is a prioritized list of single-sentence requirements maintained by the customer, who is responsible for keeping it updated Customers add new requirements to this list, while the development team estimates the effort needed for implementation An example of a Product Backlog is illustrated in Figure 2.6, highlighting its role in agile project management and product development.
Figure 2.6: A product backlog maintained in Microsoft Excel Figure taken from www.mountaingoatsoftware.com.
This two-dimensional graph illustrates the remaining work on the Product Backlog along the y-axis against the time elapsed since project initiation on the x-axis It provides a visual overview of the project's development speed, helping teams assess progress efficiently Additionally, this graph is useful for predicting project completion dates based on current velocity, as demonstrated in Figure 2.7.
Figure 2.7 presents a project burndown chart created by Brian Marick, illustrating the project's progress over time Notably, the chart features a hand-drawn projection of the estimated completion date, emphasizing that this is only an approximation This visual serves as a useful tool for tracking project momentum and forecasting deadlines while highlighting the inherent uncertainties in project planning For more insights, visit http://www.testing.com/cgi-bin/blog/2004/10/21.
The sprint backlog is a list of tasks selected from the product backlog that the development team commits to completing during a sprint Unlike the product backlog, which contains customer-requested features, the sprint backlog focuses on the specific tasks required to implement those features The team maintains and updates the sprint backlog to ensure smooth progress, while customers do not need to be aware of its details This distinction helps streamline development and clearly separates client-visible features from internal task management.
Tasks on the sprint backlog should typically be short, ranging from one hour to two days, to facilitate accurate estimation This practice enhances the precision of the sprint burndown chart, providing better visibility into the team's progress Keeping tasks concise helps ensure effective sprint planning and tracking.
This is quite similar to the Project Burndown Chart, only that it measures the progress of the sprint instead of the project.
A well-maintained sprint burndown chart should ideally resemble Figure 2.8 (a), indicating steady progress However, it often appears more like Figure 2.8 (b) because teams frequently discover new tasks during the sprint that need to be added to the backlog Since the chart tracks the remaining work rather than the completed work, it can sometimes show an increase in work remaining from one day to the next, providing an accurate reflection of ongoing adjustments during the sprint.
The burndown chart is a valuable tool that typically provides early warning if the team is struggling to complete the sprint on time When issues are identified, the team should communicate with the customer to decide whether to abort the sprint or re-prioritize backlog items Moving backlog items back to the product backlog results in a revised sprint backlog, allowing the team to complete it within the new scope This adjustment is reflected on the burndown chart by a noticeable drop in the graph, indicating progress towards completing the adjusted workload.
An impediment is any obstacle that hampers development progress Scrum masters play a crucial role in identifying and resolving these barriers to ensure smooth workflow To effectively manage these challenges, Scrum masters maintain a task list that tracks and addresses each impediment This proactive approach helps facilitate project momentum and team productivity.
Figure 2.8: Examples of Sprint Burndown Charts used in the Scrum process.
Sprints
All work is organized into four-week sprints, beginning with a comprehensive planning meeting This meeting is split into two sessions, each lasting no more than four hours, to ensure effective planning and coordination.
Scrum primarily focuses on management practices, providing clear guidance on team coordination and planning, while XP emphasizes engineering practices but lacks detailed management protocols Although the specific team workflows during a sprint are not explicitly defined, Schwaber notes that XP complements Scrum well, offering a holistic approach to software development Notably, Scrum can be viewed as a replacement for the planning game in XP, streamlining project management processes without delving into engineering details This synergy allows teams to effectively balance engineering excellence with effective management strategies.
In the initial sprint planning session, the Customer selects high-priority items from the product backlog to be completed in the upcoming sprint The Customer describes these items to the development team, who then provide time estimates for each task The sprint backlog is carefully filled to match the team's available work hours, ensuring a well-paced and achievable sprint.
In agile project management, selecting 5 items from the product backlog for the upcoming sprint is the first step The team collaboratively discusses these items to determine the necessary work to complete them, leading to the creation of an initial set of tasks known as the sprint backlog This initial set is considered preliminary, as developers often uncover new tasks during the sprint that need to be added to ensure successful completion.
During the second session, the team breaks down the prioritized backlog items into smaller, manageable tasks and adds them to the sprint backlog It is essential for the customer to be available for questions and clarifications throughout this process to ensure accurate task implementation and project alignment.
During a sprint, developers focus on completing items from the sprint backlog, ensuring steady progress Daily Scrum meetings, lasting no longer than 15 minutes, facilitate synchronization among team members by sharing updates on completed tasks, identifying any impediments, and planning next steps This daily stand-up helps maintain transparency and keeps the sprint on track for successful delivery.
Another important day to day activity is updating the sprint backlog and burndown chart.
At the end of each sprint, the development team conducts a review session with the customer to showcase the completed functionalities During this presentation, users demonstrate the new features, allowing the customer to provide valuable feedback This collaborative review process ensures transparency, aligns project goals, and facilitates continuous improvement.
Successfully demonstrating functionality that aligns with customer expectations fosters a sense of achievement for the team and provides proof that the project is on the right track If the demonstration doesn’t fully meet customer requirements, it becomes easier to identify the differences, clarify expectations, and determine the next steps Depending on the situation, only minor adjustments may be needed, or in some cases, the implemented functionality may need to be completely revised or discarded to meet project goals.
The purpose of this meeting is to help the team enhance their development process by reviewing recent achievements and identifying areas for improvement Attended by the team, Scrum Master, and optionally the customer, the meeting encourages team members to share what went well during the last sprint and suggest potential improvements After everyone has contributed, the team collaboratively prioritizes and discusses the improvement actions to ensure effective implementation To maintain productivity, the meeting duration should not exceed three hours.
Project Startup
Ken Schwaber has had much success with his kick-starting of Scrum projects as described in the book Agile Project Management with Scrum [Sch03] This process goes as follows.
The Scrum Master collaborates with the customer to prepare the product backlog, which is then reviewed jointly by the Scrum Team and the customer in a dedicated planning session During this session, the customer clarifies backlog items and the team estimates the effort required for each task Subsequently, the customer prioritizes these items and segments the backlog into sprints, ensuring a clear roadmap for project development This structured approach enhances communication, aligns expectations, and sets the foundation for successful Agile delivery.
The first day marks the beginning of the initial sprint, which closely resembles subsequent sprints However, unlike later sprints, the first sprint benefits from a partially completed sprint planning meeting, streamlining the start of the development cycle.
The team is now in complete control and have one task, namely to deliver the functionality the customer has requested The sprint has begun.
Project Completion
As the project progresses and sprints are completed, the customer receives incremental updates of the product If the customer determines the product meets their needs and no further development is required, they have the option to terminate the project early Depending on the negotiated contract, there may be penalty fees for premature project termination.
This case study evaluates the effectiveness of an agile approach in a real-world setting by analyzing a project undertaken by Company 1's team of software developers from Company 2 Detailed methodology and research procedures are provided in Appendix A The findings presented in this chapter offer insights into the practical application and success of agile practices within this collaborative software development project.
This article provides an overview of the involved parties and the project's history, offering essential background information It explains the reasons behind adopting a new method and highlights the key factors driving this decision The development process observed is described in detail, showcasing the project's progression and innovative approaches Finally, the article explores potential future outcomes for the project and team, considering possible developments and long-term impacts Overall, the content offers a comprehensive understanding of the project's evolution, strategic choices, and future outlook, optimized for SEO with relevant keywords and clear structure.
The Actors
Company 1
Company 1 is a very large company responsible for planning, building and main- taining roads They are also responsible for the supervision of cars, trucks and other road-users.
Company 2
Company 2 is a Norwegian consultant firm who specializes in software develop- ment and object oriented programming The employees are mostly highly edu- cated and the firm have a reputation of only employing skilled developers with at least three years of past programming experience.
The firm was established in 1999 and have since grown to become 70 employees(source Developer 1).
The Team
The development team at Company 2 experienced fluctuations in size throughout the project, starting with a single developer and expanding to a team of six at its peak For a detailed overview of the project's history, please refer to Section 3.2.2 To maintain developer anonymity, team members are identified as Developer 1 through Developer 8.
Developer 1 was the first developer on the project and is still working on it Devel- oper 7 and 8 worked on the project in 2003, but were moved to different projects at the end of the year Developer 2 joined the team in August 2004 and have been working on it since then Developer 3 and 4 joined the project in September 2005 and Developer 5 and 6 joined in December the same year In May 2006 Developer
4 and 6 were moved to a different project.
Today the team consists of four developers, three male and one female (Developer
5), working full time on the project The developers work at Company 1 in two adjacent offices in a floor dedicated to consulting firms working on projects for
Company 1 The offices are big enough that two people can work next to each other on different tasks, which is what the team were doing when I observed them.
Based on my observations and interviews, this group appears to be friendly, respectful, and enjoys working together Developer 5 confirmed a positive team environment, stating, “Absolutely They are forthcoming and helpful,” and expressed her happiness about being part of the team.
The Customer
In this article, "Customer 1" refers to the individual from Company 1 responsible for the project and interacting with our team, while "Customer 2" is the project leader, and "Customer 3" collaborates with Customer 1 to prioritize and manage the product backlog Based on my interview with Customer 1, I identified these three key people from Company 1 who make up the core project team Although some may consider Company 1 as the customer, I focus on these specific roles that directly influence project execution and communication This structure highlights the importance of clear stakeholder roles for effective project management and collaboration.
The Project
The Product
Company 2 was contracted to develop a comprehensive vehicle control solution designed for both in-hall scheduled inspections and roadside sampling tests This advanced system ensures reliable vehicle management across different environments, facilitating efficient and accurate control procedures By supporting various testing locations, the solution enhances operational flexibility and compliance, making it an essential tool for modern vehicle monitoring.
Company 1 faced challenges with their old system, including difficulties in tracking whether vehicles that failed inspection were properly repaired Additionally, vehicles traveling long distances were often subject to multiple stops and checks during their journeys, leading to inefficiencies and delays Implementing a more reliable system has been essential to improve vehicle oversight and streamline operations.
Solution Company 2 is developing an integrated system that includes a PDA with specialized control software, a web interface for scheduling and managing vehicle controls, and server software for data storage and system management This comprehensive setup enables seamless connection to various databases for real-time lookup of vehicle and driver information, enhancing operational efficiency and control accuracy.
The user interface for conducting controls was designed to minimize typing, enhancing efficiency This was achieved by integrating a barcode scanner on the PDA, allowing users to scan vehicle license plates and driver licenses easily Once scanned, the system retrieves relevant vehicle and driver information from a central server via a wireless network, streamlining the control process.
When the user has registered all necessary data, he proceeds with filling in the results of one of several pre-defined tests.
After completing the control, a receipt is automatically printed on the controller's vehicle printer, and the data is securely transmitted to the server for storage and future follow-up actions The receipt printing process utilizes network connectivity, eliminating the need for the controller to connect the PDA to any other device during the control process This streamlined system ensures efficient data management and seamless operation.
1 Personal Digital Assistant, aka handheld computer A small computer the size of a calculator.Usually has a touchscreen and can be considered the technological equivalent of a sixth sense orFilofax.
History
The project commenced in August 2002, with Developer 1 and Leader 1 collaboratively developing the requirements specification This initial phase concluded by late November or early December 2002 Following this, Developer 7 and Developer 8 designed a proposed solution, which received approval in January 2003.
The project was staffed with a development team consisting of Developer 1, De- veloper 7 and Developer 8 They delivered a pilot version for testing in August
2003 after which Developer 8 was moved to another project Testing and bug fixing continued into September.
In September, Developer 7 was reassigned to another project, while Developer 1 focused on system improvements, updates, and user training The system was initially scheduled for testing in autumn 2003 and full deployment in early 2004; however, due to infrastructure instability discovered in January 2004, the release was postponed A key issue was the GPRS 2 network's insufficient performance, which compromised the VPN 3 connection needed to access critical driver and vehicle database information As a result, the VPN solution was abandoned in summer 2004, prompting the development of a new security scheme to ensure reliable system access.
Developer 1 continued the system development during Spring 2004 while waiting for the network problems to be fixed During this period the functionality and ambitions of the project increased.
In August 2004, Developer 2 joined the project to enhance functionality and improve code quality During this period, development efforts focused on creating an SSL 4 authentication solution to replace the discontinued VPN solution, ensuring a more secure and reliable authentication method.
The product was launched into a pilot testing phase in January 2005, but testing was discontinued in June 2005 due to instability issues Key challenges included unreliable GPRS network connectivity and an unstable main portal infrastructure, which hampered the service environment and prevented successful deployment.
2 General Packet Radio Service, used for data communication over the mobile phone network
3 Virtual Private Network, used to provide a secure channel over an insecure network
Secure Sockets Layer (SSL) is essential for authentication and encryption of web pages and numerous internet services, ensuring secure online communication The product underwent several releases, with the final version before summer recognized as functionally stable, containing all necessary features It wasn't until December 2005 that the main portal infrastructure was fully operational, and the GPRS infrastructure achieved stability in February 2006, highlighting the gradual deployment and stabilization process of these internet technologies.
In August 2005 a refactoring of large parts of the data model and user interface was initiated This resulted in a new release candidate November 2005.
Developer 3 and Developer 4 were added to the project in September 2005 to implement new features The scope of the product was increased to support dig- ital tachographs, a system for keeping track of how long truck drivers have been driving without taking breaks 5
The Scrum method for project management was adopted in October or November
2005 to improve coordination of the different project activities as a result of the project growth This is covered more thoroughly in Section 3.3.
After a presentation of the product on Iceland, December 2005, an initiative by Company 2 to internationalize the product was started Developer 5 and Developer
In February 2006, six team members were employed and assigned to this project, adopting the Scrum methodology to enhance collaboration and efficiency They actively participated in Sprint planning meetings alongside the main development group, ensuring effective coordination and streamlined progress throughout the project.
I requested permission to study the project and, after a few phone calls and emails, was invited to visit Company 2 in March This visit is described in detail in Appendix A.
The internationalization work was completed in May 2006, freeing two develop- ers Developer 4 and Developer 6 were moved to different projects while Devel- oper 5 replaced Developer 4 in the main development group.
In May, I conducted another visit to the project site, which is progressing according to the original schedule Customer 1 reports that the project is on track, with plans to begin product utilization by September or October 2006.
5 I have not looked into the details, but there are regulations on how much long a truck driver can drive without resting.
Method Adoption
Why Base the Method on Scrum?
Before implementing Scrum, Company 2’s development team observed positive results from adopting the framework in their projects Agile methodologies and Scrum were already discussed in staff meetings, making the approach familiar to developers This prior knowledge allowed team members to share firsthand experiences and insights, facilitating a smoother transition to Scrum practices within the organization.
As a result of the above, the team decided to adopt scrum, but at their own pace and premises instead of uncritically by the book (Source: Interview with Developer1).
The Adoption
During interviews, I discovered that the team received an hour-long presentation on the Scrum development methodology from a Company 2 employee, showcasing how this method successfully operated within another team at the same organization.
In addition to this presentation, Developer 1 explored Dafydd Rees's article “Agile Project Management with Scrum,” which provides an in-depth overview of the Scrum methodology Meanwhile, other team members had not previously read any Scrum-related documentation Prior to adopting the new method, the team managed their development tasks using a spreadsheet, which was subsequently transitioned into their product backlog maintained in JIRA 6, facilitating more efficient task management and agile workflows.
The Development Method
Overview
The development methodology is an iterative and incremental approach, with each iteration lasting two weeks Releases are made at least twice a year, although the specific interval between releases remains flexible This method draws inspiration from the Scrum framework, as detailed in Section 2.5, but includes notable differences that will be discussed in Chapter 5.
Each agile sprint begins with a planning meeting, where the team outlines a clear list of tasks to be completed by the end of the cycle Developers typically arrive between 7 and 9 AM, and at 10 AM, they hold a daily stand-up meeting to discuss progress and coordinate efforts After the stand-up, they continue working diligently on their assigned tasks to ensure timely project development.
The Roles
During my observation, I identified two key roles in the project: the team and the customer, both modeled after Scrum roles These roles are integral to project success, with clear responsibilities that align with Scrum principles Their similarity to standard Scrum roles emphasizes the importance of collaboration and communication for achieving project goals For a detailed understanding, refer to the description provided in Section 2.5.2, which elaborates on these roles within the Scrum framework Implementing these roles effectively can enhance project workflow and ensure stakeholder engagement.
In the interviews and discussions the team said that Developer 1 also had the Scrum Master role, however I did not have a chance to observe this during my visits.
6 See http://www.atlassian.com/software/jira/ for more information on this tool.
The Backlogs
The team managed two key backlogs: the product backlog and the sprint backlog The product backlog is a comprehensive list of approximately 150 tasks of varying sizes and priority that the team works on to develop the product The sprint backlog consists of a subset of tasks chosen during the sprint planning meeting, which are prioritized for completion within the current sprint This structured approach ensures focused and efficient progress on product development.
The sprint backlog originally derives from the product backlog but evolves throughout the sprint as new tasks are identified and incorporated This dynamic nature aligns with the principles outlined in Section 2.5, emphasizing the importance of flexibility and continuous adaptation in Scrum processes.
Customers and users report errors or suggest new features by emailing developers or through mailing lists, and these requests are added to the product backlog The customer then takes responsibility for prioritizing each item, ensuring that the development team focuses on the most critical updates (Source: Interview with Customer 1).
During a discussion about the product backlog, I learned that the approach used on this project differed significantly from traditional Scrum practices Unlike Scrum, where the goal is to complete all backlog items to deliver a finished product, this team believed the backlog should always contain ongoing tasks such as adding, improving, or fixing features They viewed the backlog as a reflection of the project's maturity: a mature project includes many bug fixes and maintenance tasks, whereas an immature one focuses more on new features This philosophy rejected the idea of aiming for an empty backlog, emphasizing continuous development and maintenance rather than completion.
An empty backlog means that the project is dead
7 this is not necessarily how it is done, but that was how we talked about it during this discussion
Priority-Assignment Meeting
While I have not been able to observe one of these meetings, both Customer 1 and Developer 1 informs me that they meet at every sprint to discuss the product backlog and assign priorities For practical reasons there is no regular day and time for this meeting.
During the meeting, the team prioritizes new feature requests and bug reports from users to streamline development efforts They review the project's progress and discuss the strategic direction for future development, ensuring alignment with user needs and project goals This structured approach helps optimize resource allocation and maintain project momentum.
Sprint Pre-Planning Meetings
At the end of each sprint, usually on Thursday or Friday, the team holds a post-stand-up meeting to set goals for the next sprint, though I was unable to observe this directly According to Developer 1, during this meeting, the team defines sprint objectives through dialogue with the customer, often based on urgent needs like bugfix releases or key feature additions The goals are typically straightforward, such as deploying a new release or supporting an important feature Developers can propose tasks to include in the upcoming sprint, and these are subject to a vote to determine their implementation, ensuring collaborative planning aligned with customer requirements.
During this meeting, the team reviews and adapt their methods by integrating new practices such as Scrum or XP to enhance their workflow They evaluate their current practices, discussing which to retain and which to discard, ensuring continuous improvement and alignment with agile methodologies.
During the sprint planning meeting, developers are assigned top-priority tasks identified in the previous meeting These tasks are then presented and estimated as a group to ensure efficient planning and execution Clear task division at the end of the meeting helps streamline the development process and aligns team efforts with project goals.
Sprint Planning Meetings
Prior to the sprint planning meeting, high-priority tasks were assigned to team members, who prepared brief presentations outlining task details and implementation strategies These tasks were carefully estimated to ensure accurate timeframes and resource allocation Additionally, the team reviewed the tasks to identify duplicates, obsolete items, or those impacted by prior changes, ensuring a streamlined and effective planning process.
During the meeting, team members effectively discussed and clarified their task list, ensuring clear understanding and smooth collaboration They demonstrated strong teamwork in selecting tasks and balancing workload for the upcoming sprint, optimizing productivity Additionally, the team quickly assigned responsibilities for updating their software tracking system and documentation platform, streamlining sprint preparation and project management.
During my study, the team adopted planning poker, as detailed in Section 3.4.8, which significantly extended the meeting duration and facilitated in-depth task discussions To support this process, tasks for the upcoming sprint were distributed to team members beforehand, allowing each individual to present their assigned task and justify its inclusion in the sprint or suggest postponement This approach improved collaboration, transparency, and prioritization in sprint planning sessions.
Sprints
During the sprint, team members actively worked on tasks, which were then moved from the sprint backlog to the testing phase Upon successful testing and approval by a different developer, these tasks progressed to the completed items list This process ensured efficient task tracking and quality assurance throughout the development cycle.
Because my study focused mostly on the development method and not the coding
I have not previously discussed these systems, as I did not see them as crucial to development practices; therefore, I haven't covered how they integrate with daily coding activities.
I did notice that the developers talked to each other and at times moved between the offices to discuss the code with one of the other developers.
Stand-up meetings are held around a tall table in the ground-floor cafeteria, fostering quick and efficient team communication Initially scheduled at 09:00, the meetings later shifted to 10:00, ensuring flexibility in team routines These daily stand-ups begin as soon as all team members arrive, with each person sharing their previous day's accomplishments and upcoming tasks Conducted clockwise, this format promotes organized and transparent updates, enhancing team collaboration and productivity.
The cafeteria's open and occasionally noisy landscape did not seem to bother the team during meetings Although understanding conversations was sometimes challenging, this was likely because I was positioned outside the circle and the team was communicating directly with each other The team chose to hold meetings in the cafeteria because of its better coffee compared to the nearby office spots, highlighting a preference for a more comfortable meeting environment.
During team stand-ups, team members often raised obstacles hindering task completion, such as Developer 5's uncertainty about the network communication protocol design To address this, the team held a focused design meeting after the stand-up, during which they clarified the protocol, enhancing understanding not only for Developer 5 but also for other developers who consulted the source code more frequently afterward This collaborative approach facilitated problem-solving and knowledge sharing within the team.
The Burndown Chart gave a visual representation of this, as descibed in Sec- tion 2.5.
Planning Poker
Estimating tasks can be challenging due to the tendency to overlook subtasks, leading to inaccurate predictions To improve accuracy, implementing group estimation allows team members to collaboratively evaluate tasks, ensuring a more comprehensive assessment However, this approach can be influenced by developers who are most familiar with the code, as they often provide the quickest estimates, which others tend to trust without thorough scrutiny Incorporating effective estimation methods can enhance project planning and delivery.
Planning poker is a collaborative estimation technique where all developers individually estimate tasks and record their numbers Once everyone has finished, all participants reveal their estimates simultaneously, fostering discussion and consensus This method promotes accurate project planning and enhances team alignment, making it an effective approach for agile development teams.
In collaborative estimation processes, the highest and lowest estimators explain their reasoning, fostering a clearer understanding of the task This focused discussion typically leads to more accurate estimates compared to regular discussions, as it encourages deeper insight and consensus among team members Additionally, involving all developers in the estimation promotes inclusive participation, offering valuable practice for junior developers who might otherwise remain silent, thereby enhancing team cohesion and estimation accuracy.
Project Completion
The project’s completion timeline remains uncertain, as I have not observed its conclusion or directly inquired with the developers However, during my interview with Customer 1, we discussed the next steps, and he mentioned that the product is expected to be shipped in September or October this year, providing a tentative release window.
After release, the product will be actively maintained and updated for years To paraphrase the customer
I consider this a life time project If you deliver a product and say
Properly maintaining your information is essential, as outdated content becomes irrelevant within a few months, requiring constant updates Industry rules and guidelines are continually evolving, with comprehensive editions published every two years that include 1,200 to 1,500 pages of changes Staying current with these frequent updates is crucial for maintaining accuracy and compliance in your content.
Customer 1 did not know whether the current development team will be kept during maintenance, but he thought there might be some changes since the project will be moved to a different part of the organization.
This study aims to explore the practice of agile software development in Norway Based on discussions with my advisor, we determined that an interpretive case study is the most suitable research method to gain in-depth insights into how agile methodologies are implemented in the Norwegian software industry.
This chapter begins with an overview of research method theory, providing the foundational principles guiding the study It then details the data collection process, highlighting the methodological approach used to gather relevant information The chapter examines the validity of the collected data to ensure the research's credibility and reliability Concluding the chapter, a post-hoc analysis is conducted based on Klein and Meyers' seven principles from their 1999 article, offering a critical evaluation of the research methodology and insights into potential improvements for future studies.
Theory
Robert Galliers categorizes information system (IS) research into two main approaches: scientific and interpretive Scientific research focuses on objective observation and the ability to generalize findings, often involving hypothesis testing before the study begins In contrast, interpretive research recognizes that observations are influenced by the observer’s interpretation, acknowledging that the researcher’s perspective can shape the findings, making these studies more subjective and context-dependent This distinction highlights the importance of methodology choice in understanding and analyzing information systems.
Chen and Hirschheim's (2004) literature review of 1,893 articles from 1991 to 2001 revealed that 81% of information systems (IS) research relies on traditional scientific methods, highlighting a dominant methodological trend Galliers and Frank Land (1987) observed that there was a prevailing preference for traditional research approaches, even when interpretive methods could yield more insightful results They emphasized the importance of incorporating behavioral and organizational considerations in IS research, acknowledging that while this adds complexity and reduces precision, it aligns better with interpretive research methodologies.
This research adopts an interpretive approach, based on an in-depth case study that includes observations and interviews to gather rich, qualitative data While striving for transparency, the study acknowledges its subjective nature, with detailed insights into the research process provided in Section 1 and Appendix A By openly sharing my preconceived notions and the methodology behind the study, I aim to offer readers a clear understanding of how the research was conducted and interpreted.
In a further attempt to increase the quality of my research, I have done a post-hoc analysis of it using the seven principles that Klein & Meyers present in their article[KM99].
The Study
A major challenge in conducting empirical research is researcher bias, which can influence the objectivity of the study If researchers do not have a prior interest or opinion on the subject, it questions the motivation behind their research efforts Addressing this bias is crucial to ensure the validity and credibility of empirical findings.
Before I started my studies, I believed that agile methods are superior to the traditional sequential approaches I had previously learned While acknowledging that there are scenarios where agile may not be practical, I strongly believe that in small to medium-sized teams working on non-critical development projects, agile methodologies are the most effective choice.
The data collection was done using semi-structured interviews, observations from meetings I participated in and of course general observations made while I was
2006-03-17 Developer 6 (Junior) A semi-structured interview about his experience with joining the project and the development method.
2006-05-23 Developer 1 (Senior) A semi-structured interview about the project, development method, etc.
2006-05-23 Developer 2 (Senior) A semi-structured interview about the project, development method, etc.
2006-05-24 Developer 3 (Senior) A semi-structured interview about the project, development method, etc.
2006-05-24 Developer 5 (Junior) A semi-structured interview about the project, development method, etc.
2006-06-12 Customer A semi-structured interview about the project, development method (as seen by the customer), the customers experi- ences, etc.
Table 4.1: An overview over the different interviews I performed during the study. visiting Company 2 In addition I’ve received some of my data through email correspondence with Leader 1, Developer 6 and Developer 1.
During my research, I conducted two visits to observe and engage with the development team, first from March 16th to March 21st, and subsequently from May 21st to May 25th For detailed insights into these visits, please refer to Appendix A An overview of my interactions is summarized through interviews in Table 4.1, meetings attended in Table 4.2, and additional sources in Table 4.3, providing a comprehensive understanding of the development team's activities and environment.
Validity of my Research Data
As mentioned in Appendix A, I didn’t do a good job at taking notes during my second visit Because of this I had to trust my memory to some degree when
I reconstructed the sequence of events during the study So it is prudent to ask whether this has affected the validity of my research data.
For very detailed information like the length of meetings, my numbers are approx- imations and should not be considered very accurate When I did my observations
Discussion of cooperation between SINTEF and Company 1, introduc- tion to the company and project.
Staff meeting Mostly un- related to the project. 2006-03-16
Company 2 About 10 develop- ers from Company 2
Interest group on Ruby on Rails Unrelated to the project.
Company 2 Leader 1 and De- veloper 6
Company 2 Developer 6 More information on the project, questions and an- swers.
Sprint Planning Meeting and discussion of devel- opment methods and prac- tices.
Company 1 Developers 1-4 Stand-up Meeting
Company 1 Developers 1,3,5 Stand-up Meeting
Company 1 Developers 1-3,5 Sprint Planning Meeting
Company 1 Developers 1-3,5 Stand-up Meeting
Company 1 Developers 1-3,5 Stand-up MeetingTable 4.2: An overview over the different meetings I attended during the study.
Leader 1 Email History of the project
Developer 1 Email History of the project
Developer 1 Email Summary of the development method
Developer 6 Email Introduction to the project
Developer 1 SMS 1 Answers to short questions
Table 4.3: An overview over other important sources for information during the study.
I initially focused on the big picture rather than getting caught up in details However, I have become more thorough in my approach, ensuring the accuracy of my observations When unsure about certain information, I seek assistance from developers or choose to exclude that data to maintain the quality of my work.
Because of this I believe that my research data is valid.
Analysis of My Work
Principle 7
This analysis begins by comparing the Scrum methodology with the team's current approach It's important to note that the team did not aim to fully adopt the Scrum framework all at once, as highlighted in Section 3.3.1 Consequently, some Scrum practices have not yet been implemented, indicating a gradual integration rather than complete adoption from the outset.
When I have established some of the differences, I will try to explain the reason for the differences Finally I conclude the chapter with a few suggestions on how the team can improve their development method.
Observed differences
Project Startup
Implementing Scrum mid-project without prior guidance can be challenging, and it’s unclear if the team followed Scrum principles precisely Using their existing task list as the initial product backlog may not align perfectly with Scrum best practices, but this approach likely eased the transition to the new methodology Adapting Scrum during an ongoing project requires flexibility, and leveraging existing tools can facilitate a smoother changeover.
To effectively address this challenge, the alternative approach is to collaborate directly with the customer to develop a completely new product backlog This process typically takes around one day, which is approximately eight hours more than the time initially spent by the team on creating the backlog Implementing this strategy can lead to a more accurate and prioritized product plan, ensuring alignment with customer needs and enhancing overall project efficiency.
The key distinction between these two approaches lies in how the easy solution minimizes intrusion for the customer, making the process more seamless Unlike the alternative method, which requires the team to introduce the customer to the Scrum methodology and persuade them that it is a valuable use of time, the easy solution offers a less disruptive and more customer-friendly experience.
The Roles
The team and the customer worked pretty much as I expected (except for the sprint planning meeting as described below).
The Scrum Master plays a vital role in projects, especially when team members and customers are unfamiliar with the Scrum methodology Their guidance ensures the correct implementation of Scrum practices, promoting effective collaboration and project success Having a skilled Scrum Master is essential for aligning team efforts with the principles of Scrum "by the book," leading to better outcomes and smoother workflows.
The acting Scrum Master in this project lacked proper training, making it unreasonable to expect effective performance Since the team chose not to follow Scrum principles strictly, having a dedicated and fully trained Scrum Master may not be essential for success.
The Product Backlog
A quick review of the product backlog reveals a lengthy list of tasks, highlighting its ongoing nature However, during team discussions, it became evident that their understanding of the backlog differed from the Scrum framework, as they believed it should never be empty They see an empty backlog as a sign that the project has come to a halt or is dead, which contrasts with Scrum’s perspective of the backlog as a dynamic, evolving tool that adapts throughout the project lifecycle.
In Scrum, the goal is to complete all the items in the backlog.
In Scrum, the project backlog is a prioritized list of functional and non-functional requirements created by the customer, who should be able to read and easily adjust item priorities These backlog items are written in understandable language for the customer, ensuring transparency and effective communication Conversely, the team’s product backlog consists of smaller, more technical tasks primarily tailored for developers rather than the customer.
Sprint review meetings are likely to be adopted in the future, although they have not been held during recent visits These meetings are essential for stakeholders to assess whether the team has delivered the committed backlog items, as outlined in Section 2.5.4 Currently, evaluating task completion is challenging due to the technical nature of many backlog items, which relate to system design and internal development processes Implementing regular sprint reviews can improve transparency and project oversight.
The Sprint Backlog
I didn’t observe any differences between the sprint backlog used by the team and the one described in the literature.
Sprint Planning Meeting
Customer 1 did not attend sprint planning meetings due to having an overwhelming workload, resulting in less project attention However, interview insights suggest that increased team insistence could make these meetings possible Effective sprint planning is essential for project success and stakeholder engagement Addressing workload issues can improve customer participation in key agile processes.
The first part of the sprint planning meeting is not done on this project Instead,there is a separate priority-assignment meeting as described in Section 3.4.4.
Customer 1 was also available for questions and clarifications whenever the team needed this and provided a single point of contact, making it easier for the team to get the information they needed.
In addition he was active in facilitating field testing as well as performing planned testing of the product.
In accordance with Section 2.5, meetings are structured into two distinct sessions: the initial meeting with the customer and a subsequent team session Each session is limited to a maximum of four hours to ensure efficiency Once the first session with the customer concludes, the sprint officially begins, marking the start of the project’s active development phase.
The planning meetings I attended did not follow the typical structure, as the customer was absent, preventing the completion of the first part Although the second part of the meeting was somewhat similar to expectations, it still differed from the process outlined in Section 2.5 This discrepancy highlights the importance of customer participation for effective planning sessions.
In a refined agile approach, items from the product backlog are re-estimated instead of directly splitting into sprint backlog tasks A selected subset of these re-estimated items is then prioritized to form the sprint backlog, ensuring more accurate planning and better alignment with project goals This method enhances the clarity and effectiveness of sprint execution by focusing on well-assessed backlog items rather than fragmented tasks.
Daily Stand-up Meetings
I didn’t observe any differences here.
Reasons for the differences
Backlog
As I covered in 3.4.3, the team moved their list of tasks directly into the prod- uct backlog when they adopted the backlog from Scrum This set the standard for backlog items and this easy solution combined with their understanding of the backlog when they created it is the cause for the difference between Scrums product backlog and the teams product backlog.
The team experienced positive effects from adopting a new approach using product and sprint backlogs, which increased their satisfaction and confidence in their workflow They believed this method was effective and saw no reason to doubt their current process Overall, the transition to managing work through backlogs contributed to improved team morale and productivity.
The key impact of this difference is significant, as the backlog should primarily belong to the customer, not the team Providing the customer with a clear and understandable backlog enables easier identification of priorities and facilitates changes Currently, the backlog is overly technical and lengthy, making it difficult for the customer to review and frequently update priorities effectively Streamlining the backlog to be more customer-friendly enhances collaboration and improves project agility.
Customers tend to prioritize newly added items in the backlog, often leaving existing tasks unaddressed This approach grants some influence over upcoming work but falls short of optimal backlog management For effective project delivery, it's crucial to balance prioritization and regularly review all backlog items to ensure nothing important is overlooked Implementing strategic prioritization processes can enhance workflow efficiency and deliver greater value Prioritizing both new and existing backlog items ensures a more comprehensive and responsive development process.
Sprints
I wrote above that the length of the sprint should be four weeks In an interview, Ken Schwaber [Con06] argues against sprints lasting longer or shorter than this.
The optimal project timeline is four weeks, as it is the maximum period customers are willing to wait while remaining engaged in the process This duration also represents the shortest timeframe in which a development team can deliver meaningful and valuable functionality Keeping project timelines within this four-week window ensures sustained customer involvement and efficient delivery of quality results.
My research indicates that the team preferred two-week iterations, as attempts at three-week cycles proved inefficient Interview insights from Developer 3 revealed that three-week sprints led to loss of focus and a perception of diminished productivity, ultimately prompting the team to revert back to two-week iterations.
shorter product backlog items lead to smaller sprints and more manageable work cycles Scrum-sized backlog items typically involve selecting 5 to 10 features per sprint, which are broken down into a sprint backlog for focused execution As the team progresses, they experience small victories through completing individual tasks, providing immediate feedback and motivation These incremental wins contribute to overall progress, with completed backlog items each week reinforcing the team's momentum and inspiring continued development.
Since the team primarily handles small tasks and daily operations, they miss out on the satisfaction of seeing larger product backlog items or new functionalities come to life This lack of visibility can make it challenging to maintain long-term focus and motivation Focusing on delivering tangible features helps enhance team engagement and ensures continuous progress toward project goals Implementing strategies to showcase completed functionalities can improve productivity and foster a sense of accomplishment.
Sprint Planning Meetings
The team found that breaking product backlog items into sprint backlog items was unnecessary because the items were already appropriately sized for the sprint This streamlined approach enhanced sprint planning efficiency and ensured smoother workflow execution Optimizing backlog items to match sprint requirements can improve team productivity and project delivery.
These meetings differed from traditional Scrum sessions primarily due to variations in the Backlog and the absence of customer participation Our interview indicates that having a regular meeting with a customer representative is essential for effective communication A likely reason for the current setup is the lack of a dedicated Scrum Master and proper understanding of Scrum methodology, leading the team to be comfortable with their existing process The team receives a prioritized list from the customer and proceeds independently, which them seems to suit their workflow and satisfaction.
The customer was less involved in the project than initially expected, possibly due to their awareness of the need for a highly engaged user Despite this limited involvement, the project moved forward effectively, highlighting the importance of clear communication and user engagement in successful project outcomes.
Possible Improvements
Training
None of the developers on the team have received training in the Scrum methodology, which is a crucial oversight Implementing Scrum education could provide the team with valuable insights and proven solutions to common development challenges By adopting this approach, the team can significantly enhance their workflow and overall project success Emphasizing Scrum training is essential for continuous improvement and effective agile project management.
The Product Backlog
While I can’t show any evidence for this, I suspect that a product backlog that contains features and change requests written by the customer is a better solution than the one employed by the team This would provide both the team and the customer with a clearer impression of the project progress, and it would make it easier for the customer to prioritize the tasks.
Since the project has successfully operated with the current product backlog for over a year and the customer is satisfied, it is advisable for the team to maintain this approach for the remainder of the project However, I recommend exploring the implementation of the Scrum product backlog for future projects to enhance agile workflow and project management efficiency.
Meetings at the End of the Sprint
The team held a sprint pre-planning meeting at the end of each sprint, where they review tasks from both the sprint review and sprint retrospective meetings Scrum separates these meetings to streamline customer involvement, allowing the customer to participate only in the initial review, which is shorter and more focused on relevant updates This separation simplifies invitation processes and enhances the overall efficiency of sprint planning.
To ensure customers regularly attend meetings, it's essential to make these sessions valuable to them by removing irrelevant agenda items The sprint review meeting is particularly effective in inspiring both the customer and the team, so consider shifting relevant topics from the sprint pre-planning meeting to the review Including the customer in a demonstration of completed work during the sprint review fosters engagement and highlights progress.
If this works and the customer manages to attend this meeting, it should be easier to have him attend the sprint planning meeting later.
My initial impression was that the team’s approach differed significantly from established methods like XP and Scrum, leading me to believe they didn’t fully understand these frameworks It became evident that they hadn’t read the relevant literature, yet they appeared unconcerned about their lack of knowledge, which raised concerns about their commitment to proven Agile practices.
During my interview with Customer 1, I noticed a shift in my initial impression While I still find it puzzling why they haven't invested more time into understanding the method they are inspired by, the customer appeared highly satisfied with their work As he summarized, despite my doubts, their enthusiasm and confidence in their results were evident, highlighting the importance of passion and commitment in achieving customer satisfaction.
Effective communication with developers is crucial; clearly conveying project requirements ensures the desired outcome When instructing Developer 1 and the team on the project direction, providing precise guidance helps align their work with expectations Regular updates and feedback facilitate smooth collaboration between customers and developers, leading to successful project completion Clear instructions and ongoing communication are key to ensuring that the development process meets customer needs and achieves optimal results.
Effective communication about inspection procedures and regulations fosters collaboration between developers and project teams, leading to innovative solutions When misunderstandings occur due to differing perspectives on project rules, constructive discussions often result in improved outcomes Embracing diverse viewpoints encourages creative thinking and problem-solving, which benefit the overall project This collaborative approach helps both developers and teams to consider new strategies, ultimately enhancing project success and quality.
Now if we look at the agile manifesto (see Section 2.4), it says
we have come to value: individuals and interactions over processes and tools
While the team can benefit from further knowledge of development methods, they already possess strong software development skills They effectively demonstrate flexibility by adapting their approach to meet customer needs Since the primary goal of the Scrum methodology is customer satisfaction, the team is successfully delivering value and ensuring client happiness.
Interviews with developers reveal that they believe their current development method represents a significant improvement over previous approaches, fostering positive experiences This positive outlook encourages developers to share their success stories with colleagues and friends, likely increasing the adoption of similar methods in future projects The growing popularity of agile development practices can be attributed to this cycle of satisfaction and advocacy, as happy customers and developers contribute to better project outcomes and enhanced reputation in the tech industry.
Despite the team’s initial challenges when adopting Scrum, they executed the methodology effectively, delivering what the customer wanted While guidance from a Scrum Master might have improved their results, their current performance demonstrates team effectiveness Ultimately, achieving customer satisfaction is the primary goal of any development approach, and in this case, the team met that objective successfully.
Can they improve further? I suspect they will They are continuously improving their method and learning from each other and from their coworkers.