Posted by Nicole Belilos late at night: January 25th, 2012
How do you change the way you live or work? Many people, and companies, seem to think it’s enough to adopt just one or two practices. While they continue their old habits, too. Will this lead you to your desired outcome? Or will you just get frustrated?
Posted by Daniel Burm in the early morning: September 16th, 2011
Agile companies that want to create real ownership, have to say goodbye to traditional stakeholdership and embrace “joint company stakeholdership”. Remain to be an old-skool stakeholder in an agile environment and you will possibly act as a “stakekeeper” instead of a “stakesharer”, therefore withholding the company “staketakers” from focus on value and real ownership of results.
(more…)
Posted by Niklas Odding mid-morning: February 9th, 2011
In my last post I stated that there is a lot of emphasis on the fact that architects have to help to get the scrum team to work better, faster en with more quality. By following the agile values the architect will help “strengthening the heartbeat” of the scrum teams. However the activities of architects should encompass more. In this blog I will explain what this is and how to incorporate this in your way of working with scrum teams.
Posted by Niklas Odding around lunchtime: January 26th, 2011
This blog is the second of a series of blogs in which I will examine the role of architects in Scrum. Last week I started with the forgotten questions of Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile values.
Architects and the agile values
Most of the literature concerning the role of architects in an agile context focuses on the Agile flow itself and how architects can avoid disturbing that flow. Mike Cohn, in his book “succeeding with agile” makes the distinction between coding & non-coding architects. In where he states that the coding architects will have less trouble finding their new role in de Agile development process.
An architect within a team has to be able to code himself. He is a team member, who has more experience in structuring the application being build compared to other team members. By using that experience he can add value to the team. Scrum has no particular role for non-coding architects. The question rises if this is totally true. (more…)
Posted by Jarl Meijer in the early evening: January 6th, 2011
2010 has ended and a new year has begun. 2010 offered us a lot of learning opportunities. It was a good year for the Agile community in the Netherlands and in the world. We saw more and more big corporations embrace Agile methodologies and put serious effort into making it work for them, mostly as a project methodology. ‘Agile adoption’ was THE 2010 word, maybe on par with ‘Wikileak’. So what do we think will be hot in 2011?
(more…)
Posted by Vincent Partington in the early afternoon: November 25th, 2010
In a previous blog, I compared deployment automation to build automation. I wrote about the differences between the build and the deployment process and I explained why different features are required from the respective automation tools. In this blog I will explain the difference between release management and deployment and why release management tools that claim they do deployment automation are actually doing something different. And why that is a good thing. 
Let’s start by defining release management. While Wikipedia might define release management as a relatively new discipline in the application lifecycle management space, it has actually been a part of ITIL v2 since its release in 2000. It concerns itself with the management of software releases. Courtesy of the ITIL Open Guide, the key activities of release management are:
Posted by Marnix van Wendel de Joode in the early afternoon: September 2nd, 2010
In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team dynamics.
In most retrospectives, focus is on improvement. Questions are asked like ‘What is going wrong or could be done better?’, ‘What can we do to improve things?’, ‘Did we actually improve?’. While there is real value in these questions (and they should definitely should be asked), there is another part of a retrospective that is also very important: The Good Things.
Posted by Reint Jan Holterman in the early evening: July 26th, 2010
Recently, Andrew Phillips, VP of Product Management at XebiaLabs, and I had the opportunity to speak with Mike Vizard, tech journalist for IT Business Edge. We had a great conversation about automating application deployments and Mike’s article provides a nice look into our discussion.
(more…)
Posted by Erwin van der Koogh just before lunchtime: April 30th, 2010
I was triggered recently by a status update from someone that mentioned that we will have to get ‘this’ right the first time around in the future.
This particular case was about a test, very late in the project cycle, where lots of things needed to get together perfectly to make it work. Any delays would not only delay the current project, but all other projects that rely on the shared resources being used. This huge cost if things go wrong is why it is so imperative that we do get it right the first time around.
The problem is that this involves tens of people across multiple companies and departments, who have written thousands of lines of code.
Now I do not know what they are going to do to make things right in the future, but if we go by past experience most people will want to enforce even stricter entrance criteria.
There are a couple of problems with this approach:
(more…)
Posted by Andrew Phillips around lunchtime: March 8th, 2010
In a recent post, XebiaLabs‘ CTO Vincent Partington discussed some important organizational topics you will want to address while introducing deployment automation using Deployit.
Preparing your organization is, of course, crucial to getting maximum possible benefits from deployment automation. A few technical considerations also apply when introducing Deployit, and here we’d like to go into these so that you can be sure your infrastructure is ready when it comes to carrying out your first fully automated deployment.
(more…)