The desire to change

Suppose one day, after a particularly bad hangover, you decide to change your life.  You long for a trim body, a balanced spirit, lots of energy and no more headaches. In short, a happy mind in a healthy, good looking body. But how do you get there?

Well, we all know that there are many practices that will help you achieve those goals.  Exercise three times a week, stop smoking, reduce your alcohol intake, and change your eating patterns. Oh, also, get more sleep, less stress, no more pills, and drink herbal tea instead of espressos.

But you hate sports, you love chocolate and smoking is your way to reduce your stress.  So what do you do?

The daily fruit practice

In order to get healthy, you decide that from now on, every day, you will eat a piece of fruit at lunch.   It’s pretty easy to do, even though you don’t like fruit very much.  So now you are satisfied, you do a healthy thing every day, and you expect to reach your goals (more energy! greater happiness! better looks!) anytime soon.

Will you? Of course not! While the daily piece of fruit is a step in the right direction, you will never fully get the benefits you are seeking if you keep up your old habits of smoking, drinking and eating greasy food,. And after a while you might even get disappointed and frustrated, and you will decide to stop eating fruit, claiming that “a healthy lifestyle simply doesn’t work for you”.

Doing just one healthy practice, or even a couple of them, isn’t enough. What you really need is to change your mindset. You want to be a healthy person, not do some healthy stuff. Once the healthy mindset becomes your way of life, the practices will simply be the natural way to go. And they will be a lot easier to start with and maintain for a long time.

The daily Agile practice

The same applies to Agile. We see many companies and teams that ‘ do‘ Agile. They take a couple of practices from an Agile framework such as Scrum, and they figure that that will be enough to give them all the Agile benefits. Some teams even think that if they just do a daily stand-up, they do ‘ Agile’.  While daily stand-ups, just like that daily piece of fruit, are definitely a good practice, your are still far removed from true agility if the rest of your behaviour consists of old, non-Agile practices.

A company or team only gets the most out of being Agile, when its mindset is based on the Agile principles stated in the Agile manifesto, such as continuous learning at all levels in the organization, business and IT working closely together, delivering the highest business value first, welcoming change, and creating an environment where motivated individuals can be creative and self-directing.

So if you are doing ‘some’ Agile, expand your practices. But more importantly, change your mindset. Don’t do Agile, be Agile. And remember:

One practice a day does not keep the old habits away…

More focus on “the string of rights” generally brings a great deal of success but also a lot of stress to cope with. The stress comes from the fact, that if all capacity in our production system is focused on doing the “rights”, that those “rights” might not always be the “rights” you are responsible and accountable for right now.

Dealing with the stress means stakeholders have to change their attitudes from viewing themselves as stakekeeper to stakesharer. Stakesharers put more value on the overall company results than the stakes they hold (semi) individually. This as opposed to stakekeepers. To facilitate “stakesharership” means, we have to scan our organizational context to see what elements are not aligned with the concept and to improve on them (e.g.; communication structures for dealt portfolio management, job descriptions, budget-management processes, leadership styles etc.)

Your focus on the string of rights increases if there are less stakekeepers around, as Burm’s formula for joint company stakeholdership shows us:

If there are also mature teams with enough sense of responsibility and involvement to become staketakers, chances are your increased focus on value and joint company stakeholdership are just around the corner.

Say goodbye to traditional stakeholdership. If you want to create real ownership in your agile company and maximize focus on value delivery, embrace the concept of joint company stakeholdership today!

PS: If you fill in Burm’s formula for your company right now, how would you score?

Architects add vision

Strengthening the heartbeat of Scrum teams is an overly limited view of the contribution that architects can make in an agile environment. They also help develop new design ideas, assist the organization in pursuing its strategy with the aid of IT, identify IT opportunities which could promote business value and assist in their implementation. Architects envision the future. In this way architects can also become catalysts for change. New IT developments can have a major impact on the business strategy and on the priorities for IT development.

This part of the work of the architect is often forgotten in organizations that are adopting Scrum. But is a very important part of the architects work. The following illustration shows the two primary aspects of the architects’ role. On one side they play a role in strengthening the heartbeat. On the other side, they play a role in envisioning the future.

As can be seen in the illustration, there are of course the necessary connections between the two parts of the job. The concept of “design ideas” is helping a lot to be able to connect the two worlds. In my next post I will go into more detail about the way the architects can connect both worlds and add more value to the organization.

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.

The role of architects in an agile environment should at least follow the agile values from the agile manifesto. Examining these values leads to guide lines that architects need to follow in able to be of optimal value for the organization.

