Personal Productivity on Agile Teams

Personal productivity systems like Getting Things Done or the Pomodoro technique are quite popular among agilists, and I’m not surprised. There are many parallels with agile practices, most of these techniques use practices resembling iterations, backlogs and frequent retrospectives to become more productive. I’ve been experimenting with a couple of these but once I started using these at work I found that these don’t automatically work in a team setting.

Personal productivity isn’t team productivity.
In an ideal world a team consisting of very productive individuals is automatically a productive team. Unfortunately the real world is far from ideal. Because teams are very interdependent optimizing the work of a single team-member will not automatically optimize the whole. In many cases local optimization like this might even be cause the team to become less productive. Lets look at what’s causing this and how we can avoid it.

One of the ways to become more productive as an individual is to reduce interruptions. Making someone doing complex work switch between tasks a lot by interrupting them will make them far less productive, not only because the interruptions take time, the act of switching between complex tasks takes a lot of time too. A large part of personal productivity systems is avoiding interruptions. Unfortunately avoiding interruptions in teams often means avoiding communication. Communication is critical in a team.

Another way to get a big productivity boost is working with to-do lists. By listing and prioritizing tasks you can streamline your work. But in a team setting personal to-do lists can be problematic. People working from their own to-do lists instead of the team backlog can make coordinating work hard, it creates invisible work in progress and when people start planning their work too far in advance to-do lists can introduce rigidity into the team.

Aligning personal- and team-productivity
So should you only use GTD at home to organize your gardening duties? Of course not! There are a couple of things you can do to align your personal productivity with the productivity of the whole team.

Keep communicating.
The temptation to keep your head down and just steam through your own tasks is often big. For example the pomodoro technique gets is name from the kitchen timer used to time 25 minute periods where you need to do focused work without any interruptions. Pair programming can help to still get these periods of uninterrupted work without losing touch with your co-workers. You shouldn’t count questions from coworkers as interruptions. They’re part of your work. A way to deal with these is to add them as priority items to your lists.

Keep your todo lists short and up to date.
To-do lists are great for streamlining work. If you make your lists too long you’re planning too far ahead. A list that contains more than a day of work probably contains work items that should be on the team backlog. Claiming too much work for yourself will prevent your team-members from working on high priority items.

Stay transparent, give coworkers access to your lists.
Try to keep your lists in a public place. Write them down and put them on a corner of your desk. Communicate the items on your list during the stand-up. It’s important for the team to know what item is on who’s list when priorities change. Work items may even become obsolete.

When done right personal productivity systems can become an asset in a team. I’ve been experimenting with these for some time. I noticed that reporting on work done and work planned during the stand up became easier because I was tracking my work better. Tracking time (or pomodoro) spent on a single work item also made it easier to spot potential problems earlier.

The Secret To Delivering On Time

The Secret To Delivering On Time

Hi, I’m Kelly Waters, author of the popular blog, All About Agile. I’ve agreed with Artem to guest over here at ASD and be a regular contributor – this is my first post…

I’ve been doing agile development for quite a few years now, and seen many benefits. But one of the most remarkable things of all, is how so many teams can quickly get good at predicting what they can deliver, and deliver on time, even if they were hopeless at estimating before!

For decades, delivering on time has been the holy grail of software development. So this, for me, is one of the most compelling reasons to do agile development. Here is the secret to consistently delivering on time:

  • Estimate features, rather than tasks.

  • Keep your estimates high-level intuitive guesses (don’t analyse the details).
  • Estimate in points to indicate the relative size of each feature.
  • Consider estimating using a number sequence like Fibonacci. Fibonacci numbers get less precise as they get bigger, which builds a natural distribution curve into your estimates.
  • Estimate as a team. Consider playing Planning Poker to facilitate this.
  • At the end of your Sprint (or iteration), score the points for all features you managed to deliver. Only score points for features 100% complete, tested and potentially shippable. This is your Velocity. Count zero for incomplete features.
  • Track your Velocity over time on a graph. You can also track your Reliability, i.e. the number of points delivered as a percentage of the number of points committed to at the start of the Sprint.
  • At the start of each Sprint, look back at your Velocity for recent Sprints to decide how much to commit to for the coming Sprint.
  • Don’t try to reconcile points with hours.
  • Commit as a team.

