Please note that this session will work best with a maximum of about 20 attendees.
Blitz Planning is a technique developed by Alistair Cockburn which builds upon and extends the familiar (from XP) planning game and described in detail in his book Crystal Clear. This workshop presents an updated version which borrows from the concept of the Kickstarter campaign to reflect current thinking around hypothesis-driven product development.
Blitz Planning is a fast moving highly collaborative activity which supports the development of the first three-month planning horizon for any technology project. The outcomes of a Blitz planning session can be used to inform activities such as story writing or story mapping, but the technique differs in both process and outcomes in several significant ways. Key among these are the breadth of the tasks included. In a Blitz planning session, tasks are written at a much higher level and include both technical and non-technical items such as the need to develop training or marketing materials, the need to identify and provision infrastructure. There are opportunities to identify any long lead or lag times or dependencies on a particular individual, or group. Because technical and business stakeholders work together, it is possible to rapidly identify project dependencies and bottlenecks and expose any potential hidden surprises in the project. A key benefit of this technique is the resultant shared understanding of what is actually involved in delivering the project. It gives business representatives the opportunity to ensure that the expected business value of the project is clearly understood as well as providing technical representatives with the opportunity to make sure that any technical constraints or challenges are properly socialised.
Blitz planning can be conducted towards the end of an inception or project kick-off workshop and provides technical and business stakeholders with sufficient information to make crucial decisions as early as possible in a project. A successful outcome from this technique may equally be a plan to conduct an experiment or even a decision not to proceed with a project in its envisioned form due to the identification of constraints.
While originally developed with technology projects in mind, this technique can be used to kick off many different project types.
The Agile Movement recognizes “individuals and interactions” as central area for realizing better ways of developing software. Sponsors, developers and users shall work together daily to maintain a constant pace. Software development is people working together, software development is collaboration. While traditionally the role and the tasks of a developer were quite solitary, XP introduced collaborative practices like On-Site Customer and Pair Programming to deliver valuable solutions of better quality at less costs. The story doesn’t end here. People look to improve collaboration further: why not work really together-as-a-team? All the members at the same time on the same artefacts? As we do it in everyday life! Experiments began with such Real-Time Collaboration. Today we see processes like Swarming and Mob Programming grow into wider acceptance. The experience shows that they can raise intra-team collaboration to new levels. Yet, any system will likely be composed of interdependent subsystems and there will be several teams working on them. What will happen in the teams? What will happen between the teams? How do mobs work together?
Let’s try it!
This workshop will give people a playful, fun opportunity to try out working under Real-Time Collaboration conditions. The attendees will form teams who will be given a flow of requirements which they have to implement with certain quality criteria. The workshop will progress in phases with growing interactivity and always new challenges. After each phase and at the end of the workshop participants will share their experiences and discuss the lessons learnt. In order that anyone can attend regardless of her/his technical expertise we will use English (or German, depending on the audience) as development language and Google Docs as our IDE. Bring your WLAN-enabled laptop/device that is able to run Google Docs.
Do you want to experience and observe the dynamics of an Agile Team? Do you accept the challenge to escape a collapsing temple? This session runs several iterations with the affordable collaborative game “Escape” for providing the opportunity to experience team dynamics from different perspectives as team member and observer. In each iteration all teams work for themselves and try to escape a collapsing temple. Each round is followed by a reflection, in which team members and observers discuss and learn about the recognized behaviors and how to improve the next round. It’s a great simulation for teams starting with Agile in order to experience and reflect the probable team dynamics within a short time span. And it's a fun and energizing format, which is well suited for team liftoffs and retrospectives.
You will experience
Furthermore you can take away a workshop format that you can run with your own teams or within your own classes, especially in liftoffs and retrospectives.
Generating innovations is a must for any technological company that seriously intends to stay alive and prosper. The Internet of the Things (IoT) is a concept that involves thousands of millions of devices, and offers seemingly endless opportunities to generate innovations. IoT opens up for the establishment of new technological platforms as well as new types of ecosystems consisting of e.g. different firms, public organizations, and communities. These ecosystems constitute dynamic environments for the development of IoT technology and for generating innovations. Software is essential to foster all these innovations.
However this specific context also brings about numerous challenges. Like in many other industries, the technological life-cycles become shorter year by year, the pressure for reduced time-to-market constantly increases, and customers are becoming ever more demanding and also requires higher degrees of customization. Altogether, this increases the uncertainty associated to the innovation development process. Some particular features of IoT innovation render it particularly challenging. As IoT comprises numerous different technologies the demand for effective integration is substantial. Moreover, the development of IoT often takes place in networked ecosystems with multiple stakeholders, and this underlines the need to develop suitable business models that allow for fruitful collaboration, value generation and appropriation
In this context, software developers more and more need to attend to innovation in their development work: when developing new and attractive-to-the-customer products with the ambition to become innovations they have to combine creativity, agility and speed to keep up. Creativity is a fundamental resource in an innovation-intensive environment, but needs to be combined with agility in order to effectively introduce flexibility in the process and make decisions to cope with uncertainty. Speed will be required to deal with intensified competition and demands for reduced time to market.
This workshop will analyze and understand the role that agility plays in generating innovations, which this far is inconclusive and even presents conflicting results. Furthermore, agility needs to be harmonized with speed for effective innovative product development in the context of the Internet of Things.
Decision Making Processes and Agile Philosophy: What Constrains Decisions in Agile Organizations?
Maria Carmela Annosi, Federica Brunetta, Mats Magnusson and Lucia Marchegiani
Security Challenges in IoT Development: A So ware Engineering Perspective
Anh Nguyen Duc, Ronald Jabangwe, Pangkaj Paul and Pekka Abrahamsson
CitySense: Blockchain-oriented Smart Cities
Simona Ibba, Matteo Seu, Andrea Pinna and Filippo Eros Pani.
An analysis of the Bluetooth Terminal development pivots from the creativity perspective
Juan Ochoa-Zambrano and Juan Garbajosa
Selling the Business Case for Architectural Debt Reduction
Eltjo Poort, CGI
Changes and Challenges of Technical Debt and Its Management During Ongoing Digital Transformation
Jesse Yli-Huumo and Kari Smolander
Revisiting Context-Based Code Smells Prioritization: On Supporting Referred Context
Natthawute Sae-Lim, Shinpei Hayashi, and Motoshi Saeki
Who Is Producing More Technical Debt? A Personalized Assessment of TD Principal
Theodoros Amanatidis, Alexandros Chatzigeorgiou, Apostolos Ampatzoglou, and Ioannis Stamelos
Assessing Code Smell Interest Probability: A Case Study
Sofia Charalampidou, Apostolos Ampatzoglou, Alexandros Chatzigeorgiou, and Paris Avgeriou
An Investigation of Technical Debt in Automated Production Systems
Terese Besker, Antonio Martini, Jan Bosch, and Matthias Tichy
The Magnificent Seven: Towards a Systematic Estimation of the Technical Debt Interest
Antonio Martini and Jan Bosch
Towards Triaging Code-Smell Candidates Based on Scenarios and Method-Call Dependencies
Thorsten Haendler, Stefan Sobernig, and Mark Strembeck
Technical Debt Interest Assessment: From Issues to Project
Antonio Martini, Simon Vajda, Mohamed Abdelrazek, Allan Jones, Rajesh Vasa, John Grundy, and Jan Bosch
It's becoming clearer and clearer that a new perception and practice of leadership is required to unlock the potential of corporate and business agility. The reason is that Agile, with its implications of open collaboration, shared responsibility, collective intelligence and complexity mindset is a profound game-changer for most organizational cultures.
While being a manager is an appointed position with clearly defined responsibilities and powers, being a leader is a much more elusive concept -- and one that is often still influenced by mental models and assumptions that don't really fit in an Agile environment. Still, leaders play a critical role in initiating, supporting and evolving virtuous team and corporate dynamics that become the real asset of an Agile organization.
In this interactive, collaborative workshop we are going to explore the meaning of Agile leadership, and what an Agile leader is and does to foster desirable behaviors in an Agile organization. We will explore this role from the perspective of complexity thinking, since Agile leadership is inherently systemic; and we will explore the personal, individual skills that makes an Agile leader effective in the context he/she operates -- including, but not limited to, the ability to create trust, to take personal responsibility and to operate from an egoless perspective.
The contents are influenced, among the others, by works on: complexity by Dave Snowden (Cynefin framework); intrinsic motivation by Daniel Pink et al.; personal responsibility by Christopher Avery (The Personal Responsibility Process); management 3.0 by Jurgen Appelo. All these are integrated in the facilitator's own experience and perspective in evolving organizations in his role as Enterprise Agile and Executive Coach.
The workshop is designed for Agile team members, leaders, managers, executives, coaches and for all the Scrum roles.
Agile has become a kind of commodity. Almost all companies – also from industry sectors, that did traditionally not have a high affinity to agility – have started to move.
During the past 1-2 years we can observe how agile is more and more industrialized via well-defined ways-of-working frameworks. A side-effect of this is, that these mostly address process and structural aspects while the mindset part of agility doesn’t have the same level of focus. This has triggered quite some debates, one of them being a panel discussion at Agile Europe 2016 and an infoQ interview at Agile 2016 with Steve Denning and representatives from several companies and consultants.
Also the Agile Alliance’s “Supporting Agile Adoption” initiative was part of these events and is dealing with this phenomenon.
In this workshop several members of this Agile Alliance initiative are looking for your experiences and insights to discuss and work with you on how we could help companies focussing on the necessary agile mindset shift.
We will together identify thepatterns behind (potentially) successful approaches. We will summarize the result and publish it via the Agile Alliance. So this is your chance to share your insights to this area and help advancing the agile mindset adoption across the industry.
The word architecture only makes a single appearance in the 12 Principles behind the Agile Manifesto and does not appear in the Agile Manifesto itself. It is, therefore, unsurprising that agile methodologies like Scrum and Kanban do not focus on technical practices. Even Extreme Programming, probably the most well-known agile methodology focused on technical practices, does not explicitly address the topic of architecture.
Without an explicit reminder about architecture, many agile teams fail to address important architectural concerns. Many agile teams struggle to evolve a codebase that was quickly built up over many short iterations and increments without an explicit focus on architectural concerns.
In this tutorial, we will explore important "architectural practices" that align with the agile values - collaboration, fast feedback and value all in the context of exploring architectural concerns.
Participants are expected to have a technical background designing and developing software, although no code will be written during this session. Instead, participants will work in small groups to practice architectural thinking to a case study where activities include:
You may have seen this: A company decided to become agile and introduced an agile framework e.g. Scrum. The management hopes for higher product quality, a better TTM (Time To Market), an improved risk management, finally a project that is on time and budget and more. Although they implemented Scrum by the book, after about half a year, they realize, that none of the promises came true. The Scrum Master is searching desperately for another, a better tool he can try next, but none of them has the desired effect. Step by step the team is falling back into their old habits, and in the end, they say: Scrum does not work. And they are right! Only by putting a new shiny saddle on your dead horse, you won’t get it running again.
It doesn’t help to copy a process from a successful team blindly and to hope it will work in your context. What you really need, is a passionate team. A team that can deliver, even if their environment isn’t the best. But what do you need to get such a passionate team?
In this workshop, I'll show you how to assess your current teams based on the PASSION model and derive the next steps based on the outcome. The PASSION model is a team development model that helps you to identify the road blocks, which hinder your team to become passionate. At the end of the workshop, you can add some new tools to your toolbox and use the immediately, when you are back at work.
Why is our software industry vastly adopting Feature Branching ? "To isolate the work of the developer so he can be more productive" I was told. But does it really make your team more productive ? Are the projected benefits worth the problems it introduces ?
Feature Branching became mainstream in most IT organisations because proponents of DVCSs mostly rely on Feature Branching to sell DVCS. And probably also because of the success of GitFlow ...
But like all powerful tools, there are many ways you can use DVCSs, and not all of them are good. Feature Branching is definitely not a good way to use them. Although branch creation is easy, this does not mean cheap in the long run. It comes with a certain cost, certainly in the context of Continuous Integration and Continuous Delivery.
Amongst others, one of the biggest problems, is that it breaks the early feedback cycle of Continuous Integration. As long as the Feature Branch is not merged back into main line, the feature is not integrated into the application.
The evilness lies not much in the problems introduced by Feature Branching, but rather in the reasons teams are using them.
During this session we will explore the reasons for using Feature Branches, what is wrong about Feature Branching and what techniques you can use to avoid them all together.
The target audience for this session are software engineers, technical team leaders, architects, and anyone using version control systems in a Continuous Integration and Delivery context.
Software development is full of waste. I have constant anxiety that I'm investing my time and energy into the wrong design. And I don’t think I’m the only one. So what processes could reduce that waste? Through validated learning, Lean methodologies have helped reduce waste in manufacturing and product development. Maybe Lean can help software engineers too.
Lean Startup has a lot in common with Extreme Programming. They have very similar philosophies on value, waste, and responding to change. Of course, XP focuses more on engineering, while Lean Startup focuses more on product management. A bigger difference is that XP emphasized emotions, while Lean Startup emphasizes numbers. After exploring the combination, I’m convinced that bringing XP and Lean Startup together leads to sustainable innovation for software design.
XP is a disciplined form of agile software development. Lean Startup is even more disciplined and goal-oriented. The heart of Lean is build-measure-learn experiments. We want to find out as early as possible whether we are going in the wrong direction. If we are, then we pivot. XP engineers can apply Lean by transforming the red-green-refactor cycle into a build-measure-learn cycle. We can think of our designs as hypotheses and our stories as users.
In order to foster good software design, XP needs the goal-oriented discipline of Lean. Kent Beck’s advice to “make the change easy, then make the easy change” is validated learning via pain. We don’t all experience pain the same way, though. In order to coordinate our design efforts, we need a shared understanding of “the easy change.” Once we have a clear goal, different opinions on how to get there become opportunities to learn. By experimenting and measuring the outcomes we can continuously improve our designs.
This talk explores one way to apply Lean principles to XP. I will share my experiences and the challenges I have encountered. I want the audience to come away from this talk eager to find new ways of blending the humanity of XP with the rigorousness of Lean.
The problem: Your team is made up of people from different national cultures, and getting to know and trust each other is a slow process. Whether your team is working in the same office or across an ocean, your progress is in jeopardy unless real collaboration starts happening soon. You're concerned that stereotyping and other negative feelings will grow as schedule pressures increase unless you can find a practical, simple idea that you can use to help individuals "build bridges" across to each other.
In this session we will start with a brief overview of 5 dimensions of national cultures as presented in the book "Cultures andOrganizations" by Geert Hofstede and Gert Jan Hofstede. The book quantifies cultural attitudes based on five cultural
axes, namely:
1. Power Distance
2. Individualism
3. Masculinity-Femininity
4. Uncertainty Avoidance
5. Long / Short Term Orientation
Here are a few examples of how cultural differences might affect an agile team:
Someone from a highly individualistic culture might want to build their skills far above the others, not taking time to bring others along. They see this as standing out as a leader. A team-mate from a more collectivist culture may see it as self-centered showing off.
Someone from a high power distance culture does not want to voice opinions in estimation sessions until they know their manager’s opinion on the topic because to be in disagreement with their manager is disrespectful, no matter who is right.
We'll take each cultural axis in turn (as time allows), and you'll find out where your culture ranks, and with a pair you'll explore how to handle an important Agile team communication topic. Even if all cultural axes cannot be covered, you'll have enough understanding to use Hofstede's book to do further explorations.
Our own culture can contribute to problems if we are unaware of how it affects our behavior, and of how our behaviors are perceived by others. Cultural diversity in a team can be trouble just waiting to be triggered, or it can be a real strength. The difference is simply awareness and readiness to make adjustments.
Most of the key aspects of the Scrum framework are regularly discussed during Agile conferences. For good reasons. There’s indeed much to say about effective Retrospectives, dos and don’ts of the Sprint Planning or the good practices of backlog refinement. Although the Scrum Framework has been introduced many years ago and organizations use the framework for a long time, we realize that we should continue learning in order to understand the essence of it.
The Sprint Review seems to be an exception. During conferences this event usually gets less attention than for instance the Sprint Retrospectives. Has the Sprint Review become such a routine in most organizations that we don’t need to talk about it anymore? Or do we consider this event as less important, resulting in a shifted focus to other subjects?
To be honest: none of the statements seem to be true. The events of the Scrum framework all have their own specific purposes, but they are equally important to achieve optimal results. There are still many organizations where we see suboptimal interpretations of the Sprint Review. We should not stop learning about Sprint Reviews. It’s about time to put the subject back on the radar!
In this workshop Nienke Alma will explore the subject together with you. Let's come up with a "definition of awesome" for Sprint Reviews and compare this definition with the reality of the Sprint Reviews currently done by your Scrum Teams. How do your Sprint Reviews score? What can you do tomorrow to close the gap?
Don't expect any slides. This interactive workshop will encourage continuous sharing of experiences and a good discussion.
Peter den Heijer, Wibo Koole and Christoph Johann Stettina
Anh Nguyen-Duc, Xiaofeng Wang and Pekka Abrahamsson
The daily stand-up meeting is a widely used practice. However, what is more uncertain is how valuable the practice is to team members. We invited professional developers of a programming forum to a survey and obtained 221 responses. Results show that the daily stand-up meeting was used by 87% of those who employ agile methods. We found that even though the respondents on average were neutral towards the practice, the majority were either positive or negative. Junior developers were most positive and senior developers and members of large teams most negative. We argue that the value of the practice should be evaluated according to the team needs. Further, more work is needed to understand why senior developers do not perceive the meetings as valuable and how to apply the practice in large teams.
Viktoria Stray, Nils Brede Moe and Gunnar Bergersen
There is a lot of focus on software craftsmanship and automation. We can build and deploy software very quickly with current technologies. However, it’s the post-deployment stage that worries me. How can we be sure that this new functionality has the impact the business needs? In other words: are we building the things right or are we building the right things? We think you can do both with continuous business goal validation.
When making software products we made a lot of assumptions about how functionality will help us in reaching business goals. But we rarely see those assumptions being validated afterwards. We mainly run back to the backlog and start on the next feature.
We found out that there is much overlay with impact mapping. In a sense continuous business goal validation is the automation of impact mapping. Where impact mapping is a great way to define products, business goal makes sure your assumptions are being validated. Not once, but as long as the functionality is alive.
By measuring those assumptions, not only once after going live but automated and over time, when the software is being used we can really learn a lot. Do users really use this functionality as expected? Did this new feature affect the usage of an older one? In short: did we make the right assumptions? This way you can keep your product as small as possible but most effective. Remove or change functionality and keep waste to a minimum.
This is what we call continuous business goal validation…or is it validated learning?
How to:
While setting up projects or define features in ongoing customer relations setting up impact maps and/or business canvas models are a great way to have a concise view on what the expectations of the software are. This should be the start of any phase and should be done in a cooperation between business and IT or customer and supplier depending on the situation. Afterwards it is clear which problems we are going to solve for who and not the least: what are the goals we want to reach?
Business goal validation then makes it possible for a product owner to clearly communicate with stakeholders about the business goals and the results of the validation. “Yes we assumed together that the effect of this was X but we found out that this assumption was wrong. Let’s find out why and get it right”. It clearly helps the stakeholders and the product owner to define the right functionality and validate these continuously instead of detailed discussions about functionality.
We will explain how to go from inception, objectives (input-output) and outcomes and validate if goals are reached. Which choices are there to be made if a measurement fails or passes? We will show that this is an ongoing process where customers and suppliers continuously validate if they are really building the right things right.
Everybody wants to be a Scaled Up Lean Startup Enterprise nowadays. But do you have what it takes to be on the edge? And should you even be trying?
At every conference you hear many great ideas. And you would probably like to implement some of them back at work. And yet, is this really the right moment? And have you considered if the rest of the organisation can keep up? Or even wants to?
In this talk we present a way to navigate the different practices available from the Agile community. Inspired by the Agile Fluency™ Model, we show you how to start with the issues you face today, find the direction you’re aiming for, and identify the Agile practices that will help you get there.
In practical terms, we’ll describe the kinds of situations, problems and issues that can be encountered, discuss what different reactions can be depending on the stage of fluency we’re aiming at, and what practices and skills might help progressing from there.
Test automation projects can have a bad tendency to go awry, most especially when higher-level automation (e.g. via the UI) is involved. At some point, automated tests just become too hard to understand, extend and maintain.
This doesn’t have to be the case though. In software development, there are systematic methods and patterns for addressing recurring challenges – and similar approaches also exist for test automation.
In this talk, I’ll first go on a short rant about all that is wrongly understood or implemented in UI testing, then I’ll present a structured, systematic and tool-independent approach for automating UI tests. The approach and the patterns that result from it haven’t simply been invented from scratch, rather they build on and expand patterns and methodologies well-known from software development and web-testing for example.
During the talk, I’ll show examples to illustrate the structures I describe. Anyone involved in automating tests (whether they are programmers or not) can profit from learning and applying these patterns in their teams.Task allocation is considered to be an important activity in project management, independent of the method used for software development. However, the process of allocating tasks in agile software development teams has not been a focus of empirical research. This research used case study research method and involved semi-structured interviews with 12 agile software practitioners working within a software development organization in India. The results explain the process of task allocation including four different mechanisms of workflow across teams: team independent, team dependent, skillset/module dependent and hybrid workflow. These include some common set of practices whereas others are team-specific factors. Furthermore, five different types of task allocation strategies were identified based on increasing levels of team and individual autonomy: individual-driven, manager-driven, team-driven, manager assisted and team assisted. Knowing these workflow mechanisms and task allocation strategies will help software teams and project managers to make effective distribution and allocation of tasks for smooth agile software development. Future research can suggest alternative methods to overcome the hurdles faced by agile teams during allocation of tasks.
Zainab Masood, Rashina Hoda and Kelly Blincoe
Agile: Succeeding or Regressing? Are We Learning as a Profession?
Steven Fraser – Panel Impresario
Software development practices have evolved over the past 70 years beginning with the first stored computer program which ran on “The Manchester Baby”. Since then a variety of approaches to industrial-scale software development by teams of professionals have emerged. In 1970, Royce advocated the creation of software products with a disciplined engineering “Waterfall” process. This evolved to “Structured Design” (Yourdon, 1979) and “Object Oriented Design” practices (Booch, 1982) – which lead to the emergence of iterative “Agile” processes with publication of the “Agile Manifesto” in 2001.
Over the years, David Parnas, Steve McConnell, Bertrand Meyer, and others have discussed the evolution of software as a profession – and more recently, Agile has become the target of critical analysis. For example, see Dave (Pragmatic) Thomas’s presentation on the “Death of Agile” (viewable on YouTube).
This panel will discuss whether agile is succeeding or regressing – and what metrics should be used to assess progress (in either direction).
Andrea Goulet
Before we can answer if we're succeeding, we need to first ask ourselves that all-important question: What does success look like? If we're judging success based on adoption and awareness, there's little doubt that we've succeeded. It seems that nearly every company that builds software, from small startups to large enterprises, is familiar with the term. Agile has even made its way into pop culture. I laughed so hard when a character on HBO's sitcom Silicon Valley whipped out a ready-made Scrum board that he kept on hand to motivate his development team.
Of course, there are always areas for opportunity and growth, too. I see so many teams who are struggling and as a curious observer, I like to figure out what the challenge is. To me, I see three key areas where we can improve.
Avraham Poupko
In many areas we are certainly succeeding. We are able to create very complex systems and have fun while doing so. However there have been quite a few regressions along the way, some of them devastating.
Part of our regression can be attributed to the capitalization of the word “Agile”. Once agile became a “thing” we started evaluating software and process by how Agile it is and not by how agile it is. In other words, we sometimes evaluate ourselves based on conformance and not based on performance. Are we learning as a profession? A resounding yes. Are we learning the right things, and are we learning as fast as we can. Not always. But we are an open minded community interested in improving itself, so there is cause to believe that over time we will improve.
Andrea Provaglio
From my perspective, we are succeeding with agility and stagnating with Agile. What we call Agile today has evolved from what it was 16 years ago when the Manifesto was published. The fundamental values and principles are still valid, but they are now reaching a wider audience and what we see today are different approaches to “doing Agile" rather than “being Agile” — the latter being a mindset to operate in complexity. With the evolution of Agile “methods”, came also confusion and a dilution the original term (probably inevitable when something goes mainstream). Which is why I believe that for us, long-standing practitioners, one of the responsibilities is to help clarify what agility is to those who approach it.
Silvana Wasitova
The short answer is succeeding, but that is not the whole picture. The more interesting questions are: how are we succeeding, how fast, and is agile the silver bullet. Startups are inherently more aligned with agile, but what about the established companies? The reality is that transition to agile is still laborious process for many, and at times painfully pits old habits and entrenched processes against the agile philosophy and values. This is an area that agile does not address: how to transition, how to adapt and adopt. More specifically, when established players fear they have something to lose, then agile is not very attractive. This is the area where more work still needs to be done, even today, 16 years after the Agile Manifesto was coined.
Claes Wohlin
In my view, it is not really about agile succeeding or regressing! It is about our ability to engineer software, and hence it is not about plan-driven development versus more lightweight development. There is far too much focus on specific approaches, methods and tools; we should take a step back and look at the big picture. The key questions are more related to the second question in the title of the panel, i.e. “Are we learning as a profession?” And even more importantly, how can we ensure that we learn as a profession? If not learning, are we even a profession?
The inception of agile and lean has been very important, since they have helped resurrecting the importance of the human aspects in software development. Furthermore, the focus on working code and customer involvement is very important. However, agile or lean is not a panacea for software development. So, what can we learn from the evolution of software engineering? After all, we turn 50 years in 2018.
In my opinion, the success of engineering software depends on our ability to manage our intellectual capital. We must understand the needs for succeeding with a task, a project or any development activity resulting in a system, product or service. Plan-driven development is mostly focused on the organizational capital, while agile development is more focused on the human capital and the social capital. However, success is about an appropriate balance between the different types of capitals. How do we balance human, social and organizational capital in a specific situation to succeed? This is in my view the key question we need to address for the future.
After wasting £12 billion on the biggest IT failure ever seen, and constantly disappointing UK citizens with huge overspends on extremely poor digital services, every aspect of UK government IT was in desperate need of fundamental transformation.
At this huge government scale, digital & agile transformations can be successful. But a system's bias for reverting to what it knows - manifested as resistance to change from those in power - is the biggest danger.
GDS - Government Digital Service - came to the rescue of UK government IT over 5 years ago and are now facing those very challenges. They implemented a culture of user-first, agile software development across government, resulting in world-leading digital services whilst saving millions in taxpayer money. Astonishingly, they put public sector software development on a path to reach the levels of Amazon, Netflix, et. al.
Governments all around the world are now copying the GDS model which involves creating a "one government" user experience, enabling a fundamental transformation of the relationship between citizen and state. An approach that relies on assessments to enforce adequate user research is carried out and to verify teams are working in small cross-functional teams striving for continuous delivery.
But GDS always faced constant resistance from senior executives and IT leaders who didn't want to transform - who wanted to stick to old habits of waterfall software development, huge outsourcing contracts, and big enterprise software. Factions started to build up around these two schools of thought. The new "digital" teams who open sourced all the code and wanted to talk openly (blogs, conferences) with UK citizens vs the old "IT" teams who wanted to maintain the status quo of closed-sourced and hidden away.
Despite all of GDS' success, a lot of their work is now being undone as these anti-change IT leaders start to claw back power and reverse the GDS improvements. So strong is the uprising, there has been a mass exit from GDS of the key influencers, including those at the very top who fear an end to the progress.
Governments and organisations of all sizes aspiring to carry out transformation should take careful note of these key lessons.
The role of test automation in Agile Software Development projects is of paramount importance. It is absolutely necessary to automate tests in agile development projects as the number of test cases will continue to grow with each successive sprint. Through a Grounded Theory study involving 38 agile practitioners from 18 different software organizations in India, we identified five key challenges faced by agile practitioners and different strategies to overcome those challenges while practicing test automation. Understanding these challenges and strategies would help agile teams in streamlining their test automation practices.
Sulabh Tyagi, Dr. Ritu Sibal and Dr. Bharti Suri
How about creating a definition of your engineering approach to share good practice & enable engineer collaboration (using Kotter and also an anti-fragile approach to knowledge - encourage challenge). The business customer needs us to be responsive, disruptive, reliable and professional - call it an "iron square" of the industry today. Our engineers need to be able to tap into knowledge & support networks instantly. This is important for any engineering department in a large company - do you know what your value-proposition is?
Engineering also have significant Cloud Challenges - microServices, polyglot, emergent architecture, 12 factor, Cloud First, build to scale..etc... Things are moving fast.
The LIT.method is our approach (which can be replicated) and we have been inspired by some of the HSD & Cynefin approaches to balance alignment and autonomy. The perfect pull system for a 500+ person organization.
The grass-roots Roll-out was via openSpace, lean coffee & conversation. We made a conscious decision to flip top-down comms and practice radical transparency.
FINAL STATEWe build for end-Customer Impact & align with the internal-Customer, but need to retain XP discipline - Customer focus & collaboration is everything. We decided to make it real and share real experience, not theory or abstracts (with a solid system of principles as a foundation). We found that working engineers don't need high-brow principles or theory, just techniques and experience they can use today. The LIT.method() is the way we have accelerated collaboration with a clear goal of "internal-customer" satisfaction (via a high standard of engineering).
We did not use any scaling frameworks (but we inter-operate with several), we have real business on the line so have been very pragmatic, we are presenting real results, metrics & experiences. We have used Hypothesis & Product thinking to inform our approach (which has taken many turns).
Are you tired of hunting down bugs in your code? Honestly, why are you still doing this instead of simply writing code, that has zero bugs, all the time?
Meet Elm, a purely functional programming language that compiles to JavaScript. One of the most interesting properties of the language is a very strong guarantee: The compiled code will have no runtime errors at all!
With this, you can finally have a code base that is verifiably free of defects. Large refactorings are no longer scary with this level of confidence, which benefits the long term maintainability and adaptability.
However, this talk is not only about Elm: We will take a close look at Elm's high level concepts in a broader scope, that is, stateless functions, immutable values, unidirectional data flow and Elm's architectural model for applications. We will then discuss how these concepts make it easy to write high quality code consistently, and how these benefits can be translated to other programming languages as well.
A software team and the company need to be organized in a way that enables quick response to change, as the Agile Manifesto requests. To prepare for quick change, a company has to implement self-organization throughout. Yet, many agile teams suffer from the mismatch of agile and organizational leadership, with the latter being reflected by the organizational hierarchy. Operating with self-organization and iterative processes, the agile teams run into trouble with a more rigid top-down steering of their environment. Consequently, agile proponents very often believe that a supportive agile organization should be structured without hierarchies, the so called “no managers” approach of “reinvented organizations.” Several companies in the agile field are experimenting with different organizational approaches that don’t use hierarchies. Yet, “no hierarchy” or “no managers” is not an option for many organizations.
In this session we suggest supplementing Agile with sociocracy as a way to prepare for change that leaves the hierarchies in place. Sociocracy shows how hierarchies can actually be agile and can strongly support (rather than opposing) needed change. It enables managers to become agile leaders. As a participant you will learn how the principles of shared decision making and double-linking are key to enabling self-organization. These principles convert hierarchies from linear to circular so that they support an agile mindset.
Sociocracy is a way for groups and organizations to self-organize. Based on four principles (self-organizing teams, shared decision making based on consent, double-linking, and electing people by consent to functions and tasks), sociocracy provides a path for existing organizations to have empowerment and self-responsibility on all levels. Different than comparable methods, sociocracy allows companies to start where they are – with their existing organizational structures and the like. It seems to be a perfect fit for organizations that need to be truly agile (due to market pressure) and be able to respond company-wide to change. By coordinating everyone, when change happens there is an harmonious shift by all departments of the organization not a sudden conflict among them just at the moment when a fast change is needed.
Shhhhhhh! Challenge what you think collaboration is.
Join the very first workshop that kicks off the “Inclusion Collaboration” campaign founded by Sal & Katherine to promote, embrace and celebrate neurodiversity in tech.
Collaboration isn’t limited to loud, pushy, fast and extroverted. We aren’t all the same. We lose a lot by limiting ourselves to one way of working together and often unintentionally exclude amazing people with important viewpoints and vital data.
In a community of taking things to the ‘extreme’, Sal and Katherine push the limits by exploring absolutely silent collaboration. How effective can we be? What could we learn? What powerful takeaways could you get? How might it change the way you collaborate tomorrow?
This workshop will be like no other. You will:
• Help the third world in a very meaningful, practical way and non-trivial way
• Learn about how awesome (and easy) it is to embrace neurodiversity
• Experience eastern philosophical ways of generating collaborative quiet wisdom
• Participate in the Inclusion Collaboration campaign - raising awareness of supporting neurodiversity in tech
This workshop is about being different, doing things differently and absolutely loving it. We hope you take that to work and spread it far and wide.
Davide Taibi, Valentina Lenarduzzi, Andrea Janes, Kari Liukkunen and Muhammad Ovais Ahmad
Daniela S. Cruzes, Michael Felderer, Tosin Daniel Oyetoyan, Matthias Gander and Irdin Pekaric
Aligning organisational and technical boundaries with the organic boundaries of a problem domain to create autonomous teams enables organisations to innovate faster by making decisions faster, implementing ideas faster, and getting customer feedback faster. Guided by the strategic principles of Domain-Driven Design, software developers can play a key role in leading the transformation of their organisation towards greater autonomy.
Instead of naively chopping up a system into arbitrary small pieces and calling them ‘microservices that implement bounded contexts’, or merely thinking cross-functional teams will suffice, deeper - more nuanced design skills are needed. All domains are different - there is no flowchart that guides teams into knowing exactly how to break up a large system into smaller pieces that minimise the costs of handovers and shared dependencies.
Strategic Domain-Driven Design introduced the concept of subdomains; things that change together for business reasons. Accordingly, teams that own things that change together for business reasons will own more decision making and have more autonomy.
Traditionally, Domain-Driven Design has encouraged use of language as a way to identify the boundaries between things that change together. Whilst language is still a key heuristic, there are many others, in particular the flow of work through an organisation. Subsequently, by supplementing the design of teams and services with the the goal of eliminating bottlenecks in an organisation, Theory of Constraints provides a powerful mindset for determining good microservice and team boundaries.
A lot has been written and said about the added value of feature teams. Feature teams reduce the complexity and waste of external dependencies, have more focus on delivering real customer value and bring more autonomy to the people involved in the delivery of the product every single day at work. Organizations aiming to reach true Agility in the market better transform their component teams to feature teams soon!
It’s all easier said than done though; especially for the organizations that were around way before the Agile era. ING Bank is one of those organizations where most teams were built around components for many years. But ING Bank is also an organization that understands the necessity of being able to respond fast to the demands of the customer and has therefore progressed in the transformation of their old way of working to an Agile way of working. Forming feature teams, including business and IT, is an important challenge and step in this transformation.
Where do you start if you would like to transform existing component teams into effective feature teams while keeping the ship afloat? What steps do you need to take and who do you involve at specific parts in this process? Do we actually see improvements in the current status yet?
Maurice van Wijk and Nienke Alma, Agile Coaches at ING Bank, have been closely involved in a challenging, but also inspiring journey from component teams to feature teams. The road from preparations, how to get all parties on board, the needed steps and sessions ending in self-selections and kick-off of newly rising feature teams. In this presentation they will explain what approach they have followed and share their experiences. You will explore together with them what worked well and may work for you, what could be done differently in the next journey, and their next steps.
Picture the scene. You've joined a new team that work on the most important product in the company. There's just one catch. The code base is using 2002 technology and the attitude has been "get it done" since then.
Things need to change fast. To reduce the amount of work in process you adopt mob programming - where the whole team work on only one task together on one computer - and start creating a culture of safety over fear. Things start to feel better but you can't help but feel that your being distracted from your goal.
In this case study you will learn about how a team can go from individuals to a mob. You'll also hear how the most powerful improvement tool the team found was to use Lego to represent time spent. After this you'll know about mob programming, making problems visual with Lego and how that combination doubled the productivity for this team in six months.
Jevgenija Pantiuchina, Marco Mondini, Dron Khanna, Xiaofeng Wang and Pekka Abrahamsson
Technical Debt is a metaphor that has, in recent years, helped developers to think about and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. We conducted an empirical study in an academic environment, nine teams of graduate and undergraduate students during two offerings of a laboratory course on Extreme Programming (XP Lab). The teams had a comprehensive lecture about several alternative ways to identify and manage Technical Debt. We monitored the teams, performed interviews, did close observations and collected feedbacks. The results show that awareness of Technical Debt influences team behavior. Team members report about thinking and discussing more about software quality after becoming aware of Technical Debt in their projects.
Graziela Simone Tonin, Alfredo Goldman, Carolyn Seaman and Diogo Pina
Metrics are useful tools, yet dangerous. Measuring the wrong thing can steer us in the wrong direction without us even noticing. And even the right metric can cause stagnation when we need to progress to the next challenge.
Inspired by the Agile Fluency™ Model, in his talk we discuss how the stage of fluency determines what types of metrics you should focus on. And how we need to change that focus as we progress to a different stage.
We’ll discuss how you can start with the basic metrics from Scrum or Kanban, such as velocity and cycle time. Then you can progress through to the type of delivery focused metrics from Continuous Delivery. Finally, we arrive at business focused metrics appropriate for product teams.
Diversity is great, right? The more the better. That is what we are of tought.
However, does diversity really deliver on its promise? Is there such a thing as too much diversity? Can diversity sometimes become an objective on it's own? Do we sometime sacrifice other important outcomes on the alter of diversity?
Futhermore, diversity is supposed to be a good thing. It is a value that we should all adopt, right? However, isn't a common culture the 'glue' that holds the team together? Is that the opposite of diversity?
This talk is an attempt to give an honest look at these questions, and provide answers and insights rom my own experience.
I explore the limits of diversity. When is diversity good, and when get it be detrimental.
Over the years I have tried to build teams that are diverse enough to avoid the groupthink trap, yet able to work together towards achieving a common goal. Sometimes I succeed, sometimes I failed, but I always learned something.
As a senior technical architect at Cisco that leads a team of software architects, I will draw on my professional experience to offer insights on the benefits of diversity, the traps of groupthink as well as value and challenges of working with technical teams across the world. I will discuss the Agile approaches which helped to achieve the goals effectively and those that did not work quite so well.
I will start the report by asking some questions, followed by a discussion of how they are answered within the organization I work for. For example, what is the main driving force behind the goal to create diverse teams? How many faces does diversity have? Lack of gender diversity in technology space is a well-known issue, cultural diversity is targeted by many other professional fields. But is it really all we look for? How about diversity of skills, mindsets, social experiences, attitudes?
I will make the connection between diversity in teams and diversity in agile processes, looking at interactions, challenges and dynamics in varied and conforming teams.
You might not agree with everything I have to say. That's fine. Hopefully you will be provoked into giving some deep and honest thought of these issues.
Agile: Cult or Culture?
Steven Fraser – Panel Impresario
Cults are small communities of individuals with a shared devotion to a person, idea, or thing – particularly when such devotion clashes with the beliefs of others. In the context of emergent technology, a cult might be seen as an early phase in the adoption of a new practice with new shared norms and beliefs – ideas that are not yet in the mainstream but over time may gain widespread acceptance.
A culture is generally viewed as an achieved state of civilization with stable norms, beliefs, traditions, and practices that have been widely adopted (and accepted).
This panel will discuss whether agile ideas, practices, norms and beliefs have achieved sufficient momentum to evolve from cult of limited influence to a widely adopted culture. Our discussion may touch on both the scale and scope of agile adoption as well as the degree of diminishing (growing) “ideological fragmentation” of agile values and practices.
Sallyann Freudenberg
Fourteen years or so ago, when I first encountered ‘agile’ the part that really appealed to me, the bit I loved the most, was the cultural transformation. I saw an evolution from an almost silent, stark, cubicled workplace where people communicated via written documents and email – to vibrant, open spaces full of life and conversation. Where plans went from being a Gantt chart hidden away in a manager’s PC to a living, collectively owned representation on a wall. I would ask people how their work was different now and they would say things like “we know each other’s names” and “people look up and say good morning to each other now”. It all felt so much more…human.
It is only in the last couple of years that I have come to realize that this pendulum swing has actually just replaced one mono-culture with another. The tech workplace has gone from one favoring introversion, solitary work and quiet careful thinking to one (perhaps inadvertently) designed for fast-thinking, extroverted verbalizers. In truth we have (and need) all kinds of thinkers on our teams. Whilst highly collaborative working practices work well for some, they disadvantage others. I see and speak to people all the time whose gifts and contributions are passed by or their brilliance stifled by the accommodations they have to make to fit in to the environments we have created. If we are to create truly innovative products and solve the very trickiest of problems we need all kinds of minds. So cult or culture? I feel like the culture has itself become the cult. One of our next big challenges as an industry is to understand how to support and leverage the different brains we have. Our diversity can become our competitive advantage if we can make our collaborations truly inclusive.
Diana Larsen
Agile-as-a-culture began when the groups of people representing different “lightweight” methodologies met over several meetings in 1999-2001 and, ultimately seventeen of them wrote and signed the Agile Manifesto. They looked for the commonalities among their approaches to create the Agile umbrella.
Almost immediately after, the schisms began as the groups that supported the different methodologies began promoting their “agile” as the right and best agile. As disciples climbed aboard we saw agile-as-a-cult emerge. We heard about “religious” wars, cargo cults, and “are you doing or being agile?” We heard much less about the joy of working together in discovery and how the teams that embraced these more productive, humane, and sustainable approaches to work created the best jobs ever for many team members. We heard high flying promises of high performing teams, but these promises were brought to earth with a thump as stories of “fragile,” “agile is dead”, and scaling-to-fit-our-existing-bureaucracy took center stage.
Personally, I took refuge in the ideas of fluently agile teams, refocusing on creating teams of learners in productive, humane, sustainable workplaces. Looking toward agile that is neither cult nor culture, but a means to realizing the organization design principle of jointly optimizing the social, technical, and environmental systems.
Ken Power
Though I’m wary of labels, agile-as-a-cult has some implications that the teams and organizations in question are leaning towards a dogmatic, and perhaps poorly-informed, approach to agile. Agile-as-a-culture, on the other hand, has some implications that the teams and organizations in question are actively thinking about what it means to be a more agile organization, and actively embrace learning, experimentation, and continuous improvement. How do we tell the difference?
For the purpose of this panel, I will use four indicators that help distinguish agile-as-a-cult organizations from agile-as-a-culture organizations. The first indicator is the frequency of usage of the word “agile”. In recent years I have noticed an inverse correlation between the amount of times a group will use the word “agile”, and how agile they actually are. Agile-as-a-cult organizations start to label everything as agile-this, and agile-that, and create or hire “agile experts” to be the keepers of the definition. Agile-as-a-culture organizations get on with the business of delivering amazing products and services to their customers, and inherently focus on being agile to help them succeed. The second indicator is grammatical usage of the word “agile”. Agile-as-a-cult organizations use “agile” as a noun; agile-as-a-culture organizations use agile as a verb. This is summed up in the difference between doing agile versus being agile. The third indicator is attitude to learning and experimentation. Recall the often-overlooked phrase in the agile manifesto – “we are uncovering better ways of developing software …” Agile-as-a-cult organizations want to quickly standardize everything, create playbooks that tell people what to do, and roll out “best practices”. Agile-as-a-culture organizations embody an approach to discovery, experimentation, adaptation, and continuous learning to improve conditions for people in their organization and how they deliver value to customers. The fourth indicator is the metaphors people use to describe their people and development process. Agile-as-a-cult organizations use metaphors that emphasize a desire for repetition and speed, such as factories, machines, or race cars. Agile-as-a-culture organizations use metaphors that emphasize growth, evolution, and emergence, such as gardening, driving, or ecosystems.
Patrick Kua
As an individual, I see agile mostly as culture – living with an agile culture means adopting its values, and principles and drawing on different practices to best suit the situation. An important facet of this culture is the relentless focus on continuous improvement which means adapting practices, and sometimes inventing new approaches. Adaptation and new practices often means stepping away from the norm.
As a consultant, I see many companies and communities suffer from agile-as-a-cult. Their focus explicitly means drawing boundaries about what is, and what is not, allowed according to their rules of the cult they identify with. Strict and non-negotiable boundaries constrain those innovators who truly adopt the agile culture. Companies and communities that adopt agile-as-a-cult prevent themselves from being truly agile.
Nancy Van Schooenderwoert
Agile is not a cult - but that hardly matters if you are one of the people who has been steered away from Agile (maybe forever) by behaviors that refuse to deal honestly with problems around the use or introduction of Agile methods. I see 3 common situations that lead to a perception that Agile is a cult:
Each of these has the effect of being too one-way; of not being open to all the effects that the process changes are having. It is a steam-roller pattern when what we need is a pattern that truly invites teams to bring their expertise and to continuously shape the rules they will operate by. This has to be based on experimentation and honesty - on the scientific method. The rules of Scrum and even the Agile Manifesto are merely a starting point, not an article of faith.
Credentialing has its place but 14 years of certification mania has taken a toll on the Agile movement. It’s time to balance that with real inquiry, experimentation, and peer review because Agile is not a finished static thing. We need to build a culture of exploration and listening.
...In the context of bigger systems classic emergent design can result in losing a lot of time by letting similar responsibilities emerge again and again. In contrast the London School of TDD works Outside-In using mocks. It shines whenever the objects' responsibilities are quite clear upfront. An alternative I’ve developed over the last year is "Fake It Outside-In TDD". Instead of mocks fake data originating from the test assertion become your primary design driver. On an incremental destructuring journey down the call stack the data morphs more and more into structure. Design therefore develops "Outside-In" but on a "green bar" in the refactoring phase as opposed to London Style on a "red bar" when writing your tests. The remaining real "logic" is tackled with regular unit-test level TDD. The approach hits the sweet spot
The session starts by explaining the different TDD approaches including the "Fake It Outside-In" variant. In a mob-programming session we then try out the new approach, followed by a discussion of our observations and opinions regarding the approach. The session ends with a comparison of the respective TDD approaches’ strengths and weaknesses.
In this paper, we present an empirical study on the integration of user-centred design and Agile, with the goal of achieving a development process more considerate of user needs. In particular, we introduced a curated set of lightweight, qualitative design practices in an Agile company through a series of workshops. Our results suggest that the followed approach enhanced internal communication and promoted a concrete shift towards a more user-centred perspective. However, the presence of a predominant non-Agile customer seems to have limited potential benefits.
Silvia Bordin and Antonella De Angeli
We want to give an introduction to our recent endeavors in introducing pattern into the area of making leadership happen and building self-organizing Agile teams.
The reason for us to spend the time and energy in this area is very simple: With all the theories and frameworks in building leadership and self-organizing Agile teams, we are simply lost in how to make those beautiful things really happen in reality in a practical way, with specific, step-by-step tools. Taking me for example, though I was offered a number of trainings on leadership and Agile transformation topics, when I stepped into my new role of Agile team R&D leader, my confidence level was still quite low and was in desperate need of practical guidance to start my journey (actually I am looking for something like "1st-month manual for Agile SW team leader", but I failed). And I am sure I am not the only Agile team leader with this pain.
Then my “ah-hah” moment came when I attended Linda's workshop in XP2015 and then read the book "Fearless Change" by Linda and Mary. It was my first time to realize the power of pattern outside design pattern area. As a former software developer, I find that applying those change patterns in introducing my new ideas in my team is equally powerful and effective as applying those classical design patterns in crafting an elegant piece of software. Immediately, I was inspired to seek the possibility of introducing pattern into the area of making leadership happen and build self-organizing Agile team to capture those successful solutions/practices to recurring problems as I faced. Why not?
In fact, the effort turns out to be worthwhile. Our experience of capturing successful solutions/practices into patterns and applying those patterns so far has shown quite positive results. Collaborating with my colleagues in Nokia, leaders from other software companies, and other Agile practitioners in local communities, we have together summarized a number of leadership patterns which are organized around four key pillars to achieve high performance leadership in Agile teams (which we call “4P leadership framework” – Purpose, People, Performance, and Personality). For each leadership pattern, there is a structured way to document it including a name, background, problems to solve, constraints, practical solutions and known cases of applying the pattern.
The early feedback for those leadership patterns has been quite encouraging. After presenting this topic in local Agile community gatherings and national software industry summit, people are interested in learning more about those patterns and inspired to apply them. We have also received positive feedback after people try those patterns in their team and organization. More important, new leadership patterns, not surprisingly, have been added to our repository when the audiences start to summarize their own patterns – patterns are alive in this manner.
So in this talk, I want to take this opportunity to share our thinking in this topic and those leadership patterns we have so far (maybe some of them due to time limit) to a wider audience. And I am expecting something interesting to happen.
Yanti Andriyani, Rashina Hoda and Robert Amor
During an agile transition the change of mindset, leadership behavior and the shift of responsibilities to many are key elements. Usually a company would work very hard on delivering this message, training people and make sure, they understand this new philosophy. But when it comes to daily business, the employee needs to see structural and process changes, too, to receive guidance and boundaries. Furthermore, they need to see that the agile transition is something that not only takes place in mindset but also happens in reality. He needs to feel safe when acting based on the new philosophy. Feeling safe is something that they will only experience when the new definitions, rules, guidelines and boundaries are also made explicit. Quite often those structural and more tangible changes will only follow after a while. During this period confusions and fallback into old habits may arise.
And here the contribution from HR can and needs to start! Become involved and proactive: Understand what agile transition means and immediately start changing old systems and processes. Develop and offer new tools whenever needed to support the new way of working and thinking. Emphasize the wanted behavior and work methodology in guiding the teams through three stages with your new tools.
The speech will describe the benefit of the listed three phases and concrete tools and guidance on how to implement them:
Sharing (feedback) is caring
a. Throw away your old manager – employee dialogues
b. Implement team feedback
c. Let the teams do their feedback dialogues themselves
Team feedback for social competencies
Team feedback for technical and skill competencies
Learn how to and helpful tools
Reduce hierarchical thinking
a. Throw away processes that the manager usually owned
b. Let the team take ownership
c. Implement team review and team approval processes
Vacation planning
Team training budget
Recruiting and onboarding new employees through the team
Learn how to and helpful tools
Break with old (or common) rules
a. Throw away old processes for salary raises/adjustments
b. Standardize and objectify salary adjustments procedures
c. Build them on team feedback and benchmark reviews
Team Bonus
Merit Money
Learn how to and helpful tools
At Intel, we are faced with some hairy challenges: how do we create a clear line of sight from the highest levels of strategic vision to a concrete expression of a feature? How do we effectively prioritize work across the portfolio so we can allocate resources appropriately? And how do we make the voice of the customer come alive in the backlog to deliver more compelling products?
Our approach has been to progressively refine strategic value through a set of interactive, light-weight workshops translating executive intent into concrete work. By including a cross-functional set of executives at the start, defining an economic framework, identifying the job to be done and facilitating more conversations and interactions at different levels of the organization, we've been able to spend less time on non-value added activities and more time on product development. Along the way, we were able to reduce organizational WIP, understand what's really important to our business and ultimately create a more engaged organization.
This talk aims to give you a practical view of how we go from portfolio-level vision to team execution. Through a series of targeted, light-weight activities, this talk gives you a taste of each of the activities we leverage and how we get compelling results. Along the way, we'll illustrate the problems we faced, show how progressive refinement across our portfolio helped us solve them and demonstrate the benefits we gained as a result.
At the end of this session, you'll be familiar with a set of tools and practices that will help your organization align strategy with execution. You'll do more of the things that matter and less of the things that don't. Albeit not a silver bullet, an intentional approach to progressive portfolio refinement supports business agility across the enterprise.
Test Driven Development or TDD is one of the most well known and used practice of eXtreme Programming (XP) family. TDD is generally perceived as all about writing test code before writing production code followed by re-factoring if required.
Its a lesser known fact that TDD is not just about writing unit test code to find coding bugs, but can also be used as a powerful technique of exploiting the problems for writing better code. The proposed workshop intends to demonstrate how TDD can be used as a problem solving technique. This workshop is all about changing the mindset to consider TDD beyond unit tests.
The proposed workshop shall be done in the form of a "Innovation Games" exercise which provides a visual reference to problem solving technique(with and without TDD).
Workshop Modalities :
Angela Martin, Craig Anslow, David Johnson and Robert Biddle
UX and DevOps: 2 movements that still don’t understand each other. Don Norman and Jakob Nielsen say “In order to achieve high-quality user experience in a company's offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.”
They both want to be driven by customer insight, not guesswork; to be the subject of continuous evaluation, feedback, and rapid iteration; to require increasing collaboration among teams; to focus on accelerating release cycles. However, they rarely communicate to each other.
What does continuous UX evaluation look like? How do we meet users expectations? What does it look like to merge UX into DevOps practices? I’ll answer these questions and discuss the similarity of Lean UX and DevOps processes and how they can work together to bring better experiences to end users and team members.
Scaling up software projects can be quite difficult, especially if it is done focusing on the wrong aspects - most companies give too much weight to formal structures and processes (eg mandating the use of SAFe, LESS or other frameworks), and not enough weight to other aspects that would give a bigger bang for the buck: eg removing friction (providing the right tools for the job), improving communication channels, setting clear goals, delegating responsibility and accountability, etc.
In this session I'll share my experience in successfully helping companies to do the right thing in some quite large projects, and I'll offer some tools that you will be able to use right away in your projects.
The session, among other things, includes:
Pairing junior and senior developers on tasks is seen by many organisations as a mutually beneficial learning and mentoring practice. However, learning and successful mentoring are often mixed with frustration, disengagement and stalled progress. These difficulties are usually not acknowledged by the organisations and by the developers themselves.
Together with the audience we will look at a range of problems encountered when pair-programming across skill levels, analyse causes and effects of pairing ‘sins’ committed by senior and junior developers, and explore physical, technical and organisational impediments and solutions. These will range from the obvious and easily solvable, such as disengagement caused by bad physical space, to the more subtle and often overlooked issues related to self-esteem and experts' amnesia as to the process by which they acquired their expertise.
The material will be presented as a series of short sketches acted by the presenters and interspersed with commentary and audience participation. This format will enable a fun, engaging and highly interactive learning opportunity.
After each scenario we will:
Ask the audience to identify what could be improved in the interaction between junior and senior developer
Drill down into possible underlying causes of the observed dysfunctions
Capture these on a flipchart or whiteboard
The session will conclude with a group exercise to share ideas on how to address the underlying causes of dysfunctional collaboration and put better ways of working into practice.
We will share the results with the rest of the conference (if possible), and with the wider community online.
Many large IT systems have become too complex to understand. The complexity stems from the ever increasing number of technical parts but also from the increasing number of people involved. Still, the systems are designed, developed, tested, and taken into use without paying enough attention to the issues the inherent system complexity introduces. These issues – called emergent because we are not able to foresee them – result in system failures, downtime, and hasty workarounds and fixes. These, in turn, lead to unsatisfying user experience and unexpected costs.
When dealing with a mission critical information system, failures and downtime are unacceptable. The users need to be able to trust that almost whatever happens, the system is available to the users, in the best possible way. If a mission critical systems is first built, then taken to use, and finally maintained by different organizations, the challenge of divided responsibilities emerges. In the presence of any event regarded as a problem, it is not imminently clear which party is best capable of solving the situation.
The software-as-a-service (SaaS) model is a good fit with mission criticality in a number of ways. When the system is provided as a service by one service provider, there is no doubt who to blame in the occurrence of errors or who should take care of issues raised by the users. At the same time, the SaaS model puts a totally different kind of burden on the shoulders of the company providing the mission critical service. If the service has no option to fail, system design, development, testing, deployment, monitoring and maintenance while being operational, must be done the mission criticality as the first thing in mind.
Sampo Suonsyrjä
We create organizational structures and processes in order to make better decisions. Having lived with the complex bureaucratic systems in companies for decades, many businesses have started to experiment with delegating the decision making power to lower levels of the hierarchy and are therefore creating more flat governance structures.
We expand our business to new locations to reduce cost and deliver value to customers faster and more efficiently and also benefit from new markets. Having distributed organizations introduces a new set of challenges to how we communicate and work together. Many companies create new structures and processes to address these challenges.
We chose to create software in an agile way in order to build software incrementally and deliver value to the customers in every iteration instead of all at once at the end of a project. Agile software development requires a mindset that promotes servant leadership, self- organizing teams and collaborative organizations. Many companies find it challenging to create the management structure that supports an agile way of working especially when the organization is geographically distributed.
How can you in your current role influence your organization to become agile while being geographically distributed?
How can you benefit from the distributed organization instead of finding ways to avoid or fight it?
How can you create a more collaborative governance in your corner of the business?
How can you form a group of influencers inside the organization to drive this change in governance throughout the entire company?
In 2014, Ericsson split its very large Business Unit Networks in two (still very large) business units, as a response to the fast change the market was experiencing in how the core network products were shifting to cloud based, virtualized technical solutions. Internet of Things also started to take off, with new customer segments and new partners. These are truly disruptive changes, that affects how we do business, how we sell our products, and has a huge impact also on how we develop our products and cooperate internally and externally.
We realized early that in this new reality, we needed a SW Development System that was set up to manage constant rapid change, that was optimized on deliver high quality products fast, and with a healthy balance between aligned and autonomous methods and tools, based on Lean, Agile and DevOps development philosophies as well as Applied Systems Thinking.
This talk is to share the experiences we made while running one of the largest change programs at Ericsson, defining and deploying our SW Development System.
The program, “World Class Development” ended up having executed around 15 different workstreams of different sizes, addressing as many aspects of a modern SW development system, including core flow activities as Continuous Analysis, Continuous Integration and Continuous Delivery and Deployment (what we at Ericsson call Continuous Everything), as well as supporting activities such as Performance Management, Quality Management and Development Environment Management.
You will learn how we attacked the task given: “create a state of the art development model”. How we managed the program inspired by time boxed SW development methods, managed change over a very large operation, including how we worked with deployment over 13 geographically distributed Product Development Units, all with their own level of maturity, technologies, and needs.
Of course we will proudly share what we did brilliantly, but also share mistakes we did, logical/tactical as well as practical.
As we are now running the second phase of our program, WCD 2.0, we will invite for a discussion on the different topics presented, for participants to comment on and discuss what we could have done differently. To help us improve, but also to allow for an active dialogue on experiences.
So this talk is not about managing rapid change in our SW, but rather how we manage rapid change of everything else that help us deliver our SW!
In this age of software eating the world Release Early, Release Often is applicable for everyone and Continuos Delivery is right for everyone. The first step towards Continuous Delivery is having a right Continuous Integration where every commit is integrated and confirms the readiness "to deploy". It is hard to achieve Continuous Integration without Mainline Development or Trunk Based Development and Feature Toggles. The Feature Toggle technique is often rarely spoken even though it is simple.
But feature branching has been popular for long, and everyone knows about the “merge hell”, a common issue because of long-lived branches or infrequent integration. How do you continuously merge, test and release software with great confidence without spending too much time on merging and fixing conflict issues? That is where Mainline development, one of the key practices of Continuous Delivery, comes into the picture and Feature Toggle works in conjunction with the same.
Feature Toggle [also referred as Feature Flip, Feature Switch, Feature flag] is a simple technique which allows you to turn on or off a feature through configuration. Feature toggles give you the flexibility to toggle features in specific environments i.e. turn on a feature in testing or staging servers and turn it off the same in production. This also helps to rollback features, as rolling back is as simple as turning off the feature and deploying.
No Silver Bullet Reloaded: The Essence of Agile Essential and Accidental Complexity
Steven Fraser – Panel Impresario
The classic 1986 paper by Frederick P. Brooks, “No Silver Bullet: Essence and Accidents in Software Engineering,” has influenced several generations of software developers. Brooks emphasized the notions of essential complexity and accidental complexity, and he offered explanations on some of the most promising approaches to address complexity in the software development process. Most of these promising approaches are linked to agile practices. However, agile development itself not a “silver bullet”. While many of the agile practices are aligned with the approaches advocated by Brooks, agile development must be done with discipline in order to avoid adding accidental complexity.
This panel marks the 30th anniversary of Fred Brooks’ paper in the April 1987 issue of IEEE Computer – and the 10th anniversary of a similarly themed panel retrospective at ACM’s SPLASH in Montreal. Panelists will discuss the impacts of agile on essential and accidental complexity in software development and offer predictions for the future.
Ademar Aguiar
Software development is a knowledge-intensive activity that requires a spiraling process of interactions between individuals, teams and organizations, who collectively share their explicit and tacit knowledge with one simple goal: to obtain programming language statements to be executed by a computer.
Software knowledge is invisible and unvisualizable, boundary-less and dynamic, and as a consequence is inherently complex. Due to its intrinsic tacit nature, software knowledge is a challenge to capture and record outside of individuals minds. This is especially relevant for knowledge related with “what” to build (requirements) and “how” to build (design) and validate (tests). Although the complete understanding of a software system is usually hard for one single mind, it is at the same time hindered by communication among several minds.
In the “No Silver Bullet”, Frederick Brooks suggests to reuse more, incrementally refine a system, and to invest in great software developers, if we want to reduce total development costs. Agile promotes all of these, through frequent releases, simple design, and intensive team collaboration, and thus helps to reduce both essential and accidental complexity but unfortunately not in an order of magnitude. Better support for software knowledge management, from creation and preservation to retrieval is crucial.
Andreas Schliep
Agile is at home in the complex domain. By definition, it is more than a simple process or even a single framework. At the edge of chaos, we seek orientation through patterns and principles. This leads to several challenges for people who have their roots in traditional project management – and adds to the overall complexity. In this case, organizations trying to force Agile – the noun – on their people turn out to be less agile – the adjective – than several organizations that might lack modern project management but demonstrate modern leadership values.
The infamous chasm, we have been trying to cross for several decades now, has not disappeared. It has mutated into a different kind of split, not between organizational roles but mental models, a divergence within departments, management groups, even teams. Addressing this, and facilitating reconciliation, requires a new level of support by coaches, consultants, trainers and agile champions. We need to rebuild bridges, construct new ones, to help mental models change and avoid or correct fake cultural shifts. A new level of responsibility appeared, and many of us might not yet be ready for it.
Hendrik Esser
When Brooks published “No Silver Bullet” in 1987 the SW development "eco-system" looked quite different to the one we face today. The past 30 years have brought us huge technological and social advancements e.g. in processing speed, storage density, telecommunications, cloud computing, open source, 3D-printing, globalization, social networks, tele-working etc. This had profound impacts on Software engineering. We can observe huge increases in productivity, thanks to the re-use of SW components and the ability to easily connect experts from different parts of the planet. Agile has helped us to grow SW organically, create rapid prototypes and obtain customer feedback.
A lot of things became much more simple (just think of using an Arduino or a Raspberry Pi to create new products fast). At the same time the demand for ever more complex solutions has exploded. Today, almost no company can create a complex solution alone - we are living in a world of internationally distributed SW development using a network of colleagues, partners and suppliers. Everything is interconnected and there are huge dependencies. This has caused an enormous increase in accidental complexity as all this is coordinated and managed by a huge amount of engineers in management and coordination roles. It has also resulted in an impact on reliability, as no human being is alone able to oversee a complete solution. We see a lot of issues around SW quality. As a consequence there is a lot of thinking, consultancy services and tooling to get a grip on the emerging accidental complexity - many of them being of questionable impact. So accidental complexity is a significant contributor to productivity, complexity and reliability and working on accidental complexity is of rising importance.
Are the recent advancements in AI giving us hope to find a silver bullet? I do not think so. Capturing requirements needs deep conversations and contextual sensitivity as well as creativity (sometimes the dialogue with the customer turns to a completely different product than what was initially asked for). Machines will for the foreseeable future not be able to do this - look at how far speech recognition systems done by Google and Apple have come.
Jutta Eckstein
My impression is that sometimes Agile is treated as a silver bullet. Some companies are going through this transformation with the hope that Agile will solve “all” their problems. This transformation includes at times the idea of making the whole company Agile. There you can then observe that e.g. management (or the board) is using a Kanban board and is having a standup meeting, yet the structure and strategy are left untouched.
Yet, as well Agile seems sometimes to promise the silver bullet – currently e.g. the various scaling frameworks. Those frameworks pretend that there is a direct relation between cause and effect –by implementing the framework the company becomes Agile– yet ignoring the differences in organizations, staff, clients, markets, competitors, etc.
In general, I observe that complexity is often ignored. Organizations tend to treat all kinds of changes as being either static or dynamic and plan in terms of milestones for implementing a particular change (see http://www.hsdinstitute.org/resources/three-kinds-of-change.html). Yet, often (especially if humans are involved) change is complex (aka dynamical) and thus you can’t address it via milestones (or even more detailed planning) but only via experiments and then inspecting and adapting (or in Cynefin terminology by probing, sensing, and then acting).
However, Agile in its core addresses essential complexity – on the one hand with one of the principles “Simplicity--the art of maximizing the amount of work not done--is essential” and on the other hand with the practice of KISS.
Werner Wild
After more than 30 years since Fred Brook’s paper “No Silver Bullet – Essence and Accident in Software Engineering” was published, we still have not found a way to increase software development productivity tenfold in a decade. However, when using Agile and Lean, we are improving much faster than we did in the 1990s! If we would not, the rapidly increasing complexity of our current and future systems will kill us, figuratively (hopefully not literally).
Nowadays, a whole generation of software developers is entering the job market who were at least somewhat exposed to the principles and practices of the now - hopefully - well established way of development. Having trained a four-digit number of software engineers over the last 15 years I have a lot of hope that the new generation will avoid many potholes on the road to great software, but certainly Agile and Lean is not for everyone. I saw and still see many people struggling and feeling uncomfortable with uncertainty and change, which are core issues addressed by Agile/Lean. And, even for the ones who “get it”, Agile and Lean is - hopefully - no Silver Bullet automatically solving all their problems, but an invitation to adapt and adjust to the needs at hand, plus continuously improving the processes and - most important - themselves!
Currently a lot of interesting developments are happening when applying artificial intelligence and machine learning to software development, but so far I have not yet seen the serious breakthroughs required to satisfy the “tenfold increase
...Business liaisons, Product Owners, and analysts: do you work alone? Find your amigos , and engage radical collaboration. If you are a Business Liaison, Product Owner, analyst, or if you are a potential amigo this workshop is for you!
Radical Collaboration
Bring together innovators with varied backgrounds and viewpoints. Enable breakthrough insights and solutions to emerge from the diversity. (d.school / Institute of Design at Stanford).
You may already have a "friend" falling into the general role of “customer”, you'll find more of your amigos in many varied roles. ( Amigos is a word borrowed from the film title The Three Amigos. Amigos is a Spanish word meaning: friends, buddies, mates).
Your amigos are currently developing empathy in one, or more, of these areas:
That's where you'll find potential amigos. They include developers, testers, managers, and—of course—customers.
In this highly interactive workshop we'll give you a few new tools which are inspired by some of the design thinking modes and methods out of the Institute of Design at Stanford. Use your new tools to identify amigos and engage them in radical collaboration. We'll practice some methods to help you and your amigosunderstand each other's needs. We'll show you methods to balance your collaboration so that you can balance innovation, quality, prioritisation, architecture, continuous delivery, DevOps, and more. Are more needs emerging? With good amigos, you'll be able to add them to your balance.
These practical tools will help you meet your amigos and start balancing your concerns collaboratively while you consider customer value, business needs, and technical ease.
We invite you to take these tools home to use, adapt, and master.
Context
Within the automotive domain, agile methods and practices cannot always be applied following the pure doctrine, due to e.g. automotive standards, supplier-contractor-relationship or organizational characteristics.
Objective
Since software became a major part of the car, we were interested in identifying which agile practices (and methods) are used and adapted in an automotive domain at Bosch. Furthermore, we were interested in the reasons for using them.
Method
Therefore, we conducted a multi-case study with nine interviews from five different Bosch projects. Results: Similar to common agile surveys, our results showed a strong focus on Scrum. However, most of the Scrum practices are adapted and deviate from the original ones due to the specific project context. Practices from other agile methods, e.g. XP or Lean Development are used as well to extend Scrum. We were further able to collect the benefits of the single practices, most often resulting in improved transparency and planning.
Conclusions
The results show a widespread usage, but also adaptation of agile development in the automotive domain, at least in the early project phases that were covered by the case study. The study results will be used to support automotive projects in selecting and applying agile practices according to their specific process improvement goals.
Philipp Diebold and Udo Mayer
Martin Kropp, Craig Anslow and Magdalena Mateescu
Development, certification and maintenance of safety-critical software systems is complex and costly. In particular, having a high safety integrity system certified according to mandatory standards such as IEC61508 (process), DO178C (avionics) or EN50128 (railway) is fundamental to keep a competitive advantage but also one of the most severe cost drivers. An estimated 25-50% of total costs may be related to documentation of proof of compliance to standards and the assessment by external certification bodies.
The trend of implementing larger parts of safety system in software has led to a growing interest in agile software development methods and techniques to improve performance with respect to development efficiency, system quality and safety integrity, as well as resource optimization and effective assessment and certification. This raises a series of challenges, for example how to adapt agile principles to large and complex projects, how to implement changes in a conservative and plan-driven practice, how to involve external certification and notified bodies, and how to enable efficient and cost effective traceability and documentation management.
This third international workshop will be addressing industrial and scientific challenges related to the adoption and exploitation of agile methods and techniques to improve development and certification of safety-critical and high-integrity systems. The workshop will invite leading experts to share insights into recent results, needs, opportunities, and ideas to shape an important research and practice field.
The workshop will be based on a mix of presentations by an invited key-note speaker (to be announced later) and by authors of accepted papers (to be announced later). Around 40% of the time will be reserved for discussions.
Keynote: Experiences with the STAMP/STPA method for hazard analysis and its application to security and privacy
Stefan Wagner (University of Stuttgart)
The Dynamics of Agile Practices for Safety-Critical Software Development
Peter Axel Nielsen (Aalborg University)
The Agile Safety Case
Thor Myklebust (SINTEF Digital)
A Study of Safety Documentation in a Scrum Development Process
Yang Wang (University of Stuttgart)
Agile software development methods were made for small, co-located development teams, but are increasingly applied in other settings. Several large projects, with a number of teams that develop complex systems have started to use agile methods.
How to apply agile methods to large projects was identified as the "top burning research question" by practitioners at XP2010. At XP2013 to XP2016, this workshop has addressed research challenges in large-scale agile development and identified topics such as inter-team coordination, large project organization, release planning and architecture and practices to scaling agile methods.
Problematizing Agile in the Large: New Directions for Research and Practice
Knut Rolland, SINTEF Digital.
Assigned roles for Inter-team coordination in Large-Scale Agile Development: a literature review
Tomas Gustavsson
Inter-Team Coordination Mechanisms in Large-Scale Agile
Helga Nyrud and Viktoria Stray
The Negotiation of Information Infrastructure Evolution: A Research
Design
Finn Olav Bjørnson and Kathrine Vestues
Agile Approaches on Large Projects in Large Organizations
Yvan Petit and Brian Hobbs
The SAFe way to the Agile Organization
Jan Pries-Heje and Malene Krohn
Agile Transformation Model for Large Software Development Organizations
Maarit Laanti
The workshop will consist of short presentations and discussions in small
groups.
Psychological safety is a prerequisite for effective learning, and for great teamwork. We need to be able to examine and learn from our failures to be able to learn effectively. And when we feel unsafe we are scared to make a mistake, or even worse we hide them which affects not only our own productivity but the team's ability to respond to change quickly and effectively.
When we feel safe, we are at our best. But it is a big leap from saying that psychological safety is important to actually being able to create that safety among your team members. Attend this session to experience that for yourself and take away concrete tools that you can use elsewhere.
There are a lot of "right" things we'd all like to see in effective teams, like: doing things right, doing "the right things", and treating one another right. What do you do when it's obvious they're doing it "wrong?"
Agile leaders can feel dis-empowered because teams are supposed to "self-organize." Experienced Agile team members can feel their expertise is devalued or ignored.
Expertise and leadership evolves, with the Agile mindset, so that the team reaches new mutual understandings of what is "right" together. This is not helped by habitual patterns of debate, power struggle and setting standards. If you need to move faster, with better quality and are ready to try a different way, this workshop is for you.
Park your ideas of what's right, while you explore with us a model of thought leadership powered by influence, not authority. Deepen your understanding of "shared leadership", powerful questions, and inviting all voices - including skeptics. Come practice facilitative interaction skills in a dojo format, and leave with a plan to apply them in your own context.
In this workshop the participants use their own organization as a case, while progressively clarifying the
The content is based on our long experience, and research of Agile in large-scale organizations, presented at previous XP2015 and XP2016.
The workshop is based on experiential learning. The content contains thinking tools and fundamental (anti) patterns for the Adoption. For each theme we present theory shortly, analyze the participant's own working reality, share the learnings and decide what to do.
Themes for the workshop:
The background thinking may be examined at www.less.works and www.coordinationchaos.com
You have practical experiences using agile methods, such as Scrum or XP, or their underlying agile practices, e.g. pair programming, daily stand-ups, sprint reviews, retrospectives, refactoring or more? Great! Do you also have experienced yourself benefits and limitations they have in context of software and system development projects? Wonderful! Finally, do you want to contribute to reduce the amount of conventional wisdom associated too often with agility? Then you are the perfect match for our ImpAct-Workshop: Join us, share your experience on the impact of your used agility, learn from others, discuss your introduction of adoption barriers and let’s discuss solutions.
Our workshop is discussion-oriented and we are aim at eliciting as many impacts (effects) of agile practices (and also methods) on different (sub-) characteristics in different contexts. Furthermore, we are interested in eliciting contextual factors that render the introduction of single practices easier or more difficult. Based on our workshop format, we are also fostering cross-participant exchange of experience. So, join our workshop and our community!
1. Introduction and Motivation of the workshop
2. Short talks by already agreed speakers (might be even more than the two we already have)
3. Group work on specific Agile Practice and Goals
4. Presentation of Group work
5. Workshop summary and next steps
We wil perform steps 3 and 4 several times such that participants could even jump in later.
Large and complex systems have been developing for several years. Monolithic systems are often developed, deployed and tested as one bigself-standing piece of code. The modification of features in monolithic systems often requires the execution of comprehensive test suites to test the whole system. Experience teaches that monoliths often turn into
unmaintainable systems.
Microservice-based architectures can support the migration into cloud of monolithic systems. However, they are complex to design, requiring substantial expertise. On one hand, microservices can help developers to split the development into autonomous tasks, on the other hand, they require to implement a complex architecture and a messaging system to
communicate between each other that require a lot of planning effort that contradicts agility. Therefore, the introduction of microservices often slows down or interferes with the Agile development process, turning it into a waterfall-like process, particularly in migration projects. This context connects also to the recently discussed DevOps context where
development and continuous deployment are closely linked.
To address the current uncertainties including a limited documentation of best-practice and benefits, this tutorial aims at collecting experiences on microservice adoption, reporting best practices, but also specially failure cases, so as to build a community knowledge based on previous errors and successes.
Program
13:15 Opening (5 minutes)
13:20 Introduction to Microservices: What is a microservice and which problems can solve? Is microservice just another SOA architecture?
13:40 Process, Motivations and Issues for migrating to Microservices.
14:15 Work Group Formation
14:25 Discussion and classification of agile best practices, failure cases, advantages and disadvantages in adopting Microservices in agile contexts.
14:45 Coffee Break
15:30 WG summary and presentation of results
15:45 Microservices Advantages and Disadvantages: a survey industrial case studies
16:00 Wrap Up and Conclusions
There are already many simulations and games that apply LEGO® too instruct Agile and Scrum concepts. Most of these workshops deal with the planning and facilitation aspects of agile work environments. We want to introduce a different approach that focuses on XP engineering practices in the context of embedded and hardware development. The intended platform is LEGO® Robotics experimentation edition. Using a flexible set of elements, modules, sensors, in addition to a programming environment, we can outline, design and implement a robot that performs specific tasks. The engineering practices of TDD, Pair Programming, Continuous Integration and many more are not only treated theoretically but applied to the practical work.