1. Individuals and interactions over processes and tools
   The first agile value states that we are dealing with people and the way they communicate. Processes and tools can be helpful in certain situations, but should never become overemphasized. Obligatory thick architecture documents at the start of a project or the lengthy review procedures of documents, are examples where processes and tools have gotten too much attention. In a Scrum environment this is out of the question. Therefor Architects have to change their focus from written to oral communication. They have to communicate in person as much as they can with all of the stakeholders in the organization. Architects need to be able to communicate equally  well with the product owner as with individual members of the teams. Communication has to be two-way, enabling the architect be fed with ideas from others. Architectural frameworks like TOGAF can be used, but only if it helps the architect to get the message across. The method can never prescribe the activities the architects should do.
2. Working software over comprehensive documentation
   Architects in the past have been doing this from a distant perspective from the builders. Communicating through extensive design documents proofed to be not the most effective one.  Although architects themselves can be very proud of the documents they produced, this will not work within an environment with Scrum. Implementing Scrum in an organization urges the architects to focus much more on the communicative part of their job.An architect has to focus more on drawing sketches. He has to talk about the sketches to all the stakeholders. Adjust the sketches to remarks that customers en suppliers make.  Adjust the sketches to ideas given by the development team. But also the sketches to the impediments found during implementation, which makes them more in line with the real world.  Using sketches helps the architect to create a common view about the design of the software with all stakeholders, which helps to raise the quality of the software developed.
3. Customer collaboration over contract negotiation
   Architects have a big role to play in aligning IT and business. In companies with a complex multi-system environment, and multiple agile teams, the architects should be very close to the product owner, helping him to create maximal business value out of the requirements on the product backlog. By sketching the solution and giving insight in the complexity of this solution, the architect can help the product owner in settings its priorities even better, and support teams with the outcome of these global design discussions. An effective relationship between the product owner and the architect can create more business value with less effort.
4. Responding to change over following a plan
   The architect has to be able to respond to daily change. The best way to experience daily difficulties which can lead to changes, is to be close to the development team. The architect should be there to be consulted about all kind of practical design issues. The architect has to adjust his own sketches of the future continuously. The architect should be able to let go of some of his ideas if they are very difficult to execute.

Following these agile principles the architect has to communicate & interact more than ever with all stakeholders. In his communication he should make use of sketches instead of large documents. His working desk should be close to the teams and he should daily talk to the product owner. Most of this is focused on “strengthening the heartbeat” of the Scrum teams. He can add more quality to the software and speed up teams by smart designs.

However in my opinion there is missing something. So what is the missing ingredient what could make architects really successful?  In next week blog I give you my answers to that.

We are sure the Agile hot topics for 2011 are:

Agile Management

The managers finally find their place within an agile organization. In 2010 a lot of managers struggled with their position, in 2011 they find their spot. It’s called facilitation island and it smells like paradise and still feels like hard work.

Agile Management Consultancy

The management consultancy world invites itself to the party. The consultancies bring new (project)managementmodels around Agile with them to establish their position in the agile world. This is a mixed blessing: it’s both confusing and useful at the same time. Confusing because Agile is put in models that oppose the Agile values and put more emphasis on process tracking, Big Up Front Plans and management control. Useful as it attracts senior management attention to Agile and help accelarate agile thinking on typical board management topics as Agile strategy implementation, Agile KPI management, Agile risk management, Agile budget control and Agile organization structures.

Agile at Scale

Corporations shift from scaling agile to agile at scale. Instead of using Agile only for projects, agile is implemented at corporate level with a stronger focus on product portfolio management to deliver more value. Senior management gets seriously involved in the prioritisation of what’s really important. The discussion is no longer about prioritizing projects, it’s about what delivers most value to the company in the long run.

Agile Maturity

Many companies start their journey with agile. They seek to learn from the past experiences of those that went before them. Those trailblazers on the other hand are ready for the ‘beyond Agile’. Agile maturity with a focus on the journey from just starting to completely incorporating agile is the subject of many publications and presentations in 2011. Agile maturity is how the different groups share their experiences and learn from each other.

Agile Metrics

Now the use of Agile has become more and more serious, the need for good metrics has become even more real. The Agile world rids itself of its cowboy stigma by creating more transparancy in a way that is useful for everyone in an organization. Putting things on a wall is no longer enough, you can’t expect everybody in a 30,000 people company to visit all the teams daily or even weekly. The big agile adoptions embrace metrics to enable running agile at scale.

Risk Management

Given these other trends risk management becomes more important. The IT risk management so far has been the laughing stock of real risk management. 2011 is the year IT risk management matures and agile leads the way.

Agile Results Only Work Spheres

