The Many Faces of Behaviour-Driven Development Tools

Software development is an inherent social activity. Put a group of great minds together, each from their own discipline, and see how innovation can flourish. In high-performing agile teams, bottlenecks are really not what one wants. And surely no ‘business bottlenecks’. A lack of innovative ideas, poorly specified epics or user stories will put the software development team machine to a grinding halt. Luckily, solutions exist that can act as catalysts or even fuel the machine: behaviour-driven development, or BDD in short.

BDD is synonymous for a collaborative approach for entire agile teams, and has common understanding and sustainable agility as its two cornerstones. BDD comes with a fair amount of tool support as well. The main focus of these tools is to accelerate the development process in conjunction with checking that the software that’s being developed, is right (cf. test-driven development). And this is what is very much needed. Not a single hour (minute?) of waste between the specification of (functional) requirements in user stories and the verifiable correct implementation of these requirements in well-defined acceptance criteria. This allows organizations to spend most of their precious time on actually implementing the functionality!

Whereas a plethora of tools already exists (see e.g. this list), new tools are popping up quite frequently. Some of the tools, such as FitNesse, focus on collaboration using a wiki. This allows teams to not be dependent on an integrated development environment (IDE) to which e.g. a product owner might not have access. Other collaboration tools (e.g. Cucumber or JBehave) integrate well in IDEs which allows teams to treat the specifications just as source code (“requirements are versioned too, you know!?”). As an aside, FitNesse was recently brought to your IDE as well..

Within Xebia, we’ve recently spent some time on evaluating JGiven. A new star at the BDD firmament but not yet widely known. JGiven truly brings BDD to the developers. JGiven does not start with the specification in text (where example test cases are specified in nearly plain-English, ready for automation), but with the specification in Java source code. The textual specification, which can then safely be handed to the business, is generated from the Java source code. A pro: JGiven has improved maintainability over some other BDD tools. These may seem just small and subtle differences, but organizations should weigh these considerations carefully when selecting a BDD solution. At least, this shows the dynamic nature of the collaboration tool arena.

Rest assured, Xebia will continue to explore these novelties in the specification and test automation landscape! Want to join the discussion? See what we’re doing or give us a call!

Written by Viktor Clerc, Business Unit Manager Test Automation

How TNT created the new Track & Trace with a rich customer experience

TNT is striving to give our customers the best possible experience. After successfully launching the new online shipment booking tool, the digital team’s focus shifted to piloting a new user-friendly Track & Trace. It is now being rolled out globally.

How do we do that? We focus on delivering modern, user-friendly tools to give our customers what they need, when they need, and on whatever device they need. Here’s the lowdown:

Introducing the new Track & Trace

The new Track & Trace is a user-friendly tool to let both senders and receivers know exactly where their shipments are. Customers can clearly see the status of their shipment and even understand when they need to take further action. This maximises customer experience by giving them timely information, but also reduces the need for them to contact Customer Care.

Another important feature of the new Track & Trace is that customers can access it on any device. That means whether they are in the warehouse or away from the company, they can track the status of the shipments wherever they are. It also brings TNT to the forefront of the shipping world with the first responsive Track & Trace tool.

To deliver the new Track & Trace, we used agile methodology which focuses on continuous improvement. There are 3 different phases of production: design, development and testing which are handled simultaneously. One of the the most important aspects is user-testing.

User testing and getting feedback on the new Track & Trace

Rather than just making a beautiful tool, it needed to be easy to use for customers as well. We selected people from inside the TNT centre and real Track & Trace customers to test it out to find areas where we could improve the customer experience.

We set up a usability lab and invited people to come test out the product. People were assigned tasks and UX experts noted reactions and feedback, as well as recording mouse movements, click behaviour and eye tracking. Insights from these tests broaded the focus of the application.

Another important source of feedback was from internal stakeholders at TNT. At the end of every sprint, we demonstrated the new functionalities at Super Tuesday. People from all departments at the TNT centre were invited to experience the newly developed aspects of the application and give feedback based on their specialist shipping knowledge. This was an invaluable part of the product development process.

Software testing the new Track & Trace

