3months Agile Consulting Blog

Article published in Computerworld 21/4/2008:

Outsourcing Agile – can it be done?

First let’s start with a contentious statement: An Agile approach is crucial to the success of any web/software development project that contains significant technical or business ambiguity.  

Agile means a lot of different things to different people. I believe the most important aspects of Agile are:

· Early and continuous software delivery, with a preference towards small two or four week iterations

· Acceptance and even welcoming of continually changing requirements

· Tight integration between the business and developers — one team who enjoy working together

· Giving motivated individuals the environment and support they need to be successful

· A steady pace of software delivery that can be sustained indefinitely

· Face-to-face interaction as the best form of communication

I’m not going to try to convince you to use Agile or go into detail about how it works — it’s isn’t for everybody and there are plenty of other resources in the space.  But, what happens if you are a business wanting to create something new, you like the idea of Agile and you want to out-source the development?  

Is it as simple as engaging a reputable “Agile” web/software vendor, signing a contract and off you go?

Not quite.

At the beginning of an Agile project you accept that you can’t fix price, time, precise scope and quality.  Agile accepts the reality that this is impossible - you will often find quality, time and price are fixed but the precise scope is the variable.  

Not being able to exactly define what you’ll get for your money at the outset can be a scary prospect for some. However this is where, in theory, a good contract comes in.

A contract, according to Wikipedia, is a “legally binding exchange of promises or agreement between parties that the law will enforce”.   In a traditional non-agile project a contract covers things like IP, payment terms, reporting requirements, warranty, conflict of interest, confidentiality and so forth. It also, most importantly, defines time-line, quality, cost and exact scope — that is; it tells you what you’re getting for your money.  

But, a standard contract doesn’t really ensure that you’ll get what you want. In most cases you will not be able to define exactly what you want up front, in part because the world changes around you during the course of your project. But also because you often don’t realise what you do want until you see what you don’t want.

Most bespoke web/software contracts are not worth the paper they’re written on. The main reason for this is explained above – you can’t define everything upfront to the point where it can be used by the legal system. Contracts are also a bit like prenuptial agreements — they don’t exactly help to build trust. They can also act as a substitute for communication during the project, which is a bad thing.  

So if an organisation wants to engage a vendor for an Agile project how can a contract be created that protects both parties, minimises risk and builds trust?

How about this: at the beginning of the project an Agile agreement is created (that is not considered a legal document) based on some key principles:

•     We will embark on a relationship of mutual trust and respect

•     We will ensure that both parties have incentive to maintain the relationship

•     If at any point, for whatever reason, the relationship breaks down we will ensure that either party can exit with minimal damage (typically cost or reputation) to either party

Additionally, this agreement should cover the following, written in plain English:

·         A description of high level scope and ball park estimates

·         A definition of core principles of the relationship (as above)

·         Client and vendor rights and responsibilities

·         Housekeeping, covering confidentiality, non-poaching, restraint of trade and so forth

·         Warranty, so everybody is clear about who pays for bugs and for how long

·         A description of the process the project will follow and the IP transfer agreement

This last point is the interesting bit.  In a nutshell the process could work something like this: there are short iterations of development, typically 2 weeks, resulting in working software at the end of each iteration. This is standard Agile.

At the end of each iteration the client tests and approves the functionality from that iteration. They are then invoiced (and they pay promptly) for the time spent but at a reduced rate (perhaps two thirds of the actual cost). This reduced rate is designed to cover costs but not give any profit to the vendor.

Once payment for an iteration has been received the source code is released to the customer. This cycle carries on until the whole site or product is released.  

At an agreed point, perhaps one month after go-live, the customer pays the remaining third of the whole project costs.  Once this final payment is made the IP and source code are transferred to the customer as per the original agreement.   The developer obviously has a big incentive to get to this point as soon as possible.

If all goes well a great product or site is built and everybody goes out for a beer and starts planning the next phase.

So how does this type of arrangement protect everybody if things go wrong? The first important point is that the whole Agile process is geared to highlighting and addressing major problems early — when there is less money at stake — rather than finding issues at the end when it is a lot more costly to address them.   The client guarantees the option to terminate the project early should they feel they aren’t getting value for money; for the vendor the agreement ensures that an unproductive and/or damaging relationship can be ended without a legal battle.

If the relationship or project does need to be ended there can be two types of split:

·        The amicable split. Everybody is still friends but agree to go their separate ways.   A notice period is given, specified in agreement, the customer pays money owed for time spent and the developer gives all source code, IP and documentation. Everybody goes for a beer a few months later.