The Results Only Work Environment (ROWE) or ‘new way of working’ (Dutch: “Het nieuwe werken”) is here and implemented by many corporations. While corporations want the benefits from working with Agile, there is also a strong desire to apply ROWE. An answer is found to combine distributed working and teameffort into a new way of working called: Agile Result Only Work Spheres also known as AROWS.

We wish you all a pleasant 2011 and may it be a MoreAgile year !

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:

(more…)

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.

As humans, most of us are focused on what we can do better. Speaking for myself, I hardly name my strong assets or the things where I am actually good at. I focus on what I should (…) do better or what I can improve on. But I recently experienced that by focusing on the things to improve I actually lose focus on my assets and even start doing worse at the things I was good at.

In teams at retrospectives I see this happen as well. It really helps to create room during the retro to ask the question ‘What is going right?’. Examples of ‘Good Things’ are ‘Our code quality has really improved over the last iteration’, ‘Communication between our team and [some stakeholder] has improved a lot now that we visit him at least once a week’ and ‘I can focus a lot better on my work now that I blocked out at least three hours a day in my schedule in which no meetings can be planned’.

All members should really spend time on investigating the good things in the team and the process in use. These good things should be taken from the retro as well as the things to improve we listed and should also be guarded. Examples of actions to guard the good things are ‘We set up a reoccurring meeting with [some stakeholder] every Thursday so we ensure communication will remain as good as it is now’ or ‘Let’s make it a team policy to block two hours a day to make sure no meetings can be planned there’.

My schedule for a retro most of the time is the following:

1. Look back at the concrete improvements we decided on during the last retro and did we actually achieve those?
2. Take inventory of what things we think we need to improve (I don’t care how…), group them and prioritize.
3. Agree on concrete actions to take to improve the things we decided need improving in the coming period until the next retro
4. Take inventory of what things we think went well and attributed to the (increasing) performance of the team (or yourself)
5. Agree on what actions to take to hold the things that we value as good things

Ending with the good things for me is important, if only to prevent the retro from being “our bi-weekly complaints session”.

The retro is a powerful tool to use in Agile processes, aimed at constantly improving as a team (or organization). It is very important to strive for improvements, but keep in mind all those things that are actually already going well and don’t let those slip.

In the last paragraph, he brings up an interesting point, saying “there is going to be a lot of grumbling about having to adapt to some alien vendor’s approach to IT workflow.” Unfortunately, this is still an opinion we commonly see in the deployment world, and one we will need to work hard to overturn. Andrew noted that we want to get people to the point where they don’t see it as “[adapting] to some alien vendor’s approach to IT workflow,” but rather getting the benefits of industry best practices.

Of course, there are also situations in which there are legitimate reasons for deviating from this best practice. We often hear that change is too expensive and risky, or companies are too attached to their legacy investments. In these kinds of situations, we want to give people the opportunity to diverge from best practice and get the system to do what they need. 

However, it’s important to note that there is a definite trade-off here. Looking beyond any initial transition cost, companies employing outside deployment solutions benefit from the ease-of-use and peace-of-mind right out-of-the-box. However, for companies wanting to create their own in-house solution, they have the convenience of implementing a custom process, but will incur far more maintenance in the long run.

Issues around deployment solutions often result from a lack of industry standards. We’ve built our solution Deployit as a response to this absence. While we recognize it’s often difficult for companies to abandon their own solutions, Deployit still allows companies to work with their middleware of choice, supporting all leading solutions. And with the open plugin API, we offer both customers ways to tweak our in-built best practices as well as development partners ways to create new plugins to support even more middleware solutions out-of-the-box.

That being said, we’re very much a believer of accepted, open industry standards. If such a standard for deployment were to emerge, we would definitely embrace it. For now, the challenge remains getting companies to accept outside solutions for deployment automation to keep up with best practices.

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:

• Having to test every component for these extra criteria is a lot of work
• The longer the list of criteria is, the harder it will be to guarantee that every component does adhere to all of them
• When integrating multiple components it is the interaction where the complexity is, not the separate components
• You will only prevent foreseen errors

Especially the last two make it very unlikely that having stricter entrance criteria will work. So what can we do?

All of this reminds me of something in ancient IT history. I was not around myself, but I have heard much about the Punch Card days. Just to refresh everyone’s memory. This was an age when if you programmed something you made a punch card. You then took a stack of these cards to an operator who at some point in time ran your program on a big computer with a fraction of the computing power that you currently have in your microwave.