Successful development relies on good software testing processes. The Track & Trace team tests extensively in cycles. There’s a lot more to it than you think. In the early phases, software is tested on a variety of browsers and devices to make sure everything is working well. In the later phases, we automate testing to emulate real user clicks and scrolls on many different browsers on a tool called BrowserStack. We then do Galen tests to find any inconsistencies which cannot be found through automated tests.

Making the new Track & Trace faster

There’s no point making an easy-to-use tool if it doesn’t load quickly. We built the code with maintaining high optimisation. One of the biggest challenges was to find a balance between a rich user interface in such variety of devices, browsers and platforms we support.

Development tasks which we call ‘user stories’ are prioritised by our product owner. Google Analytics and Relay42 are being used to collect application usage information and other related data. We process these big chunk of data to understand the reasons of our users, in return make us to be more agile in making the right solutions in our improved customer experiences. Qubit is an another tool which we use to do A/B testing online.

To summarise even though our application will be rolled out globally this quarter, there is still so much to do and improve. This continuous process of improvement makes application success rate higher by increasing amount of happy customers by giving them right information on time, in return less calls to our customer service, overall better customer satisfaction and loyalty.

Agile, but still really not Agile? What Pipeline Automation Can Do For You. Part 2.

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?

Possibly your answer is “No”, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‘old problems’ just do not seem to go away…

Hence the question:

“Do you fully capitalize on the benefits provided by working in an Agile manner?”

Straight forward Software Delivery Pipeline Automation might help you with that.

In this post I hope to inspire you to think about how Software Development Pipeline automation can help your company to move forward and take the next steps towards becoming a truly Agile company. Not just a company adopting Agile principles, but a company that is really positioned to respond to the ever changing environment that is our marketplace today. To explain this, I take the Agile Manifesto as a starting point and work from there.

In my previous post, I addressed Agile Principles 1 to 4, please read below where I’ll explain about how automation can help you for Agile Principles 5 to 8.

 

Agile Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is an important aspect in Agile. People get motivated by acknowledged empowerment, responsibility, ownership and trusted support when performing a job. This is one of the reasons Agile teams often feel so vibrant and dynamic. Still, in many organizations development-teams work Agile but “subsequent teams” do not. Resulting in mini-waterfalls slowing down your delivery cycle as a whole.trust-in-hands

“Environment and the support needed” means that the Agile team should work in a creative and innovative environment where team-members can quickly test new features. Where the team can experiment, systems “just work” and “waiting” is not required. The team should be enabled, so to speak .. in terms of automation and in terms of innovation. This means that a build should not take hours, a deployment should not take days and the delivery of new infrastructure should not take weeks.

Applying rigorous automation will help you to achieve the fifth objective of the Agile manifesto. There is a bit of a chicken and egg situation here, but I feel it is safe to say that a sloppy, broken, quirky development environment will not help in raising the bar in terms of motivating individuals. Hence “give them the environment and support they need, and trust them to get the job done”.

 

Agile Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

When working Agile, individuals and interactions are valued over the use of processes and tools. When starting a new project, teams should not be hindered with ticketing systems, extensive documentation to explain themselves and long service times. These type of “services” often exist on boundaries of business-units of bringing different ‘disciplines’ to the solution.500px-People_together.svg

Although working Agile, many companies still have these boundaries in place. An important aspect of Continuous Delivery is executing work in Product teams dedicated to delivery and/or maintenance of an end-product. These product teams have all required disciplines working together in one and the same team. Operating in this manner alleviates the need for slow tooling & ticketing systems and inspires people to work together and get the job done.

Organizing people as a team working on a product instead of individuals performing a task, which in itself has no meaning, will help you to achieve the sixth objective of the Agile Manifesto. There is not a lot automation can do for you here.

 

Agile Principle 7: Working software is the primary measure of progress.

Agile aims towards delivering working software at the end of each sprint. For the customer that is basically what counts: working software, which can actually be used. Working software means software without defects. There is no point in delivering broken software at the end of every sprint.Working-Software

When sending a continuous flow of new functions to the customer, each function should adhere to the required quality level straight away. In terms of quality, new functions might need to be ‘reliable’, ‘secure’, maintainable’, ‘fast’, etc, which all are fully testable properties. Testing these type of properties should be integral part of team activities. One of the principles related to Continuous Delivery addresses this topic through Test automation. Without it, it is not possible to deliver working production-ready software by the end of each sprint.