·        The not-so-amicable split, involving major fallout or someone  going bust.  The client has got the source code to go elsewhere, the developer has received enough money to cover costs and may decide to use the IP/Source code to recover other costs. There’s no beer, but no lawyers either.

Mark Pascall is director of 3months, a Wellington-based agile consulting and web development company. This column is based on a presentation given at the Agile Barcamp in Wellington in December

Ok, I know a lot of you guys out there are getting asked about certifications and education and all that sort of stuff and without it you face questions about whether or not agile is legit. Lean back and relax now and let the Agile University come to your rescue !

Are you thinking about adopting agile practices in your organization? Then you probably think about how you get on with it and what the best approach is for your particular organization. Top-down or bottom-up - should you start with the executive management or the people doing the ground work? Should you introduce it step by step or with a big bang (a la Salesforce.com)?

Mike Cohn has written up an excellent article about the pros and cons of several approaches. You can check it out here!

Funny - I was so sure I won’t prepare a presentation for the agile barcamp tomorrow but instead just talk straight from the heart. Yet here I am writing down my thoughts of how to best communicate the benefits of both an agile approach to software development but also to project management. So without further ado and in reminiscence of the 7 habits of highly effective people here are the 7 habits of highly effective IT projects:

Habit #1 - Open and trusting culture

I said it before and I say it again: Agile is a state of mind more than anything! Establishing a culture based on openness, honesty, trust and respect encourages efficient communication. Risk and issues are identified and brought to the table where they then can be resolved in collaboration. Goals, risk and outcomes are shared and the team (client and vendor, business and IT) works together to achieve the desired outputs. Individuals embrace responsibility and accountability for their actions and for the success of the project.

Habit #2 - Identify your stakeholders

Find out who your stakeholders are and divide them into three categories:

• The ones that can stop the project - typically your project sponsor but there may be more
• The ones that can delay your project - dependencies to other people/projects, political agendas etc
• The ones that are interested in your project - they need/should be kept in the loop but do not have the power to impact the project

Failing to engage critical stakeholders from the get go can result in incomplete requirements, a wrong impression of the desired project outcome. Which leads us directly to

Habit #3 - Define success

Ask yourself if you have a clear definition of what success for your project looks like. Sure, there are the obvious things like “on budget/on time/to scope” but can you honestly say that even if you achieve all that your project is successful? What if you deliver everything but it turns out that the scope defined does not fit (anymore) the business requirements? On the other hand what if you do not deliver everything you set out to do but what you deliver is meeting the business needs perfectly?

At Fronde we usually define success with the help of sliders (developed by Rob Thomsett). These sliders show the priorities and the flexibility in certain areas, namely:

• Stakeholder satisfaction: How important is it that all stakeholders are completely satisfied.
• Objectives: Do all objectives have to be met?
• Time: How rigid are the timelines?
• Budget: Is there room for movement under the right conditions?
• Added value: Typically not all objectives add equally value to the business (e.g. compliance requirements)
• Quality: Does the system have to be bullet-proof? Or is there room for defects in lesser used parts of the system?
• Team satisfaction: How important is it to keep the team happy (disgruntled team members might leave)?

The kind of questions that the sliders ask are along the lines of “Is it more important to meet the dead line or to add value to the business?”. Having all stakeholders agree on the priorities and movement in areas is a sure sign of a highly effective project!

Habit #4 - Define scope

Quite often projects define scope as business requirements - in other words features of the system to be built. Effective project management defines scope as explicitly in scope and explicitly out of scope. Everything that needs to happen to make this project successful but is not the responsibility of the project team has to be identified (typical examples are user documentation, training, implementation/roll-out etc). Equally important is to identify one or more stakeholders responsible for making sure these things happen! So every out of scope item has to have a name next to it and this person/these persons take on the responsibility of making it happen (directly or indirectly).

And by the way, once you have defined scope make sure that you manage it efficiently!

Habit #5 - Deliver often and early

Agile comes in many flavors but all of them rely on iterative development techniques. Short (1-4 weeks), time-boxed iterations provide well-defined milestones where small chunks of the overall system are delivered - fully tested and ready for a production release if the business decides so.

The progress reported to the business and end users is quite tangible and stirs thought processes about how fit the current system (built to the current specifications) is for its purpose and gives all stakeholders a chance to rethink the priorities of the features yet to come. Some features may get deferred or dropped at all in an effort to work to an ever changing market - some may just get dropped because they seemed to be a good idea at that time but with a tangible system in front of stakeholders lost their initial charm. New features have a chance to be implemented quickly because the business can prioritize them in at the beginning of each iteration.