Like most great things in life, it’s actually very simple. That’s really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.

You’ll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.

Trust me, it works. I have seen it work in many different teams, time and time again. It’s a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.


The 7 Software Development Wastes – Lean series Part 5 – Motion


Previous posts on software development wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features , Extra Processing and Transportation

I must apologize to you all for the lag in this series. But being August, I was away on vacation. Interestingly, getting back is hard. You have to get back into the swing of things again to get up to maximum productivity. There’s quite a bit of re-acquainting and relearning so there’s waste for sure. However, I do feel I have more energy now since I am back so perhaps the waste is negated over time.

Motion – Task Switching

Waste #5 in manufacturing is defined as Motion. And motion can be compared to “task switching” in Software Development – as defined by the thought leaders applying Lean thinking to software development.

Task switching can be a big time waster. Studies have shown that if you’re working on anything beyond two seperate and distinct tasks, your efficiency goes down drastically the more tasks you take on. The reason is quite obvious; working on software development tasks takes a lot of thought processing and task switching requires that your mind switch contexts all the time. Each time that you switch contexts, there’s relearning and re-acquainting that needs to take place.

Additionally, if you are working on multiple tasks simultaneously, it’s going to take you longer to complete the first and each successive tasks. If you storm the first task and get that out, you are delivering value to the customer much sooner.

It’s important to be mindful of this. I have found in many organizations, especially software companies where there is a real casual atmosphere, it’s easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

If you’re a good tough ScrumMaster, you’ll see to it that priorities are all driven through the backlog and the Scrum process and that your teams are left to focus on distinct activities for maximum throughput and reduced overall cycle time in development.

Next week I will cover the 5th waste in the series – Waiting.

Fixed price part 2, Fix it with agile!

In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we’ll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.

To look at why fixed price is popular with clients I’ll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented “As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it’s spending money, at worst – wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares.”

I tend to agree to some extent. Clients often don’t care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don’t care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don’t realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?

Clients often don’t trust the supplier enough to move away from fixed price to other contract types. Fixed price often seems a lot safer to a client because it allows them to push risk to the supplier. In practice this just isn’t the case. The fact that a client can sue a supplier for breach of contract will not change the fact that the client doesn’t get any software. Allowing the client to point fingers won’t solve their business problem.

What do we need to improve our chances in fixed price?
Unfortunately we can’t get rid of fixed price. But there are several things we can do to make the best of this situation.

  • We need to make the best estimates possible within the limited time we have available before the start of the project with the limited requirements we have at that time.
  • In order to reduce risk we need to keep a close eye on progress in order to detect problems as soon as possible.
  • We need to build trust with the customer. Without trust there’s no way we can break the fixed price habit in the future.
  • We need to create a situation where we can break out the fixed price contract whenever requirements change without having to throw away lots of work in progress.

Agile fixed price
Fixed price projects will cause an agile team to make several compromises, up front estimation is not something we’re used to doing, committing to those estimates even less so. Limiting scope is also not a very agile thing to do. But even within these constraints I do think agile has a lot to bring to the table in fixed price projects. Lets look at how agile practices will help us achieve the four goals I stated earlier.

Agile estimation
The hard part of fixed price is up-front estimation. You need time and a detailed set of requirements to create really accurate estimates. We don’t have either so we have to make the best estimates possible with the least amount of resources. One of the best methods to do this is agile estimation. Even with the rough requirements you have before the start of a project it should be possible to create a set of user stories and attach rough relative estimates to them using something like story points. These can be transformed into a set of estimations using past velocity of the team. Keep in mind that it’s probably a good idea to pad these estimates with a risk-factor. In my experience abusing agile estimation techniques like this will not bring you the most reliable estimates, estimates are never as unreliable as at the start of a project, but considering the circumstances it’s the best option. Techniques that claim to be more reliable like function points analysis simply take too much time.