Proper implementation of test-disciplines, fostering a culture of delivering high quality software, testing every single feature, adhering to testing disciplines and applying matching & automated test tooling addresses topics related to the seventh object of the Agile Manifesto. Supply a test for every function you add to the product and automate this test.

 

Agile Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

As software complexity grows exponentially, it will become more difficult overtime to maintain a constant pace of delivering new features, when assembling, deploying, testing or provision manually. Humans are simply not made to perform multiple tasks fast, repetitively and consistently over a longer period of time, that is what machines are for!

The eighth Agile principle typically comes down to a concept called ‘flow’. You might have an Agile team in place for creating new softflow-clipart-9183-flow-designware, but what about the flow in the rest of your organization? Should the team wait for requirements to drip through, should it wait for the testers to manually test software, or is it the Operations team that needs to free resources in order to deploy software? To address this, from idea to product, handover moments should be minimized as much as possible and where possible principles of automation should be applied. This brings us back to build automation, test automation, deployment automation and the automation of infrastructure.

 

Stay tuned for the next post, where I’ll address the final four Agile principles of the bunch.

Agile, but still really not Agile? What Pipeline Automation Can Do For You. Part 1.

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?

Possibly your answer is “No”, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‘old problems’ just do not seem to go away…

Hence the question:

“Do you fully capitalize on the benefits provided by working in an Agile manner?”

Straight forward Software Delivery Pipeline Automation might help you with that.

In this first post of three, I hope to inspire you to think about how Software Development Pipeline automation can help your company to move forward and take the next steps towards becoming a truly Agile company. Not just a company adopting Agile principles, but a company that is really positioned to respond to the ever changing environment that is our marketplace today. To explain this, I take the Agile Manifesto as a starting point and work from there.

 

Agile Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is the main objective what Agile teams aim for. Delivering a fully functionmoney_time_value_blue_dice_400_clr1-300x300al product by the end of every sprint. But far too often this product gets ‘stuck’ somewhere in between the Development environment and the subsequent Test, Acceptance and Production environments, basically leaving you with nothing new to demo to your Product Owner and other stakeholders.

For a large part, if not the largest part, it is about culture: do (product-based) teams literally thrive towards producing high quality functional components in the shortest possible time-frame? If the mindset is correct, you have already come a long way, but often teams work with tooling which is well, errr .. just quirky. Builds need to be started manually, unit tests are performed in a couple of areas and there is a real low coverage for functional testing. In many cases, I see that deployments are performed manually by senior technical developer or the Operations department.

Automation of every manual step in the pipeline that can be automated is key here. Be it the automation of packaging, the automation of tests, the automation of deployments or automatically instantiating new infrastructure. Shaping your company into a product-centric environment, aligning your delivery teams and automating every manual step in your Software Delivery process that can be automated will help you to achieve the first objective of the Agile manifesto.

 

Agile Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile teams aim to be as transparent as possible. This also fits the necessity for delivering a fully functional product by the end of every sprint. By delivering software on a regular basis, requirements may be updated at any time as well. The best feedback a team could wish for is customer feedback and nothing more dynamic than the voice of customer.Lets-Talk-Change

Being capable of dealing with the ever-changing environment requires a different mindset than the one used for working with rigid processes some Enterprises still work with today. It requires a culture of trust, continuous improvement on organization, product and personal level and fosters experimentation. A company incorporating concepts of Continuous Delivery focuses on shaping products together with its customer, resulting in a product that will optimally fit customer needs. For instance, this can be done setting up a Minimal Viable Product, making it accessible to the customer while monitoring both user -and system behaviors where feedback is channeled back into your end-product. This feedback-driven change is continuous in nature and requires a level of rigorous automation where manual interventions for deploying a new product are no longer welcome.

In order to foster ever-changing requirements, make sure your software development pipeline is able to provide the right amount of flexibility so your team can deal with this. It is of upmost importance you can react instantly and this is where automation comes into play.

 

Agile Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Deliver working software frequently is what an Agile team aims for, giving it instant ROI on a sprint-by-sprint basis. Agile teams deliver fully functional software by the end of each sprint, but sometimes this software remains stuck in subsequent parts of the software delivery process. As long as software is stuck within the pipeline, in any other environment than Production, it does not generate any value.Time-m

