Posted: March 25th, 2012 | Author: greger | Filed under: Professionalism | Tags: agile manifesto, agile software development, unagile manifesto | 1 Comment »
The so called Agile Manifesto has created so much excitement in the software development world and beyond. It is time that all those who oppose Agile methods in software development got their own manifesto and here it is. The unagile manifesto:
The Unagile 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.
Posted: March 23rd, 2012 | Author: greger | Filed under: Project Management, Software Engineering | Tags: agile software development, continuous integration, research results, scrum, xp | No Comments »
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
A stereotypical view of a team of Indian agile offshoring engineers. By C. Frank Starmer. Used under a creative commons license. Click image for details.
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.
Iteration Demos
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
-
J. M. Bass, "Influences on Agile Practice Tailoring in Enterprise Software Development," Agile India, pp. 1-9, 2012.
@article{citeulike:10477962, abstract = {Agile development projects have become a reality in large enterprises using offshore development models. A case study involving seven international companies with offices in Bangalore, India, and London, {UK} was conducted, including interviews with 19 practitioners. The contribution of this paper is to illustrate the reasons for tailoring Agile practices within the context of large enterprises. The findings show that scrum roles and practices did not conflict with enterprise policies or processes and were thought to improve product quality and productivity. However, agile practices from the {XP} tradition were not so widely adopted. Test driven development did not integrate well within enterprises where independent quality assurance teams were constituted as separate departments. Continuous integration was found to be challenging where enterprise software products required time consuming regression testing and elaborate code release processes. While adoption of coding standards and collective code ownership are necessary to facilitate interaction between disparate stakeholder groups.},
address = {Los Alamitos, CA, USA},
author = {Bass, Julian M.},
citeulike-article-id = {10477962},
citeulike-linkout-0 = {http://doi.ieeecomputersociety.org/10.1109/AgileIndia.2012.15},
citeulike-linkout-1 = {http://dx.doi.org/10.1109/agileindia.2012.15},
doi = {10.1109/agileindia.2012.15},
isbn = {978-0-7695-4657-5},
journal = {Agile India},
keywords = {20120320c},
pages = {1--9},
posted-date = {2012-03-20 05:31:50},
priority = {2},
publisher = {IEEE Computer Society},
title = {Influences on Agile Practice Tailoring in Enterprise Software Development},
url = {http://dx.doi.org/10.1109/agileindia.2012.15},
volume = {0},
year = {2012}
}
Posted: March 22nd, 2012 | Author: greger | Filed under: Project Management | Tags: agile software development, continuous improvements, leagile, lean | No Comments »
Joe Dager from the Business 901 blog and podcast is someone who has covered the cross-breeding of lean and agile more than most people.
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”.
References
-
B. Swaminathan and K. Jain, "Implementing the Lean Concepts of Continuous Improvement and Flow on an Agile Software Development Project: An Industrial Case Study," Agile India, pp. 10-19, 2012.
@article{citeulike:10477940, abstract = {The idea of applying lean principles to software development has been gathering a lot of interest over the last decade. Several books have been published exploring the lessons learned from manufacturing around lean. Some books have also taken the principles of lean manufacturing and provided the guidelines for adapting the same to software development. However, there is still a huge need for providing empirical evidence of application of lean principles to software development through real case studies. This paper attempts at making a contribution in that direction, by exploring the implementation of the ideas of continuous improvement and flow, which are so central to lean, on a real life industrial project. Besides exploring the practices that aid these concepts in agile software development, this paper also discusses some of the metrics that can be used for measuring and tracking progress of such a project. The study shows that applying the concepts of continuous improvement and flow to agile software development does seem to have significant benefits, and is something that needs to be extended further and applied to different project situations.},
address = {Los Alamitos, CA, USA},
author = {Swaminathan, Balachander and Jain, Karuna},
citeulike-article-id = {10477940},
citeulike-linkout-0 = {http://doi.ieeecomputersociety.org/10.1109/AgileIndia.2012.12},
citeulike-linkout-1 = {http://dx.doi.org/10.1109/agileindia.2012.12},
doi = {10.1109/agileindia.2012.12},
isbn = {978-0-7695-4657-5},
journal = {Agile India},
keywords = {20120320b},
pages = {10--19},
posted-date = {2012-03-20 04:56:40},
priority = {2},
publisher = {IEEE Computer Society},
title = {Implementing the Lean Concepts of Continuous Improvement and Flow on an Agile Software Development Project: An Industrial Case Study},
url = {http://dx.doi.org/10.1109/agileindia.2012.12},
volume = {0},
year = {2012}
}
-
X. Wang, K. Conboy, and O. Cawley, "” Leagile” software development: An experience report analysis of the application of lean approaches in agile software development," Journal of Systems and Software, vol. 85, iss. 6, pp. 1287-1299, 2012.
@article{citeulike:10423481, abstract = {In recent years there has been a noticeable shift in attention from those who use agile software development toward lean software development, often labelled as a shift ” from agile to lean”. However, the reality may not be as simple or linear as this label implies. To provide a better understanding of lean software development approaches and how they are applied in agile software development, we have examined 30 experience reports published in past agile software conferences in which experiences of applying lean approaches in agile software development were reported. The analysis identified six types of lean application. The results of our study show that lean can be applied in agile processes in different manners for different purposes. 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.},
author = {Wang, Xiaofeng and Conboy, Kieran and Cawley, Oisin},
citeulike-article-id = {10423481},
citeulike-linkout-0 = {http://dx.doi.org/10.1016/j.jss.2012.01.061},
doi = {10.1016/j.jss.2012.01.061},
issn = {01641212},
journal = {Journal of Systems and Software},
keywords = {20120320b},
month = jun, number = {6},
pages = {1287--1299},
posted-date = {2012-03-20 04:56:03},
priority = {2},
title = { ” Leagile” software development: An experience report analysis of the application of lean approaches in agile software development},
url = {http://dx.doi.org/10.1016/j.jss.2012.01.061},
volume = {85},
year = {2012}
}
Posted: February 21st, 2012 | Author: greger | Filed under: Project Management, Software Engineering | Tags: agile project management, agile software development, project management | 2 Comments »
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.
Newton wood has some huge ant hills - this is one of them. © Copyright Brian Henley and licensed for reuse under a Creative Commons Licence, click image for details.
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.
Posted: February 14th, 2012 | Author: greger | Filed under: Project Management, Requirements Engineering | Tags: agile, agile software development, backlogs, requirements, scrum, user stories, user story, WBS, work breakdown structure | 2 Comments »
Someone probably told you that you must have user stories to be Agile, right? I would have you consider what kinds of stakeholders and requirements you have and are trying to meet.
Is there a clear user for each piece of work you are supposed to do? If that is the case you can use user stories. User stories is one style of requirements but is not always the best style for requirements. I am not totally clear about what the scope of your project is but I am suspecting that there is not always clear a user as you have problems to formulate the user stories.
Scrum and other agile methods do not require or mandate that you use the user story style. That is why items in the backlog are simply called “backlog items”. Whatever style you choose for your requirements and backlog items it is important that you make sure that the backlog items have the INVEST properties. If they don’t, it will be harder to be agile. But they don’t have to be written in the “user story” style.
Posted: January 17th, 2012 | Author: greger | Filed under: Project Management, Requirements Engineering | Tags: agile software development, backlogs, bugs, change management, change requests, configuration management, requirements, requirements management | No Comments »
There are change requests and then there are change requests. All change requests are not created equal and should not be treated the same way. In this post I will describe the two major types of change requests as I see them and why you need to treat them differently.
Change Requests in Traditional Software Development
Let’s start with a small history of change requests and how they were used in what I sometimes call “traditional software development”. Traditional software development projects often work like this:
- A set of requirements is created.
- After careful analysis etc the requirements are baselined or frozen.
- As time goes by, the baselined requirements need to be changed.
- The person wanting to change something needs to create a change request (CR) which is then handled by a change control board.
The idea is that a stable set of requirements Read the rest of this entry »
Posted: January 12th, 2012 | Author: greger | Filed under: Software Engineering | Tags: agile software development, maintainability, research results, source code metrics | No Comments »
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?
References
-
P. HegedHus, T. Bakota, L. Illés, G. Ladányi, R. Ferenc, and T. Gyimóthy, "Source Code Metrics and Maintainability: A Case Study Software Engineering, Business Continuity, and Education," , Kim, T., Adeli, H., Kim, H., Kang, H., Kim, K. J., Kiumi, A., and Kang, B., Eds., Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, vol. 257, pp. 272-284.
@incollection{citeulike:10216018, abstract = {Measuring high level quality attributes of operation-critical {IT} systems is essential for keeping the maintainability costs under control. International standards and recommendations, like {ISO}/{IEC} 9126, give some guidelines regarding the different quality characteristics to be assessed, however, they do not define unambiguously their relationship to the low level quality attributes. The vast majority of existing quality models use source code metrics for measuring low level quality attributes. Although, a lot of researches analyze the relation of source code metrics to other objective measures, only a few studies deal with their expressiveness of subjective feelings of {IT} professionals. Our research involved 35 {IT} professionals and manual evaluation results of 570 class methods of an industrial and an open source Java system. Several statistical models have been built to evaluate the relation of low level source code metrics and high level subjective opinions of {IT} experts. A decision tree based classifier achieved a precision of over 76\% during the estimation of the Changeability {ISO}/{IEC} 9126 attribute.},
address = {Berlin, Heidelberg},
author = {Heged\H{u}s, P\'{e}ter and Bakota, Tibor and Ill\'{e}s, L\'{a}szl\'{o} and Lad\'{a}nyi, Gergely and Ferenc, Rudolf and Gyim\'{o}thy, Tibor},
chapter = {28},
citeulike-article-id = {10216018},
citeulike-linkout-0 = {http://dx.doi.org/10.1007/978-3-642-27207-3_28},
citeulike-linkout-1 = {http://www.springerlink.com/content/m4p61121x530r527},
doi = {10.1007/978-3-642-27207-3_28},
editor = {Kim, Tai-hoon and Adeli, Hojjat and Kim, Haeng-kon and Kang, Heau-jo and Kim, Kyung J. and Kiumi, Akingbehin and Kang, Byeong-Ho},
isbn = {978-3-642-27206-6},
keywords = {20120112a},
pages = {272--284},
posted-date = {2012-01-12 13:26:40},
priority = {2},
publisher = {Springer Berlin Heidelberg},
series = {Communications in Computer and Information Science},
title = {Source Code Metrics and Maintainability: A Case Study Software Engineering, Business Continuity, and Education},
url = {http://dx.doi.org/10.1007/978-3-642-27207-3_28},
volume = {257},
year = {2011}
}
-
G. Wikstrand, "Human factors and wireless network applications : more bits and better bits," PhD Thesis , 2006.
@phdthesis{citeulike:10216067,
author = {Wikstrand, Greger},
citeulike-article-id = {10216067},
citeulike-linkout-0 = {http://www.ub.umu.se/sok/bocker/album},
isbn = {91-7264-205-X},
keywords = {20120112a},
posted-date = {2012-01-12 13:46:48},
priority = {2},
title = {Human factors and wireless network applications : more bits and better bits},
url = {http://www.ub.umu.se/sok/bocker/album},
year = {2006}
}
Posted: January 9th, 2012 | Author: greger | Filed under: Professionalism | Tags: agile software development, mindset, mission-type tactics | No Comments »
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. Read the rest of this entry »
Posted: December 19th, 2011 | Author: greger | Filed under: Professionalism, Software Engineering | Tags: agile software development | No Comments »
Seems the last few days have been full of discussions about what is fake and what is real. A Facebook friend posted an image of a hunter, an elk and a cougar. Turns out it is fake. I read in the newspaper about how larger clothes manufacturers send “samples” of smaller companies collections as “inspiration” to off-shore manufacturers.
On You Tube, everything can be faked...
So, what does this have to do with Agile Software Development? Read the rest of this entry »
Posted: December 14th, 2011 | Author: greger | Filed under: Professionalism, Software Engineering | Tags: agile software development, legacy code, software development | No Comments »
Legacy Code… We all love to hate it. We all have it. Some of us keeps creating it. How do you deal with it once you have it? Sometimes we find problems with it. But then, what do we do? A colleague at Capgemini, Paul Oldfield, suggested I should read “Working Effectively with Legacy Code
“. I have not done so yet, but if you have, please give your comments below.
A Waterfall is Fine – for Watching
Wordle for March 2012
Waterfall got it right… almost