Agile risk management
Finishing stories every iteration is the best way to measure progress. A story is never 80% done. It’s 0% done or it’s 100% done. Everything in between is uncertain and will not allow you to measure progress. Agile forces you to finish stories every iteration giving you a clear picture of progress so you’ll know early on when a project is behind schedule. This kind of risk management is very important in fixed price projects where missing a deadline can mean the difference between a happy customer and a lawsuit.

Build trust by showing working software
Actually finishing stories in every iteration also gives you the ability to show working software every time. In fixed price projects this does not seem very important. Clients don’t expect to see software until the very end, and on the many non-agile fixed price projects I’ve been on that was exactly what we were aiming for. But when you want to build a relation based on trust with a client this is not the way to go. The best way to show a client that they can trust you is to be able to show them what you’re doing. Show them working software.

Break out of the contract
Showing your customer working software has an interesting side effect. They’ll want to change requirements. But because of the fixed scope this won’t be possible without breaking out of the contract or by doing work outside of the contract, giving the customer features for free.
There are two things that make breaking out of a fixed price contract hard. First of all the supplier will want to bill the customer for the work that has already been done. But if you have lots of work in progress defining progress is hard, fortunately in an agile project progress is much easier to measure as we’ve already seen. Also clients will probably not want to pay for software when many important features are missing. Prioritizing work according to client business-value will make sure the most important features will be implemented first. It will be much easier to switch from fixed price to a more flexible contract type halfway through a project.

In situations where you can’t get around working with fixed price contracts people often give up on doing things agile altogether. To me this is a bit like someone who is trying to stop smoking who, in a moment of weakness, smokes a cigarette, gives up completely and starts smoking one pack a day again. The fact that fixed price makes you abandon a couple of agile practices does not mean you should give up on agile altogether. I hope to have shown some compelling arguments for doing fixed price agile in this article.

The 7 Software Development Wastes – Lean series Part 4 – Transportation


Previous posts on the first 3 wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features and Extra Processing

It’s both interesting for me on the one hand, yet puzzling for me as to what makes a blog popular or not. The first article I wrote on this topic had close to 5000 reads as compared with only 1000 for the last blog post. I figured that based on the response to the first post, folks would be real keen to understand the rest of the 7 wastes in software development. Never the less, I am committed to continuing with the series. Hopefully there are still some of you out there who can benefit from it all.

Transportation – Hand-offs

Transportation in manufacturing corresponds to hand-offs in software development. Anytime you hand a deliverable off to a different party, there is some loss in the transfer of knowledge.

There are many such examples of hand-offs in software development:

1. Developer hands off to another developer. In this scenario if the first developer never documented the code properly it’s going to take significant addition effort to figure things out. Worse, the second developer may make assumptions and, as a result, introduce bugs in the system.

2. Developers hand off code to testers to test. Many organizations still don’t engage QA early enough. Bear in mind that on Agile projects, QA is involved as early as the requirements phase (not that it’s a phase). If the QA has no idea what the developer did or the problems he faced or the assumptions he made, then the QA is really just shooting in the dark. It’s important that the developer at least includes the QA early on, documents the feature accordingly (no long dissertations), so that an effective transition is made.

3. Handing the code over to deployment teams. Many times I find separate deployment teams struggling to figure out how to get applications deployed. Configuration settings, compile instructions etc if not properly communicated can cause significant delays.

4. Handing-off to customers. If the client is not trained properly, or the software functionality is not documented properly, there will be more support calls for example.

There are many ways in which to reduce transportation wastes in software development:

1. Ensure there is open communication between all parties. Broadband communication (as defined in Agile software development practices) is imperative.

2. Ensure proper, up-to-date and effective documentation is in place where appropriate. Identify these needs up front and ensure there are tasks for this on the backlog.

3. Include all functional areas in the development process.

Be mindful of and identify all these transition points in your organization. This will help minimize costs due to hand-offs in your organization

Next week I will cover the 5th waste in the series – Motion

Fixed price part 1, what’s so bad?

In his excellent article 10 Contracts for your next Agile Software Project, Peter Stevens described 10 different contracts that are often used in software development projects. At the end of his article he singles out one contract-type:

“Fixed price projects and agile development are considered not to mix. I know from experience that this is not strictly true. I am also convinced that other forms are better.”

I completely agree with him on this but since fixed price contracts are so common in software development it seems like a good idea to look at them a bit more carefully. In this article I want to look the problems with fixed price and why traditional software engineering methodologies are unable to solve these problems. In my next article I want to continue on a more positive note and show how agile practices will help you make the most of fixed price.

What’s so bad?
The most obvious downside is of course lack of flexibility. Fixing project scope in the contract often makes it non negotiable during the project often preventing change altogether. In my experience stakeholders will change their minds during any non-trivial project and fixing scope at the start of a project will limit the quality of the end-product because it will not fit the client’s wishes one-hundred percent.

Not only scope is fixed at the start of a project but price is also fixed, hence the name. Making the supplier to commit to price estimates even before the project has started forcing critical decisions at the worst time possible. The later you make a decision the more information you have to base that decision on. Agile tells us to make them at “the last responsible moment”. Making them sooner is risky.

Fixed price projects are often more expensive than they should be. The rigidity of these projects often causes scope to be too large. At the start stakeholders in the client-organization will specify many requirements and features they probably won’t need ‘just in case’. They know it will be hard to get them in later. Fixed price projects also force the supplier to make very accurate estimates at the start of a project to reduce risk, the time spent creating these estimates are later often added to the price of the project. Suppliers often also add a fee for the extra risk they have to carry, a former employer of mine added 20% to fixed price contracts and seeing how much trouble fixed price was for them this was actually low.

Instead of aligning interests of the client and the supplier fixed price projects artificially opposes them. The client will want to stretch the scope agreed in the contract as wide as possible while the supplier will want to do as little work as possible. This often prevents good communication while increasing risk. I have yet to see a fixed price project where the client delivered an on-site-customer and I don’t think this is a coincidence. Fixed price pushes stakeholders into roles that are not beneficial to the success of a project.

Fixed price and BDUF
I’ve heard more than once that these problems make fixed price problems especially to do in an agile way. A potential employer once told me when I asked him if they used any agile practices “We do fixed price so we can’t do agile”. When you look at the downsides of fixed price projects this seems logical. Fixed price has problems with some of the core agile values like flexibility and communication. The focus on up-front estimation also seems to point to big design up front or BDUF.

Unfortunately more traditional approaches won’t help us either. Big design up front will not help with estimations. We need accurate estimations before the project has even started. There hasn’t been time to gather anything resembling a complete set of requirements. Traditional estimation techniques like function point analysis are only as good as the data you put into them and unfortunately the data isn’t very good at the start of a project. Problems with flexibility and communication are only hidden, not solved.

Fixed price has some big problems. Not only for the supplier as many clients seem to believe but also for clients. These problems don’t go away by giving in to the traditional big design up front methodologies although some of the problems with flexibility and communication will be less visible. In the next article I want to look at how you’d do fixed price in a more agile way. This won’t solve the problems but it will give some tools to see them coming and to make it easier to switch contracts during a project.

The 7 Software Development Wastes – Lean series Part 3 – Extra Processing


Waste is a killer in any organization. But if you don’t know what to look for then you’re probably not going to be able to find waste and minimize it or eradicate it. This series primarily deals with explicitly defining the 7 wastes in software development so that you can start thinking about how this may affect your ability to remain as productive as you can be. This can make a significant difference to your company’s bottom line.

As reference, the first two wastes can be found in my previous blog posts here: In-Process Inventory/Partially done work and Over Production/Extra Features.

#3 – Extra processing

Extra processing in Manufacturing is the 3rd waste and this can be equated to Relearning or Rework in Software development. The time we spend relearning things we once knew or having to rework the same feature due to poor code quality can be significant in many organizations, ergo, it’s important to be mindful of this. It’s probably useful to list examples that would cause extra processing in software development

Undocumented code

If your developers don’t document the code properly then later on when you’re either fixing the code or making changes to the code due to new feature requirements, your developers (even the original author of code) are going to need to relearn why the code was written that way in the first place. Taking the time to document your code up front while it’s fresh in your mind can therefore save the company time and money.