When your aim is to move towards the shortest possible release cycle, like delivering software multiple times a day, this can only be done when applying rigorous automation. These topics are addressed in areas like build automation, test automation, release automation, deployment automation and automating the provisioning of your infrastructure. Automating every manual step in your Software Delivery process that can be automated, will help you to achieve the third objective of the Agile manifesto.

 

Agile Principle 4: Business people and developers must work together daily throughout the project.

Working in end-to-end responsible multidisciplinary teams is an important aspect of Agile. People with all types of knowledge related to the end product need to be assembled within one and the same team. “You build it you run it” is what we hear often and for this, we need to make sure we are working in teams which objective is to not only deliver new functionality, but also to take care of the product’s operationGrowingTogetherLogo-web_sizeal aspects.

An important part related to Continuous Delivery, if not the most important part, is culture. When the objective is to push product delivery cycle times to an absolute minimum, chances are your workforce needs to be organized in a different manner than it currently is. First of all, you need to minimize the amount of handover moments, which can be achieved by organizing people centrically around (a part of) your product, i.e. put business, developers and ops representatives into one team where each member of the team is to explicitly bring skills to the table that add to the product.

Now, there is not much that automation can do in terms of ‘teaming’, but automation can help you in pulling product information to an abstract level everybody can understand. A failing build (red screen), a failing test (red screen with clear test name), a failing deployment (red screen with failing component name), a statistic report (6 / 10 deployments successful or ‘spikes after deployment of version n of the product) can help the whole team to understand what product status is. And this is what teaming is all about: that every discipline within the team understands that it is not just about their isolated part, but it is about the complete team’s product.

 

Stay tuned for the next post, where I’ll address Agile principles 5 to 8.

 

Michiel Sens.

Begin with the end in mind

road with start written over it
begin with the end in mind

Begin with the end in mind.

My previous blog was about the mind shift that leads to the decision to start building a continuous delivery environment. But also without this sudden mind shift, most organizations started improving their software delivery process to enable them to meet the rapidly changing business needs.

In my opinion starting to automate your software delivery process is a very important step itself. It really doesn’t matter if the improvement is set off building a fully automated test environment or improve the deployments of software.

This reminded me of the 2nd habit for effective people written by Steven Covey “Begin with the end in mind”. Although this habit has more to do with personal development and how to deal with changes if you have a clear focus on what you want to achieve. For me, in this context, it has two meanings: First “Begin”, in other words start automating and second “with the end in mind” so you’re able to make the right choices based on the current maturity level and the level needed to meet your ambitions.

To give an example (and perhaps an incorrect example because I’ve never really checked): Amazon release changes a 1000 times a day, you can imagine there is no manual action involved anymore after the developer is done. However, if the purpose of an organization is to mitigate the overall release weekends that occur ones a month (read less hassle and less headaches), then you don’t need to automate your release process to an extreme level. At least it will save you some money.

continuous delivery table
Continuous delivery maturity model

When we perform a continuous delivery maturity scan or audit, the maturity level really needed to ensure the business needs is an important question before we start a maturity scan.

If you want to release 12 times a year or every day will make a big difference in an existing landscape (unless you have the luxury to start with a clean slate). So we look at the total release-process from idea to production and determine the needed maturity level based on business needs. A good starting point would be where it currently hurts the most.

Finding the right balance between maturity, real needs and wishes. Having a clear view on your goals is always helpful, in this case it’s a necessity. But at the end, start automating.

“Begin with the end in mind”

How a large blue whale can actually greatly boost the agility of your IT

Logo Docker

When I joined Xebia about a year ago, I first felt a bit guilty not knowing that much about Docker. But knowing that developments in the infrastructure automation world follow each other quite rapidly nowadays, and the fact that none of my colleagues knew — let alone, had any experience with — Docker two years ago either, was a relief. But things change rapidly now! Looking at the rate in which we help Xebia customers transform their IT using next generation datacenters, powered by Docker, I can only conclude that this Silicon valley company with its distinctive blue whale as logo, is in the midst of the disruptive New IT movement that is currently underway.

Since my early years in software engineering I have been fascinated by the open source community. In those early 2000s it was cool to see Linux starting to claim an important role in the datacenter. Currently, next generation datacenters are almost entirely powered by open source ecosystems. Virtually everywhere you look in the IT stack—from storage to networking, compute, mobile, and virtualization—the most exciting innovations are driven by open source projects. Last year alone, the open source community produced great value in projects like OpenStack, Mongo, Mesos, Kubernetes and Deis. And Docker, for a second year in a row, made the top-10 as well. And rightfully so, if you ask me.

