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.
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.
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.
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.
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.
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.
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.
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:
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.
