Notes by Ian De Silva
Introducing Agile in Large-Scale Projects
Vladimir Koncar, Ericsson Nikola Tesla
Drago Holub, Ericsson Nikola Tesla
Zoran Kokolj, Ericsson Nikola Tesla
Emina Filipovic-Juric, Ericsson Nikola Tesla
Josko Bilic, Ericsson Nikola Tesla
In this talk, Koncar described his team’s experiences using agile on a large-scale telecom project at Ericsson. This hardware-dependent project was estimated to be about 10 million lines of code, requiring the work of 100 developers for two years. Because of hardware-plan instability, uncertain requirements, and sensitive time to market, agile was the development methodology of choice. In particular, they used Scrum with long-term, cross-functional teams.
In their environment, there are numerous complexities. Koncar organized them into four sets: complexity and uncertainty; a large, distributed organization; a long-running project; and numerous stakeholders.
Complexity and uncertainty are present in the project in the form of unknown requirements, many dependencies between requirements, and a delayed and unstable project plan. Using short development cycles addresses inherent complexity and uncertainty, as the team can learn about the system and discover new requirements. Especially due of the volatility of the hardware, the incremental method was key to minimizing risk and allowing change to occur.
The large, distributed organization poses additional problems as work must be coordinated among many people in different geographies with numerous languages. To combat this, they developed a visualization of the architecture to create a shared vision, increased their communication, defined acceptable quality and used it to measure deliverables from each of the teams, and used continuous integration to provide early feedback on integration.
Long-running projects make it hard for the team to keep focused. Moreover, during that time teams and requirements change, so new team members and the team as a whole will need to be brought up to speed. To combat these problems, they kept teams intact and constant, improved backlog visibility, and increased their team ceremonies.
Having numerous stakeholders throughout the company posed another problem for the team as it was hard to identify the correct stakeholders and the stakeholders did not consistently prioritize the project. To address this, they increased their transparency and collaboration to ensure that stakeholders were a part of the development effort, and they admitted to delays and misunderstandings to start a dialogue with stakeholders. Further, because they used an iterative approach, misunderstandings and failures were limited to a small amount of wasted time.
What did they learn from all of this? They found that agile is a journey and it requires a mindset change. This can be difficult in a large organization because of the number of people who have to adopt the mindset. Some discipline (such as ceremonies) is required. The biggest benefit for them was to do small, beneficial things; get feedback; and learn from the experience.
The adoption of agile processes reduced the time to market by 30% and improved the quality of the product compared to expectations. Further, because of the success of this project, team morale is high.
How to Implement Zero-Debt Continuous Inspection in an Agile Manner
Brian Chaplin, Chaplin Solutions
According to Wikipedia, technical debt refers to the eventual consequences of poor software architecture or development quality. As architects and developers, we want meaningful code-quality statistics by which to measure potential sources of technical debt. Chaplin presented a case study of a project in which he used Sonar to aid in such measurements.
Chaplin advocates an extract, transform, load model to generate the data for analysis. In the extract portion of this model, he gathers information from Sonar, the source content management system, and project management systems and stores them in a database. In the transform phase, he generates change lists for the time spanning from the most recent extraction and the previous extraction. The change lists are then loaded into a quality database that will support reporting. After the quality database has been populated with the latest changes, these are sent out to the team via email, so team members who increased the technical debt can help lower it.
To aid developers in lowering the technical debt (this could be duplication, untested conditions, or a number of other things), Chaplin provides some best practices:
- Teams need a quality person who can help fix problems and coach team members.
- Code reviews are still necessary as they can eliminate false positives and catch things like bad documentation.
- A reliable and stable build are necessary for this practice to succeed.
- The team must establish static analysis rules and stick with them so that developers know the rules and are not surprised with sudden problems.
- Analyses must be run frequently to correctly attribute debt increases to the correct person.
There are a number of lessons to be learned from his case study. First, when proposing a similar technical debt management system, Chaplin suggests communicating the benefits such as improved maintainability, more testable code, and fewer defects. Second, false positives happen. False positives can be caused by untestable code, grandfathered code, static-analysis rules change, or a number of other reasons.
How do we manage the technical debt? We can manage it by providing immediate feedback to developers, encouraging refactoring, providing one-on-one assistance, and training the developers. Ultimately, ensuring the high quality of the product motivates developers and enhances productivity (see DeMarco and Lister’s Peopleware).
Implementing Contextual Design in a Corporation Without a History of Using Contextual Design
Elizabeth Correa, Verizon
What is contextual design? It is a bottom-up architecture where you, the architect, sit with your users and understand how they use the product. You use that information to improve the software. This is especially suited to enhancements to existing systems, migrations from legacy systems, or automating manual processes.
Elizabeth asserts that every project should use some contextual design to avoid ambiguous or missing requirements. In this talk, she presents her experiences with using contextual design at Verizon.
Verizon wanted to use contextual design, globally, for mission-critical software. They created a contextual design platform to support development and roll out this technique in their organization. In order to perform this roll out, they had to simplify contextual design, even renaming it “user-experience design” to improve developer and management buy-in. They also had to make the contextual design process more generic. This allows testers to use it to improve test scenarios, allows developers to determine why features are unused, and allows architects to clarify requirements.
Verizon encountered some challenges. They found that contextual design is disruptive to the user’s work and requires executive support. Further, they found that IT employees wishing to use this need a lot of training to use it and communicate their findings. To support the effort, Verizon added in, among other things, additional training modules and interview templates to facilitate the user-experience interviews.
In their pilot, Verizon found that in particular, the testers and architects love this method. Users also feel heard; they have a voice in the development of applications they will ultimately use. Their pilot was such a success that they are rolling out this technique to the rest of their business, trying to break the silo-ing of architecture, development, and testing.