I love configuration management! “But”, you ask, “isn’t configuration management boring?” Well, configuration management can be boring and tedious if you do it manually. With modern tools it is not all that bad. Even if it is boring, that is out-weighed by the sheer importance of proper agile configuration management for a successful software development team. Continue reading →
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.
In a small study, three different projects were examined with respect to the degree that they used eXtreme Programming practices and what the code looked like in terms of size, complexity and coupling. The conclusion was that more agile practices used in a project lead to lower size, complexity and coupling in the product. The study is too small for any definitive conclusions but it is evidence pointing in the right direction.
Traditional agile user stories are on the form: “As a user I want to xxx so that I can yyy”. A simple example would be “as a mobile phone user I want to make a phone call to my mistress so that I can arrange our next meeting”. But hey, who cares why I am making the call? Who even cares whom I call? Can we have a little privacy here!
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.
The usual agile requirements life cycle consists of three simple states: “not started”, “in progress” and “done”. This is not enough! These steps only cover the software development part of the requirements life cycle. Do not forget about the stages before and after. First requirements are new, then they are analyzed and estimated, then they are commited for delivery in a sprint. After that comes the states mentioned above. After that comes release, deployment, maintenance and eventually retirement. Have a look at the Requirements Abstraction Model.
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 →
Is it appropriate to call a driver's license a unit test? Would that be consistent with unit testing best practices? That was part of the discussion that erupted on our internal Yammer network after… »
As humans we love the majesty of nature. Who can fail to be impressed by such majestic cataracts as the Niagara falls or the Victoria falls? Someone said that falling is fine, it's hitting the ground… »