docker-arch

Docker has the potential to revolutionize the way we build, deploy and distribute applications. Docker is an open-source project to easily create lightweight, portable, self-sufficient containers from any application. The same container that a developer builds and tests on a laptop can run at scale, in production, on virtual machines, bare metal, OpenStack clusters, public clouds and more. Docker containers wrap up a piece of software in a complete file system that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in. Docker has a powerful slogan to summarize this feat: “Build, Ship, Run”. And the metaphor with physical shipping containers isn’t hard to make: Docker’s virtual containers make it easy to move and run software across the thousands of computers that make up today’s massive data centers.

Since the company open sourced its tools, Docker radically altered the cloud computing landscape. Practically every cloud computing and web infrastructure company on the planet, from Amazon to Oracle to Red Hat, is integrating their products with Docker, and you can’t attend a developer conference these days without hearing at least a couple talks on containers.

docker-training-partner     docker-consulting-partner

 

 

 

It is for this reason that Xebia’s IT architects were the first in the Netherlands to not only embrace the concept, but also experiment with Docker in all sorts of ways (we regularly host innovation days, meetups and seminars — internally and at our customers). We entered the Docker partner program for consulting and training services early this year, and have a number of certified Docker trainers in our midst. We also play an active role in the Docker community, and have given quite a few workshops on Docker-based solutions on conferences and meetups (e.g. DevOpsDays, XebiCon, and Docker Randstad). To boost innovation in datacenter automation and to lead the containerization in modern IT infrastructure, we launched our own label Nauts earlier this year. I am very proud to see that all these activities help to attract great talent, and build a capability needed to really have an impact also in the most corporate, bureaucratic and whale-like customers we serve.

This summer, however, I clearly noticed a shift to next gear in Docker adoption in practice. This is primarily driven by our customers, who, after a period of building awareness and getting used to a new world of IT operations, now seem more than ever ready for diving into New IT themselves.

At Xebia we have seen our customers struggling with building proper software for over a decade. Let alone the hassle of bringing this software easily into production, maintain it, and remain the software quality over time. In a world where enterprises only survive by continuous innovation, there is a dire need for shipping better software faster. And here is where Docker offers developers a hand. When applications run in Docker containers, developers do not have to worry anymore about setting up and maintaining different environments or different tooling for each language used. Instead, more focus can be placed on new features, bug fixing and shipping the software. Docker also integrates well with the continuous integration and continuous delivery practices many of our customers invest in. And to complete the typical triangle of architecture – operations and – development, organizations investing in microservices architectures benefit greatly from Docker as well. Many CIOs by now have found out that a redesign of their IT landscape is clearly a way to go in order to allow their autonomous agile teams to actually create business value. And this move towards independent, business-value-generating, building blocks of IT, is what makes microservices such a powerful concept. [Side note: this concept is nothing new; at its core, it uses a philosophy that was the central idea behind the Unix operating system: “programs do one thing and they do this thing extremely well”].

At this moment Xebia is helping four large customers with redefining their IT operations, and part of that transformation involves building next-gen datacenters. I will delve into these cases in future posts. In all those architectures, however, Docker plays an important role.

Docker is definitely not the answer to everything, but for me it represents a trend in software development and operations that greatly helps simplifying, scaling and speeding up software development. And this is perfect for transforming traditional IT departments into leaner and meaner production factories where “done = live” actually is possible, and where IT is no longer a bottleneck in innovation. Not bad, for a company whose logo does not really have an ‘agile’ connotation. 😉

We cannot solve our problems with the same level of thinking that created them

I was thinking about this quote (presumable once coined by Einstein) when I was talking to a client about Continuous Delivery. The manager responsible for the IT development department explained to me that the release of their main application was a big hassle.  Continue reading We cannot solve our problems with the same level of thinking that created them

Big balls of mud turning into elephants

On my first day as Xebia employee I immediately got involved in a very interesting project for a customer in the financial sector. In hindsight it had almost all ingredients to be a spot-on case for our New IT paradigm.  Continue reading Big balls of mud turning into elephants