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
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
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
There are change requests and then there are agile change requests. Now, I hear some of you saying to yourselves: “He is crazy, there is no such thing as ‘agile change request’!” You are right, partly, I agree that agile methods were designed to avoid change requests. But! All change requests are not created equal and should not be treated the same way. In this post I will describe two major types of change requests as I see them and why you need to treat them differently in agile software development. Hopefully, after reading this you will have a better idea on how to handle change requests in agile methodology. Continue reading
I did my Ph.D. thesis on how network factors can predict and influence user satisfaction in wireless networks. I.e. how “hard” but low-level technical factors have an impact on more abstract entities.
Hegedűs et al does something similar but for source code metrics and their impact on maintainability. It has long been maintained by the software development community that cyclometric complexity and so on will have a high impact on maintainability. Maintainability is important for agile software development!
So do source code metrics predict maintainability? According to the article “A decision tree based classifier achieved a precision of over 76% during the estimation of the Changeability ISO/IEC 9126 attribute.” But how large is the effect?
What makes Agile Software Development methods different from Traditional Software Development methods? There are the obvious answers related to different techniques used, e.g. early integration rather than late integration or dividing the problem space from the client perspective (user stories) rather than the technology perspective (client-middleware-database). But essentially the major difference is in the mindset. Continue reading