You don’t Need “User Stories” to be Agile

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.

Do We Listen too Much to the “Business”?

Yesterday I watched a documentary on National Geographic about the infamous Sampoong Dept Store Collapse. It immediately got me thinking of some of the threads running here on testing and the business case for testing. In Agile and in our industry in general we always say that fulfilling business requirements are our top priority…
Read the rest of this entry »

Agile Change Requests

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:

1. A set of requirements is created.
2. After careful analysis etc the requirements are baselined or frozen.
3. As time goes by, the baselined requirements need to be changed.
4. 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 »

Can Source Code Metrics predict Maintainability?

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

• [2011,incollection] bibtex
  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}
}
• [2006,phdthesis] bibtex
  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}
}

Backlog Prioritization for Value Based Agile Software Engineering

Sprint burndown chart by tö, on Flickr. Used under a Creative Commons license, click image for details.

Fake or Real Agile?

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 »

Legacy Code

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.

12 Key Agile Practices

Which are the key agile practices? Researchers José Fortuna Abrantes and
Guilherme Horta Travassos combed the research literature and were able to identify
12 key agile practices:

• test driven development,
• continuous integration,
• pair programming,
• planning game,
• onsite customer,
• collective code ownership,
• small releases,
• metaphor,
• refactoring,
• sustainable pace,
• simple design and
• coding standards

References

• [2011,article] bibtex
  J. F. Abrantes and G. H. Travassos, "Common Agile Practices in Software Processes," Empirical Software Engineering and Measurement, International Symposium on, pp. 355-358, 2011.
  @article{citeulike:10098906, abstract = {Objective: to investigate studies about software processes looking for practices which can be used to obtain agility in software processes. Method: A systematic review including seven search engines was executed in Feb/2010. To apply the defined criteria to select papers and extract information regarding working practices bringing agility to software processes. Results: from 6696 retrieved papers, 441 were selected to support the identification of 236 occurrences of 51 distinct practices associated with the concept of agility. Their descriptions were deeply analyzed and consolidated. After discarding those which appeared in the technical literature in a small amount of papers, 17 agile practices were identified. Conclusion: although further studies are necessary to evaluate the efficacy of these 17 agile practices, 12 of them have been more commonly approached in the software projects and could be primarily considered: test driven development, continuous integration, pair programming, planning game, onsite customer, collective code ownership, small releases, metaphor, refactoring, sustainable pace, simple design and coding standards.},
  address = {Los Alamitos, CA, USA},
  author = {Abrantes, Jose F. and Travassos, Guilherme H.},
  citeulike-article-id = {10098906},
  citeulike-linkout-0 = {http://doi.ieeecomputersociety.org/10.1109/ESEM.2011.47},
  citeulike-linkout-1 = {http://dx.doi.org/10.1109/esem.2011.47},
  doi = {10.1109/esem.2011.47},
  isbn = {978-0-7695-4604-9},
  journal = {Empirical Software Engineering and Measurement, International Symposium on},
  keywords = {20111206},
  pages = {355--358},
  posted-date = {2011-12-06 13:36:55},
  priority = {0},
  publisher = {IEEE Computer Society},
  title = {Common Agile Practices in Software Processes},
  url = {http://dx.doi.org/10.1109/esem.2011.47},
  volume = {0},
  year = {2011}
}

Why do you need requirements?

Why do you need requirements? To facilitate collaboration! Great podcast from IBM Rational – if you ignore the over commercial cheesy phrases at the end.

10 Things I hate about ALM – Part 3

Agile Practices Reduces Software Development Issues

In a large study of the effects of switching to agile ways of working at a unit of Ericsson in Sweden researchers Kai Petersen and Claes Wohlin found a number of issues with Agile Software Development but far fewer than with the previous plan driven approach. The table below shows the issues found with the plan driven approach and the agile approach respectively. Issues are rated by their severity and frequency on the following scale “general problem”, “very common problem” and “common problem”.
Read the rest of this entry »