Why do some people distrust agile software development? Should you distrust agile software development? How can you possible trust people who say that they will “take your money and deliver something” after a month or so? How can you possible trust people who have a rubber bird as part of their continuous integration process? After my recent post on trust in agile software development, Mike Lehr asked me why people distrust agile software development.
In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to client to come out with what they expect to achieve from a Project.
Image above depicts the Fibonacci series, which is used as one of the sizing techniques for User stories.
How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much . Typical rules of thumb figures for software development requirements change rate is cited as 1-3% . But the rate of change is accelerating. In 2002, 10% was not uncommon . How high is it now?
Continue reading Change is the only constant in agile
Generalists versus specialists — it is an ongoing debate. Is it better with generalist or specialist team members in agile software development or elsewhere? Continue reading Generalists versus Specialists in Agile
So people keep talking about the Agile – Waterfall dichotomy. About agile and un-agile practices. I decided to have an unscientific look at what Agile isn’t. If there is a true dichotomy between Agile and Waterfall, then things opposite of Agile should be either entirely out of scope for projects and software development or they should be characteristic of Waterfall methods. And since anyone would bother to mention them in the context of Agile, one would assume that this would be because they are distinguishing between Agile and Waterfall. Continue reading Agile is NOT new and not enough
The so called Agile Manifesto has created so much excitement in the software development world and beyond. But for all those who got their life ruined by agile, for all those who oppose Agile methods in software development — it is time they got their own manifesto. Here it is — The un-agile manifesto.
The Un-agile Manifesto
We are rediscovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Follwing a plan over responding to change
- Contract negotation over customer collaboration
- Comprehensive documentation over working software
- Process and tools over individuals and interactions
That is, while there is some supposed value in the items on the right, we value the items on the left more. The Unagile Manifesto is based on the Unagile Principles.
Following a Plan
Responding to change is a bit of a joke. We known since time immemorial that there are no changes. “There is nothing new under the sun.” So what is change? It is just an attempt to create confusion and sabotage the project. It is better to stick to the plan.
Customer collaboration is just another way to try to introduce changes into the project. A contract is what you have to guarantee to yourself and the customer that they get exactly what they pay for.
How long will your software keep working if it is not documented?
Process and Tools
In hobby-sized projects people can chat and be nice, in industrial strength projects it is necessary to use processes and tools to align people and products.
This post was updated on 2013-12-18 with a rationale for each item in the manifesto.
How is Agile offshoring done in practice? Julian Bass studied seven different companies doing off-shoring London-Bengaluru. He had expected that the companies would have adapted a continuum of practices from Scrum and XP.
Findings about Agile Offshoring
To his surprise he found that this was not true. Instead, all of the companies had adopted scrum with the exception of iteration demos. All companies did enforce coding standards. This was not really related to agile practices. It was a corporate standard enforced regardless of agile. All companies also claimed that they had collective ownership of code. There were two projects which did pair programming and TDD; none of the others did. Finally, only one project / company had implemented any other XP practices, most notably Continuous Integration. So, is the cost of continuous integration too high for your agile offshoring project?
Continuous Integration for Agile Offshoring
There were two agile practices that I missed most. Only few of the agile offshoring project did iteration demos or continuous integration. Continuous integration requires a lot of work to setup and maintain. But the alternative, late and manual integration is so risky and complicated. Agile software development methods are very much about avoiding building up a debt of unfinished work. It is also about doing the most risky things first. Extreme programming has the right attitude about continuous integration. Regardless if you are in an agile offshoring project or not you should always do continuous integration. You do not need to do test driven development (TDD) to do CI. Just having a build running is enough to catch many errors.
Why did so few agile offshoring projects perform iteration demos? I have always found that iteration demos are really useful. They provide an opportunity to interact with the users. To gather feedback from the users. To make sure that they actually look at it before it is to late. This should be more, not less important in agile offshoring. When you are far from the user you should spend more time on iteration demos, not less. Be extreme, try doing it twice per iteration. I have tried and it really worked.
References for Agile Offshoring
So how does one apply Lean to agile software development? Wang, Conboy and Cawley examined thirty experience reports and came to the following conclusion:
Lean concepts, principles and practices are most often used for continuous agile process improvement, with the most recent introduction being the kanban approach, introducing a continuous, flow-based substitute to time-boxed agile processes.
But does that help? According to Swaminathan and Jain it “does seem to have significant benefits”.
Many people and companies think of Agile as some kind of Laissez-Faire approach to project management and software development. Agile is in fact a very rigid structure on how to do things so that there may be flexibility in what to do.
Agile project management is based on advanced project management concepts such as earned-value management (EVM) and phased rolling planning.
Agile software development is based on continuous quality control, other practices that are known to generate quality and a tight feedback loop with stakeholders.
There is no grand master plan or architect for an ant hill. Ants simply follow simple behavioural rules. The ant hill emerges as a result of millions of ants mindlessly following these rules.
Someone probably told you that you must have user stories to be Agile, right? But really, you don’t need user stories to be agile! I would have you consider what kinds of stakeholders and requirements you have and are trying to meet. Continue reading You don’t Need User Stories to be Agile