Now these programmers were in pretty much the same boat. They had to get it right the first time around. Any typo or mistake and at best a couple of hours were wasted, potentially days.
Currently however there are very few programmers around that care about typos before running a program. Let alone trying to figure out more complex mistakes. Why is that?
The answer is of course the compiler. A compiler can check your code for these mistakes much more quickly then you can. Why would you spend hours trying to find errors in your code manually when the compiler can find most syntactic errors for you in minutes or seconds?

The next great invention was the invention of the Unit Test. It was a lot more involved than just running a compiler on your code, but it did allow you to very quickly find not just syntactic errors, but also most of your logical errors.

Then came Continuous Integration. No longer content in finding errors in a single persons code we are now able to find another class of logical errors, which are introduced by the complexity of having multiple people work on the same application and relying on external components.

So what do these three measures have in common? They are very cheap, certainly compared to the cost of not detecting the error and they are very quick. These properties allow you to use them whenever you want, which means you might as well use them after every significant change, just in case you introduced an error.

In the complex environments we are currently working in there is no way we can get it right the first time all the time.
So next time you are saying “We just have to get this right first time in the future” or hear someone else say it, make a slight adjustment. “We have to go get this right the first time around when we try this for real”. And then go find a cheap and quick way of finding out if it works.

Preparing your infrastructure

Getting Deployit running on your infrastructure usually requires only minimal adjustments, but you’ll be able to get up and running even more quickly if a couple of things are set up in advance.

Configuring LDAP groups

Roles and access rights in Deployit are associated with users and groups in your LDAP. Once you have thought about who should have which permissions in your organization you can create the appropriate LDAP groups and assign users to them. Common examples are a developers group (or even one per application or “funtional area”), a set of deployers, middleware-experts and, of course, the administrators.

If some of your development is outsourced and you’re going to set up Deployit to allow externals to carry out secure “self-service” deployments, you’ll want to consider how to manage their access rights. One account per project or oursourcer is common, but we’ve also seen limited LDAP federation used here.

Identifying a Deployit host

In a normal installation, the Deployit server runs as a standalone Java 1.5 application. Its low resource footprint means that you don’t usually need a dedicated machine; we usually see Deployit installed on a “utility” box.

Since the Deployit server will attempt to make connections to the target machines, it is, however, essential to choose a host with network connectivity to all the machines Deployit will manage. The ports that need to be accessible will depend on the connection type, with SSH being by far the most common option. Of course, the Deployit server will also have to be able to access the LDAP used for authentication.

Users working with Deployit’s Flex GUI simply use a web browser to connect to the server. Obviously, they need to be able to make HTTP(S) connections from their local machines to the Deployit server to do this.

Preparing target machines

As Deployit is agent-less, no intrusive changes to the managed machines are required. A couple of small things are worth verifying before installing Deployit, though.

Obviously, the Deployit server will need to be able to connect to the managed machines, using the protocol and credentials given. Verifying that the specified account is correctly set up, can connect remotely and has sufficient permissions to execute management commands (refer to the User Guide requires authentication) is a good idea.

You can also use different credentials for connecting to the target machine and command execution, by specifying a SUDO user. If so, check that that user will be able to run the management commands.

Checking your middleware configuration

Deployit supports many versions of popular middleware stacks such as WebSphere, WebLogic and JBoss; check for your version on the list.

Since Deployit uses native management interfaces, such as wsadmin and WLST, to manage and deploy to middleware, you’re generally quite free to set up your middleware installation in your preferred way.

For some stacks there are a small number of requirements, such as wsadmin being installed. Also, if you will be deploying Java EE applications that are “fronted” by a web server such as Apache, Deployit needs to be able to modify the web server’s configuration. The documentation of the standard plugins describes these requirements in detail, and it’s good to check them in advance.

In some cases, such as deploying to Tomcat, certain features depend on specifc container configurations or modules. Deployments can also be carried out on a “bare-bones” installation, of course, which may well be enough for your needs.

Preparing data for your Configuration Item Repository

In order know how to connect to and manage your target machines, Deployit needs some information about your environments, such as the IP addresses or hostnames of servers, or the WAS home directory of a WebSphere cell.

By looking at the Configuration Items you plan to use, it’s easy to get an overview of the pieces of information required. Collecting these and extracting them from CMDBs and similar data sources, where appropriate, will make it easy to automatically feed them into Deployit via its Command Line Interface.

Next steps

Running through this checklist will put your in a great position to get Deployit installed, up and running and carrying out deployments using the out-of-the-box processes with a minimum of hassle.

Next time, we’ll discuss how to identify and evaluate the need for customizations to the standard process, and how you can go about further adapting Deployit to your organization’s procedures.

If you want to know more, these and other relevant issues – technical as well as business-oriented – are covered in detail in the free Deployit Training Series.