That was the question on my mind while walking out of an hour and a half meeting which was attended by 6 people. The problem wasn’t that complicated, we went into the meeting with 3 alternative solutions: so why did it take so long to pick one? It kept nagging me a bit and then I recalled the “Simple Architectures for Complex Enterprises” book by Roger Sessions. By applying his approach I was able to determine if we made the right choice and I’ll describe the results below.
What electronics tools exist to electronically master the agile process like Scrum, Kanban, and others?
Since this question surfaces every now and then, answers collect here (in alphabetical order).
- Agile Bench
- Google Docs
- Microsoft » Excel
- Atlassian » Greenhopper for JIRA
- Bandit Software » LeanKit Kanban
- Pivot Labs » Pivotal Tracker
- Rally Software » Rally
- Silver Stripe » Silver Catalyst
- Version One Suite
- Atlassian » Vodafone wins Ultimate Scrum Board Award
- Serge Beaumont
- Theo Gerrits
- Olav Maassen
- Pieter Rijken
- Yves Hanoulle
Some time ago I saw an interview on a talk show that intrigued me. It kept me thinking and even to this date the topic discussed still puzzles me. In modern day organizations and markets more and more emphasis is placed on efficient behavior which should lead to better results and better ROI. Effective behavior is also sometimes mentioned, but way less often and it’s is not elaborated upon as much as efficiency. Maybe it’s because both nouns have two f’s and a lot of e’s, so people tend to forget about effectiveness?
A while ago I realized that the C in COTS stands for Customize, so in reality it is Customize Off The Shelf (and not Commercial Off The Shelf). The premise of COTS products is that it reduces system development costs and long term operational maintenance costs. Sounds like music to management and procurement departments. Reality can be different. Realizing that the C stands for Customize highlights one of the pitfalls most people are aware of: the amount of customization needed to make a COTS product fit in an organization can be huge. But there are more pitfalls and in this blog I’ll highlight a few.
Abstract types in Scala can make your life much easier. In this blog I’m going to recap my intellectual journey to compare ‘apples to pears’ in a typesafe manner, which led me to abstract types.
What is NodeJS?
Node is an open source project initially conceived and developed by Ryan Dahl in early 2009, and has been in active development ever since. Joyent, Dahl’s employer, is backing and sponsoring the project.
Before we go in-depth, let’s explain what’s probably the core point of NodeJS – event-based I/O.
A few months ago I blogged about the integration between Deployit and IBM WebSphere CloudBurst (since renamed to IBM Workload Deployer). While that article gave an overview of the integration and included some nice screenshots, it did not really go into the details. Now is the time to explore the implementation of this integration..
Workload Deployer V3 and Deployit from XebiaLabs both “deploy” things, but they deploy different things. Deployit deploys application artifacts and resources, such as EAR files and data sources, to middleware systems like IBM WebSphere Application Server (but also HTML to web servers, IBM WebSphere MQ configurations to queue managers, and so on). IBM Workload Deployer, on the other hand, deploys patterns (or topologies) of virtual images to hypervisors — but not just any kind of virtual images. IBM Workload Deployer is especially geared toward deploying middleware topologies.
IBM Workload Deployer V3 is an updated and enhanced version of the WebSphere CloudBurst Appliance, renamed to reflect the expanded scope of workloads it can deploy, which are no longer limited to only WebSphere workloads. The content for this article (including screen captures) was created using a WebSphere CloudBurst Appliance, but everything noted here is equally applicable to IBM Workload Deployer V3. However, for the sake of consistency with the images presented, “WebSphere CloudBurst” is used throughout this article to refer to both products.
In other words, IBM Workload Deployer deploys the middleware systems and Deployit deploys applications to those middleware systems — complementary functionalities that form a perfect fit.
At XebiaLabs, we have been working on two exciting new integrations for Deployit. We created a Deployit plugin that enables you to deploy EAR files directly to virtual systems created by IBM Workload Deployer V3 or its predecessor, IBM WebSphere CloudBurst Appliance V2. We also created a WebSphere CloudBurst script package to deploy application artifacts and resources on newly created virtual systems.
This article explores two integrations between WebSphere CloudBurst and Deployit as a way of showing how you can leverage the WebSphere CloudBurst command line interface and script packages to integrate cloud deployment with your application deployment automation solution.
When working on a mobile Android application, I was confronted with the fact that the backend server wasn’t available yet to deliver the REST service. But I needed a server or good dummy for testing the Android client against the REST services. So I began my search for a REST mock server.
I started out using the SoapUI REST functionality, but that still lacks a good implementation for my purpose of reacting on REST calls. I ended up with a 10-minute build-your-own REST mock using the Play framework. This blogs describes how this was accomplished.
Today I was asked a really interesting question by a client: “Agile is very simple, why do you need Agile coaches?”.
That is a pretty fundamental question to ask of any Agile coach and after my initial shock we did come up with some good answers.
But the question (and the initial answers) kept nagging at me all day. And while I sat down with a glass of good whisky in the evening I got back to the question. Here is what I came up with:
- Agile is simple, not easy
- Experience bootstraps learning
- Organizational gravity
Across all industries, the services delivered by business applications have become an essential part of an enterprise’s customer offering. Bringing new features to market quickly is thus a critical factor in determining a company’s success.
In this post (an extended version of which is available as a whitepaper), we will outline today’s Release Management challenges and discuss the need for Release Automation.
We’ll identify key considerations for successful solutions and highlight why “Zero-Maintenance” is a critical requirement for Release Automation that provides the scalability required in an agile landscape and enables the delivery of continuous business value.