3. For any project, if you have not done deliverable-based planning, you are in a disaster. You just don't know it yet. In agile, this means you do a demo at the end of an iteration. For kanban, you do demos when you have finished a feature. For a more traditional project, you build in demos or other deliverables at regular milestones.
If you have done deliverable-based planning, and you see no deliverables, you are in trouble. You should always be able to see a deliverable of some sort.
4. Ask the people on the team what their
confidence level is in the schedule. Ask them anonymously. If they
start to have less than 80% confidence, you are in trouble. You can do this for any project.
5. If you have no release criteria, you are in a disaster. I'm not fond of changing release criteria, because it feels as if you are chasing a butterfly. But, if you can't meet the current release criteria for some reason, change them to something you can meet. Release criteria are not stretch goals; they are criteria you expect to meet.
If you see any of these signs on your project, act. Write a charter with a vision and release criteria. Make sure you have a servant leader for the team. Develop deliverable-based milestones. Ask the people on the project what their confidence level is.
Now, you have a shot of avoiding disaster.
Gil Zilberfeld, an agile practices expert, has posted on 4 warning signs that Agile is declining. I will not re-iterate his points; you should read the article for yourself. The overall theme though is this. The software establishment - including the managers, the consultants, the trainers, the vendors - has embraced Agile, to the extent that, according to Zilberfeld, more than half of software projects at least nominally use Agile methods. The results are disappointing though, because companies have simply absorbed bits of Agile into their existing top-down management culture. Therefore:
At this point, I feel Agile is declining into what TQM [Total Quality Management] was. A brilliant success in the beginning, and now just a history fact. In a few years, months even, the business side will wake up and say: Agile is snake oil. It doesn't deliver on its promise (and it doesn't matter if it's done wrong). The backlash will be grand.
I am reminded of something I learned from one of the excellent QCon conferences in London, which covers Agile in depth. It was not so much a specific speaker or talk, more a common theme running through many presentations. Software projects generally do not fail for technical reasons. They fail because the team - using the word team in its widest sense, to include all project stakeholders from users to executives - fails to communicate effectively. Many Agile techniques, such as the daily meeting which is part of the Scrum methodology, are designed to facilitate communication. I have also heard recommendations such as moving developers into the same office as managers in order to get them talking to each other. Another example, at a micro level, is Pair Programming, where two developers work side by side on the same code. You cannot do this without communicating your intentions, ideas and solutions to the person alongside you.
Kent Beck, one of the pioneers of Extreme Programming and Test Driven Development, highlights the human factor in software development. Take a look, for example, at his essay on Accountability in Software Development:
... while programming I offer accountability as a way of demonstrating my trustworthiness and encouraging my own best behavior. Pair programming; test-first programming; continuous integration; visible daily, weekly, and quarterly cycles; slack; and estimation are some of the way I make public commitments and render account of my activities. Knowing I will be honest and accountable affects how I do my work, just as knowing that I am hiding and concealing negatively affects how I do my work. Taking responsibility for my choices and actions deflects blame. There is no hidden shame if everything I do is above board.
What is important here is not the techniques in themeselves, but the trustworthiness and accountability they facilitate.
Human problems are harder to solve than technical problems, and seen in this light it is not surprising that companies which adopt bits of Agile methodology without changes in corporate and management culture will miss out on most of the benefits.
Another common experience at software development conferences is to talk to developers who enthuse over the insights they have received, but then lament that they cannot be applied in their workplace. The reasons are old and familiar: inflexible management, longstanding broken processes that nobody seems able to fix, little kingdoms which protect their borders at the expense of the effectiveness of the whole corporation, and so on.
A few thoughts in conclusion. First, if Agile projects are failing, that does not necessarily imply that something is wrong with Agile methodology. It all depends on how it is done and whether the people involved are embracing or resisting the change and communication that goes along with it. Second, irrespective of the methodology, effective communication is key to the success of a project; and if it is not possible to change the methodology or even the tools and technology, working on team communication may still yield amazing results.
4 people, (16-4)/2=6That means the number of paths for up to 8 people is still manageable (24), but once you get to 9 people, it becomes 36 paths, which is high. For 10 people, the number of paths is 45, which is unmanageable for most of us. Can some people manage this number of communication paths? Sure. But not many of us, which is the problem. That's why "teams" of 10 people don't work.
5 people, (25-5)/2=10
6 people, (36-6)/2=15
7 people, (49-7)/2=21
8 people, (56-8)/2=24
9 people, (81-9)/2=36
10 people (100-10)/2=45