Deviations from the intention of a requirement (e.g. a misinterpretation or ambiguities in the specifications) are discovered early on and can be remedied with little cost involved.

Habit #6 - Planning and tracking

Keeping habit #5 in mind there are basically two levels of planning:

1. The project plan: This is the obvious one that most if not all projects have. It defines an overall timeline, major milestones and the road map - the strategic direction of a project or product. This is also the one that is more likely to adapt throughout the project.
2. The iteration plan: Most agile methodologies recommend a half day to a day planning session at the beginning of an iteration. The key here is to break down the features/user stories/use cases into small chunks of work (1-2 days max). This will allow you to track progress in a much more meaningful way. Rather than estimating a task to be 40%/70%/90% completed (and run in surprises in the “last” 10%) a task is either done or not - and with “done” I mean it has been accepted by the testers. On a related note consider spending some time at the beginning of your planning session on a retrospective of the previous iteration.

You can track progress in many ways - e.g. using spreadsheets, web tools or sticky notes. Whatever you use make sure it is visible to the team and ideally the stakeholders. If you are co-located having a board with sticky notes that move from “open” to “in progress” to “in test” to “done” is an easy way to track and communicate progress.

Habit #7 - Tools

Make sure you have the right tools in place to support an agile environment! For a software development project for example, at the bare minimum have an IDE with productivity support (e.g. Refactoring toolset), a source control system that allows you to easily roll back to previous versions and a continuous build server that compiles the code and runs unit tests and some code analysis tools on each check-in. There is no point in embracing change when it takes you ages to execute the change and you live in constant fear of breaking something!

It’s gonna be cool, it’s gonna be informative and it’s gonna be fun - in short it’s gonna ROCK!!!

We have been working behind the scenes over the last few weeks to organize a new barcamp event here in Wellington. The topic of this event is agile in all its forms and shapes. Have a look at the official barcamp wiki to find out more about what and who to expect.

Overall I can say I’m very pleased with where we’re at. Deloitte has offered us the top floor in their premises at Brandon Street (overlooking the harbor), the logo is done and the flyers are on their way. Huge effort particularly by Brian and Thomas to get that sorted!

I guess one of the challenges being an organizer of a barcamp (which is by nature a self-organizing event) to find out what to do - and what not to do. We are concentrating our efforts on the venue (location, facilities like WiFi etc), raising money to buy t-shirts and food and spreading the word. What we don’t want to do is organizing the day itself. If you want to learn about agile, share stories and/or experiences with peers, network with practitioners or talk to people about the dark side of agile just come along. And if you feel like you have something to say just go up to the whiteboard and put your name and your topic down and be a speaker too! It’s that easy!

One of the more difficult things to do during a Scrum sprint (or an iteration in general) is to manage the scope throughout the sprint. With the team working closely with the business to ensure we actually meet the business expectations there is a fine line between incorporating feedback and taking on more work.

Granted, without a detailed specification there is room for interpretation and it’s in the nature of an agile development (and one of its many advantages) that great ideas pop up as we can see a first cut on a particular functionality. However it is also important to not make the mistake of confusing the new ideas with the original sprint scope. You may be able to implement some of the ideas right away - depending on how much work is involved to make it happen. But often these ideas enhance the functionality you set out to deliver - in this case you are mostly better off to add them as backlog items and defer them to a later sprint. You might even find out that if seen in the context with the remaining backlog items they become less important and eventually aren’t implemented at all. If they are truly great ideas then surely the business will prioritize them into one of the next sprints.

If you take a four developer team and a four week sprint in which the team works closely with business representatives as an example it is reasonably to assume that two of these ideas (assume on average maybe 6h/idea) per developer come into play. Then maybe there are a few little other things (~1h work) your team is asked to do that is not directly related to the sprint goal and suddenly there is a full week of work that you haven’t planned for. It’s easy to miss a sprint goal if you keep doing this.

One trick is to consider implementation details purely from a business value point of view. Take for example a screen in an application that is used in a data entry process but also in a work flow. If your sprint scope includes the data entry but not the work flow then the screen is completed once it implements the data entry functionality - even if the team has to go back and modify the screen to make it work also for the work flow. With little things coming up ask yourself the hard question if they are necessary to complete the sprint goal! If not they go into the backlog and will be prioritized in the next sprint planning session!

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 …

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.

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.

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.

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.

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)