Poor planning

Some project managers assign work to developers in a haphazard manner. Although you do want to ensure there’s knowledge overlap on your team, if you keep switching developers on the same features, each time a new developer takes over, he is going to have to relearn what the original developer already knows.

Poor quality

The earlier you find bugs and fix them the less costly it is for the organization. The most expensive scenario is when you find problems once they’re already deployed to production. Partly this is due to the fact that the developer now has to reacquaint himself/herself with the code again. So if the developer spends the time upfront to write extensive unit tests, if the team takes the time to define proper acceptance test criteria then the chances of having to rework the code and worse yet relearn the code diminishes significantly

Task switching

The more things you throw at a developer at the same time the longer things take to get done. Task switching beyond 2 tasks is highly inefficient as the developer has to more often than not relearn or re-acquaint himself with the task context each time he switches back.

Poor communication and recording of knowledge

Today, with the proliferation of technology, there’s no excuse for poor communication. Wiki’s provide a great way for developers to record knowledge about their findings. And search makes it really easy to find information. I am not advocating heave documentation here. I am suggesting short summaries of information on key decisions you made during development so that if someone else has to take over or you have to come back to that code in the future, the relearning curve is not that great.

Stay tuned for next weeks blog post in this series which will cover the 4th waste – the equivalent of “Transportation” in manufacturing processes.

Hacking code ownership

Two weeks ago I wrote an article about the virtues of sharing code in teams. Just to confuse you, this week I want to tell about a situation where code ownership actually helped me introduce a couple of agile engineering practices in a team I worked with some time years ago. Here’s the story. Facts, names and situations have been twisted a bit to ensure the client’s privacy.

The project
When I got started on this project the team had already been working on the code for some time. They didn’t have strict rules about code ownership but most developers had started on their own piece of code at the beginning of the project and had kept on working in the code they knew as the project went on. When I joined the team everyone had a well defined layer of the application to call their own. I got to work on the UI layer.

On previous assignments I had tried introducing TDD and pair programming. But I often ran into problems. Maintaining a set of tests is hard when your co-workers change your code and don’t fix tests when they break. You end up spending extra time fixing the tests other people break and it’s hard to convince people to do TDD when it’s costing you so much work.

Introducing TDD
But now things were different, no-one touched code. I was free to start writing unit-tests. At first this wasn’t easy. UI’s are never easy to test. But I started slowly refactoring all the screens I worked on to extract the presentation logic to separate presenter classes that I could test. Slowly my test coverage got better and slowly my code got cleaner making it easier for me to implement new features.

Introducing Pair programming
Code-ownership also created extra dependencies within the team. Changes in the code usually went right across the artificial boundaries. This created an ideal opportunity for me to introduce pair programming. If someone wanted me to implement something I’d invite them to sit behind the computer with me to help me figure out what I needed to build. I was actually kinda surprised how quickly people picked up this habit.

Because I actually had the chance to be successful with TDD and because pair programming gave me the opportunity to show this off to my team members they started picking this up. The guy responsible for the data-layer actually had been doing TDD on his personal projects but had had difficulty doing it over here because most of his code was tightly bound to the database. I helped him separate the logic he wanted to test from the pure data-access code and helped him get started using Rhino-Mocks, a .Net mocking framework.

Because my contract ended I didn’t see that project through to the end. I heard they started sharing code more when they got more comfortable with each others code through pair programming and they were experimenting with continuous integration now.

The retrospective
Lets do a project ‘retrospective’ and see what we can learn. Should or shouldn’t we get rid of code ownership? I think we should, eventually, but whenever you get rid of something you should think of the value it brings first.

In his book Working Effectively with Legacy code Michael Feathers talks about using an anti corruption layer to shield our newly written code from getting corrupted by bad design decisions made in legacy parts of our system. These layers are a temporary fix, as the old code is upgraded to new quality standards, piece by piece it slowly move and eventually become unnecessary. Sometimes we also need an anti corruption layer in our teams and ironically code ownership, a practice I criticised in my article two weeks ago, gives us the means to implement such a layer.

