Archive for October, 2007

Purpose of business software

Tuesday, October 23rd, 2007

Business software exists for one reason only: to support the business and its activities, or to help change the way business is performed. There is no other reason for business software. If it doesn’t support the business the way the business needs to be supported or help change the business, it doesn’t matter how technically brilliant the software is. Its value lies in its capability to increase the productivity and efficiency of the business.

In principle, there are three ways in which business software can support a business and its activities:

  1. A business process improvement project is started to improve the functionality of a specific business process. New or improved software is designed to help improve the way people can perform the business process.
  2. New ways to use technologies become available, making it possible to totally change the way business is performed. For example, Web services have profoundly changed the way a web shop might interact with suppliers of goods sold by the web shop. Web 2.0 might have a similar effect on the way some businesses organize their interaction with customers and partners.
  3. Decision support.

One thing to always keep in mind for IT professionals …

The Agile Business Thrives

Tuesday, October 23rd, 2007

For business managers it’s important that the structure of software solutions is based on the strategy and structure of the business. If the business software is structured the same way as the business is, it becomes easier and less risky to change the software concurrent with the changes in business. When this is the case, the business becomes agile. The agile business always beats the less-agile competitor in the long run.

The most important purpose for service-oriented architectures is the business agility they’re capable of bringing to the enterprise. And being agile is a required—even if hard to achieve—attribute of any modern business. It is much more important for a business as such to be agile than for the software it uses to be produced by agile development methods. There’s not necessarily any conflict between the two, but business agility is by far the most important one.

There is no such thing as fixed scope

Tuesday, October 16th, 2007

The classic rule for agile projects is that out of the three main constraints time, price and scope (often referred to as the Iron Triangle) only two can be fixed - in other words you can fix the end date and the price but leave the scope flexible, or you can fix scope and time but leave the price flexible etc.

Iron Triangle of Software Development

Particularly as a vendor we are quite often asked to deliver on-time, on-budget and to-scope. Fair enough, as a client you want to know what you get, when you get it and how much you have to budget for it. I will ignore for a moment the fact that quite often less important features get de-scoped in favor of new more important features and/or modifications to already delivered functionality. This tendency is well documented and known by most people with two or more projects under their belt. How can an agile project succeed if the client asks for on-time, on-budget and to-scope?

The answer of course is that there is no such thing as fixed scope! You might have a fixed list of features in your backlog or a fixed list of requirements in your requirements document. But these features or requirements can be implemented in a number of different ways - some of which will take more effort to build than others. With frequent and rapid user feedback you will encounter a lot of little changes to your implementation - and rightfully so! After all we set out to build a solution that is aligned with the business as much as possible. But of course that means you still need to manage scope as you can’t just take on a whole lot of little things without either dropping other features (reducing scope), deferring the delivery date (time) or charging extra (costs). At the same time this also allows you to negotiate scope and open up the iron triangle by making the deliverables side flexible!

Typically the original request is to build all features to the utmost sophistication and usability. In reality however on average at least 50% of your feature list are either used less frequently or be a smaller audience than your high-priority features and therefore lend themselves to compromises should you need them. When putting price tags on features based on the sophistication level of the implementation you will discover quickly that the client will rarely go for the deluxe version.

The Agile Asana

Monday, October 1st, 2007
This article is part of the Agile Yoga series. To fully understand the context I suggest you start by reading the introduction.

Postures are probably the most well-known aspect of yoga. But there is much more to the postures than meets the eye - it is more than making a shape in space. It is what’s going inside this shape that is important. The foundation of this is the structural equilibrium established by subtle muscular adjustments. It is alignment that gives posture the grace, stability and ease that characterize Asana.

It is alignement that gives a posture grace, stability and ease
Alignment gives stability

In your organization Asana for once translates into alignment within your business - getting buy-in from the different parts of your business. Establishing a focus and common goals is a first step. In yoga the basic purpose of alignment is to harmonize the body (or in this case the organization) by harmonizing opposing lines of force (conflicting interests in your organization). It teaches us that through consistent repetition, tension is eventually eased and these lines of forces establish deeper and deeper structural harmony and integrity. However, to attempt these idealized notions of perfection (ideal processes and behaviors) on the specific realities of distorted body structures (current conflicting interests) is counterproductive: It not only more deeply entrenches habitual tension but also most likely create new ones. If we work with and from our actual limitations we will find ourselves approaching so-called perfection effortlessly and inevitably. So work with what you have and consider the current state of your organization! Achieve alignment through constant repetition and reinforcement of messages around alignment.

Another aspect of alignment lies in the subtle fine-tuning of the methodology and techniques of your choice. In yoga every fine adjustment can change your body structure. Rotate your arms outwards in Adho Mukha Svanasana (downward facing dog pose) and it will feel very differently - more effortless - even though the change is barely noticeable to an observer. Sandy recently told me a story about one of her clients who was very reluctant to prioritize the backlog. Only after several extensive discussions she managed to get to the root of her client’s issue. In their understanding prioritization was associated with automatically giving up on low-priority items (maybe past experiences?). When calling the same exercise Ranking the client was perfectly happy to do that and could see the benefits. A grand example of Agile Asana :)!

The Agile Yoga

  1. The Agile Yoga
  2. The Agile Drushti
  3. Intermezzo - The art of retrospectives
  4. The Agile Asana
  5. The Agile Vinyasa (coming soon)
  6. The Agile Bandhas (coming soon)
  7. The Agile Pranayama (coming soon)