What’s Agile for Drivers? I have always been driving kind of ad hoc. Getting from A to B with no particular plan. If I were a programmer you would call it “cowboy coding” but I’m not, so we can call it “cowboy driving”. People, everyone it seemed – my boss, my wife, my children, the odd passengers, were all complaining that I needed to use sound engineering principles and state of the art equipment to improve my driving skills. “It will help you get from level 1 to level 2 or even 3″, they said. Read the rest of this entry »
Can we make Agile work in regulated industries? That is the topic of an upcoming webinar. I find this a bit ironic. Can we make Agile not work in regulated industries? Did Agile cause the Ariane V crash or was it “GRC (governance, risk and compliance)” that caused it?
The Ariane 5 Crash – due to a lack of Agile
You will find the full and official crash investigation report here. Too summarize a major culprit in the crash was the project management methods and software engineering practices employed. Basically, some components were changed in terms of their output. Other entities were not modified regarding their corresponding inputs which caused a “range check error” which lead to a cascade of failures.
Could that have happened in an agile environment with test first mentality, continuous integration etc? Surely not. So what is the value of “GRC” if it does not lead to safer products? Colleagues in highly regulated industries tell me they have already moved to Agile with marked benefits.
Conclusion
So why is there still a discussion on if we should adapt Agile in this or that place? Probably due to misconceptions. Misconceptions about Agile being some kind of cowboy style development practice. Misconceptions about the excellence of the organization in question and how effective it really is in software development, compliance to waterfall/agile etc.
Using Agile in “highly regulated” industries should be a no-brainer. The Ariane 5 explosion is a good counter-example.
Does your waterfall look like this? By a n a n d h a m, on Flickr. Used under a creative commons license, click image for details.
I am not going to write a whole lot on waterfall versus agile but… An interesting point that is worth reiterating. Waterfall software development processes can remind us of many of the important steps in software development. The difference is not so much in what we do as in how, when and what order.
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.
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:
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}
}
When you are building a home it is often quite possible to know in advance exactly which steps to take and in which order. You simply cannot start with the roof, continue with the walls and finish with the basement. You cannot apply the wall paper before the walls. Furthermore, you can easily predict how much time is required for applying X square meters of wall paper, or Y roof tiles etc. There are manuals available for project managers containing a wealth of data on standard work and its cost etc. In effect, it is possible for a competent construction project manager to create a plan for a project like this and to follow it with no small chance of success.
In software engineering on the other hand, things are a lot more difficult to predict. You cannot know in advance how long it will take to implement requirement X. This is because you are not assembling house number 1000 in a long line of identical houses. The whole idea of software engineering is to take something which is more or less unknown and transform it into something well known. So while designing the software is not really a predictable process impressing it on a CD and shipping it is.
Risks Levels Have Increased
Well, it turns out that the construction industry is not all that predictable anymore either. According to Everts et al. a lot has happened in the construction industry in recent decades. Where there used to be 70% of construction taking place on virgin land at the edge of the city with relatively predictable conditions there is now 70% of construction taking place in already built-up areas with of course a much higher level of unpredictability. Also, at least 50% of construction work is not new buildings but repairs, remodelling and the like. Working with old buildings is naturally much more prone to surprises, just like working with old software…
So far, the response of the construction industry have been to increase bureaucracy by generating more paper work for incident reports, change requests etc. If you are in the software industry, you will recognize this instantly…
… Move to Agile
Everts et al. takes things one step in another direction by surveying which skills would be needed and/or are lacking among construction project managers and building project managers in order to be able to work in a more agile way. They lists skills such as:
Negotiation skills
Cultural awareness
Conflict management
Conclusion – Not a Waterfall any Longer
Skills which are equally useful for a software engineer or manager! And that’s not all. With smart buildings the software component of the construction work is increasing. Intelligent building of intelligent buildings will be a new and major challenge for the construction industry. I guess I will soon have to switch to another example when I want to explain under which circumstances a non-agile project management style is most appropriate.
P. Everts, F. Pries, and S. Nijhuis, "Towards Agile Project Management and Social Innovation in the Construction Industry," in MISBE2011 – Proceedings of the international Conference on Management and Innovation for a Sustainable Built Environment, 2011.
@inproceedings{citeulike:9729807, abstract = {Is project management developing towards a more human- or culture-oriented discipline? Two recent studies of the Dutch construction industry dealt with this issue, and the results of these studies have led to the conclusion that project management has developed in the opposite direction over the past few years, towards a 'harder', more instrumental approach with an increasing degree of specialisation. This approach works well with relatively simple and repetitive construction assignments, but project managers have noticed that their environment is rapidly increasing in complexity, and that this development limits their effectiveness. Some of these issues include the project's immediate surroundings (for projects in the city centre), legislation, regulations, procedures, the number of parties involved and judicial matters. The highly instrumental management style described above is not entirely suitable for these increasingly complex construction projects. We have observed that these new construction assignments require new management paradigms, but that the existing paradigms are tenacious in their hold on managers' thinking. The dominant form of management today is still technical, Taylorian and instrumental, and the dominant management culture is still task- and results-oriented. And yet there are some new developments in the field; lean or agile project management is clearly gaining momentum (or so the trade journals would have it seem). Within this 'movement', the human aspect takes precedence over the structure. The average project manager may be satisfied with his competencies in general, but he gives himself a low score on the 'human' or 'social' side of project management. That is also the facet he would most like to improve about himself; especially with regard to skills such as negotiation, conflict management and leadership. There is a general trend towards social skills and away from purely technical expertise. This implies that project managers do not necessarily have to be engineers. The project manager of the future will definitely have to have people skills, but according to the project managers themselves, they still have a long way to go.},
author = {Everts, Paul and Pries, Frens and Nijhuis, Steven},
booktitle = {MISBE2011 - Proceedings of the international Conference on Management and Innovation for a Sustainable Built Environment},
citeulike-article-id = {9729807},
day = {19-23},
editor = {Wamelink, J. W. F. and Geraedts, R. P. and Volker, L.},
isbn = {9789052693958},
keywords = {20110831b},
location = {Amsterdam, The Netherlands},
month = jun, organization = {Delft University of Technology},
posted-date = {2011-08-31 12:28:55},
priority = {0},
publisher = {Delft University of Technology, Delft, The Netherlands},
title = {Towards Agile Project Management and Social Innovation in the Construction Industry},
year = {2011}
}
I agree with most of what is said in the podcast, especially that there is no “one size fits all solution“. Different teams have different needs. Some people need Scrum, other Kan Ban and yet others just a general idea of how to do Lean.
In traditional non-agile project a lot of effort is spent in generating documents in order to achieve coordination, collaboration and communication. In agile software development the main artefacts beside the code are the storyboards. So what happens with all that other stuff? Open university research might have the answer in “Three ‘c’s of agile practice: collaboration, coordination and communication“. I have requested a copy and will give more detail when and if I receive it.
Sorry, but I am not going to pay to read any further than the abstract but if someone will donate a copy to me I promise to write about any other sensational findings in the paper.
O. McHugh, K. Conboy, and M. Lang, "Motivating Agile Teams: A Case Study of Teams in Ireland and Sweden," in International Research Workshop on IT Project Management 2010, 2010.
@inproceedings{citeulike:9846555, abstract = {This research is an exploratory study, which investigates how the use of three agile practices - the daily stand-up, iteration planning and iteration retrospective - may contribute to motivation or de-motivation in an agile team in two different European countries; namely Ireland and Sweden. Several studies recognize that motivation is an important issue in software development and have identified factors that motivate software developers. However, relatively little is known about motivation in an agile context or how agile practices may impact on team motivation. Seventeen individuals across two teams were interviewed. The results indicate that in both countries agile practices can contribute to team motivation and de-motivation. This study hopes to make an important contribution towards research efforts in the area of motivation and agile software development by identifying factors that can contribute to and inhibit motivation in agile software development teams.},
author = {McHugh, Orla and Conboy, Kieran and Lang, Michael},
booktitle = {International Research Workshop on IT Project Management 2010},
citeulike-article-id = {9846555},
citeulike-linkout-0 = {http://aisel.aisnet.org/irwitpm2010/8/},
keywords = {20101119},
posted-date = {2011-10-03 10:35:15},
priority = {2},
title = {Motivating Agile Teams: A Case Study of Teams in Ireland and Sweden},
url = {http://aisel.aisnet.org/irwitpm2010/8/},
year = {2010}
}
Can we make Agile work in regulated industries? That is the topic of an upcoming webinar. I find this a bit ironic. Can we make Agile not work in regulated industries? Did Agile cause the Ariane V… »
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… »
I think Wordles are beautiful and interesting. That is why I have created one for this blog. Click on the image for a full-size version.
Biggest Wordle Words
It seems that the "biggest" words in… »
These are the Unagile Principles also known as the Principles Behind the Unagile Manifesto. They are a support for all those who oppose the dangerous and wide-spread dissemination of methods based on… »
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… »
Agile team staffing is about staffing your agile teams and managing the talents of the teams not just the individuals. So, how do you create agile teams where the members trust each other? Keeping… »
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… »
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?… »
I am not going to write a whole lot on waterfall versus agile but... An interesting point that is worth reiterating. Waterfall software development processes can remind us of many of the important… »
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… »
A Waterfall is Fine – for Watching
Wordle for March 2012
Agile Offshoring in Practice