Another thing that surprised me here was how easy it was to get people to do agile practices when they were introduced at the right pace in the right order. ‘Refactoring’ a team to agile instead of trying to become agile in one big leap actually has helped me more often. When you take small steps and be careful to take the step that brings the most value every time acceptance is easier and faster and that will make sure people will keep on improving even when you’re gone.

Agile is Dead

The agile revolution has won. There is no doubt about it. No longer are its evangelists the pioneers who blaze new trails and chart the unknown, like they used to a couple of years ago. Agile principles, methodology, tool sets, even agile lingo, have become mainstream. Frankly, everybody and their dog is “doing agile” these days. Of course, there are pockets of resistance in the more backward (or “conservative” to be more polite) companies, but they are destined to eventually see the error of their ways and switch over. Even the most pointy haired of pointy haired bosses know that if they don’t learn, accept and embrace agile methodologies, they are doomed to very soon become everybody’s laughing stock, not to mention their careers are going to go down the drain.

And that my friends, is agile movement’s doom. The revolution is over. The establishment has struck back, as it usually does, using the strategy it always chooses – assimilation, dilution, extermination.

These days, you can call everything “agile”, even the most ridiculously non-agile concepts and get away with it (“agile RUP”, anybody?). See, the problem is that the PHBs that decided that they absolutely have to “go agile”, at the same time decided that they don’t really want or need to change their habits – instead they will just re-dress and rename their usual processes and culture. Which obviously means two things:

  • buying yourself an expensive, yet “agile” tool set, so as to justify inflated budgets
  • getting a bunch of costly certification or two, so that nobody higher up in the food chain can claim they are not “agile”

I have noticed quite a few comments on this site, typically posted by the “foot soldier” developers, that “this whole ‘agile’ thing is same old, same old. All it does is bring us more meetings, more reporting, more micro management”. How typical. Agile processes are being introduced in companies without paying attention to the absolute fundamental need for a culture shift – it really is “same old, same old”, it is just dressed funny. The end result is that teams mindlessly follow “agile” process steps, because the expensive, certified consultant told them to, or a costly tool, mandated by the upper management, forces them to. And they fill out more and more paperwork — even more than they used to before they went agile. Unit test reports (usually hand-filled in Excel). Ridiculously detailed time tracking. Insanely elaborate acceptance criteria for user stories. Torture of daily standups (an hour of it every day, with mandatory report-out to management). It is all in there. There is not a trace of principles of communication, respect, trust, self-organization left in such teams (it has never been there in the first place), they do not evolve to becoming creative and effective, but they are still “agile” and they can prove it! They are certified!

And quite honestly, we have brought this upon us ourselves. Instead of concentrating on spreading the word about the principles – which is hard, because traditionally-bred teams and managers have trouble understanding, not to mention converting – the agile community has concentrated on proliferating certifications. Certified Scrum Master? Scrum Practitioner? Scrum Trainer? Grand Klan Master? Chief Lizard Wrangler? Cappo di Tutti Cappi? Sure, why not, just shell our a bunch of monies and sit there for two days, pretending to listen to some bloke that already is certified by us. Admit it – it is a Ponzi scheme. There is no proof whatsoever that becoming “certified” makes you a better developer or project manager – but it does mean that the thing is easier to sell to top level management. ISO certifications and CMMI server the same purpose – improving the chances of selling consulting services to managers. And of selling software to customers (“gee, they must be good, they have ISO 9001 and CMMI 5, let’s buy from them”).

It does not stop there. Soon, agile is going to have a “maturity model” of its own – backed by IBM, no less. Who cares if it is worthless — it is from IBM, so it is “professional”, right? I wouldn’t be surprised if the next move is for some big player to simply go out and acquire trademarks to all relevant agile processes – “Scrum(TM) and you can only use it under license form Microsoft”? “XP(TM) brought to you by IBM (and we better not catch you using it without paying us)”. Why not? What’s to stop them?

The revolution is over. It is time for a new one.

Or is it? I invite you to a discussion. Convince me that I am wrong.