My 10 Favorites Agile Project Management Articles

This is a (personal) list of articles dealing with agile project management that I like. I have chosen to include material that is longer than the usual (short) blog posting. I encourage readers to give more objectivity to this subjective set by submitting in the comments what they preferred ;o)

Agile, Multidisciplinary Teamwork by Gautam Ghosh

The Agile Customer’s Toolkit by Tom Poppendieck

Bridging Agile and Traditional Development Methods: A Project Management Perspective by Paul E. McMahon

Managing the Work in an Agile Project by Dan Rawsthorne

A Governance Model for Incremental, Concurrent, or Agile Projects by Alistair Cockburn

Measuring Integrated Progress on Agile Software Development Projects by Tamara Sulaiman & Hubert Smits

Visualizing Agile Projects using Kanban Boards by Kenji Hiranabe

The Pomodoro Technique (The Pomodoro) by Francesco Cirillo

Agile Fixed Price Projects part 1: “The Price Is Right” by Pascal Van Cauwenberghe
Agile Fixed Price Projects part 2: “Do you want agility with that?”

The Need for Agile Project Management by Mike Cohn and Ken Schwaber

Additional agile project management article resources

Agile Alliance Library
Scrum Alliance Library
Agile Journal
DZone Agile Zone
InfoQ Agile Section
Methods & Tools Articles Archive
Mountain Goat Articles
Software Development Articles, Agile Section

More than 1000 tools registered at SoftDevTools.com

SoftDevTools.com is a unique directory of software development tool where you can be informed on both commercial and open source solutions for your software development needs. It covers all software development activities: programming (java, .net, php, ruby, etc), testing, configuration management, databases, project management, etc. Tools can be classified using multiple criteria: licensing, running platforms and functionalities, etc. With 10′000 monthly visitors, SoftDevTools.com is proud to have registered its 1000 tool and looking forward to reaching the 2000 milestone.

If you are the editor of a commercial software development tool or contributing to an open source project, go to http://www.softdevtools.com/ to register your tool.

Unit Testing Still Widely Informal

A recent Methods & Tools poll examined how organizations perform unit testing. Is it an informal activity that is done before integration if there is some time left after programming or is it the key element of the development effort? The question was: How is unit testing performed at your location?

Proportion	2008	2006
Unit testing is not performed	17%	13%
Unit testing is informal	40%	46%
Unit tests cases are documented	9%	11%
Unit tests cases and their executions are documented	14%	16%
We use a Test Driven Development approach	20%	14%

Participants: 384 (2006:460)

Ending date: October 2008 (February 2006)

Despite the fact that the number of TDD adopters has grown nicely since the previous survey, you can notice that unit testing is still widely conducted in a informal manner, when it is not simply ignored by developers. This could sound weird when many people announced a general adoption of the agile approaches, but the results of our survey are similar to many other polls on the same topic.

Comparing the two surveys, it seems that people that were already doing unit testing formally have switched towards a TDD approach. People that don’t do unit testing have different reasons. Some will consider simply that they don’t add value to their development process, which is sometimes difficult to believe. For others, it is the lack of time, a reason more easier to understand ;o) Many complains that unit test are hard to write, but creating a good unit test is a proof that you understand what your code should do. I agree however, that it could be difficult to maintain large libraries of unit testing scripts if requirements are changing constantly. In the “good” reasons not to perform unit testing, some thinks for instance that the client side of Web application is not suited for this kind of tests. There are also some organizations that have separate testing teams. Their developers will rely entirely on the QA guys to test their application. You can also consider that when the software has a very limited life expectancy, it is not worth making unit tests.

Has Agile Lost its Soul?

VersionOne has published raw results for the 3rd Annual State of the Agile Survey that was conducted in June and July 2008. Answers were received from 3061 participants in 80 countries. Participants working in agile projects are satisfied: they think that agile achieves a very good overall project success rate. They see improvements in productivity, quality and maintainability. Scrum or a Scrum+XP hybrid solution are the main approaches used. The objectives are to achieve shorter iterations and accelerate time-to-market. The mostly used practices are continuous integration and iteration planning. In the least used practices, you find on-site customer and pair programming

These results seems to tell us is that agile could be applied by organisations more like a new version of the RAD method of the 90s: a project management approach with short iteration that relies on smart people and increased automation to deliver software faster. We should not forget however that the second sentence of the Agile Manifesto starts with “Through this work we have come to value: Individuals and interactions over processes and tools”. Collaboration inside and outside the software development team is one of the main idea behind the Agile manifesto.

Does the fact that the practices linked to collaboration are the least implemented tells us that Agile has lost its soul to achieve a higher adoption rate? Change is always difficult, especially if it deals with organisational culture or personal behaviour. Agile adoption has to face the reality that developers are mostly introverted people. End-users often don’t think that developing software is a high priority or they cannot take more time for software projects, because they have a business to run. Is this bad? No. All approaches aims for a “perfect” execution context, whether it means to be 100% agile or that you can freeze requirements ;o) What we have to keep in mind is that creating this ideal context is difficult. It is therefore more important to cleverly adapt than blindly adopt. If developers (and users) think that project is successful, then a discussion about the “purity” of the approach used is meaningless.

Full data of the VersionOne survey

More than 500 Links in SoftDevLinks.com

SoftDevLinks.com is a new general directory for software developers, testers and managers. Launched in June, it has achieved in September more than 500 links. If you have a blog, a web site, distribute a tool or work a consulting company related to software development, do not hesitate to add (for free) your links in this directory.

http://www.softdevlinks.com/

Third Annual State of Agile Survey Data Available

This survey was conducted and sponsored by VersionOne in June and July 2008. It received answers from 3061 participants in 80 countries; most of them (70%) were participating to the survey for the first time. The majority of the respondents were agile team leaders, coach or consultants. This could lead to a bias towards a perhaps slightly more optimistic vision of the reality of agile projects. Whether they are agile or not, managers stay managers ;o)

The survey doesn’t try to measure agile adoption, but it gives interesting information on how agile is adopted. A majority (55%) of the participants works in rather small organizations with less than 100 people involved in software development. For most of them agile is also relatively new, as only 34% of the companies have been practicing agile for more than 2 years. The percentage that has adopted agile in the previous year is 36%. We could see that adoption is often partial in software development organizations as 65% of the participants use agile in less than 50% of their projects. Full adoption is realized in 17% of the companies, a similar number that was found by a Methods & Tools survey conducted at the end of 2007.

Scrum is the most followed agile methodology. Amongst the practices, iteration planning, unit testing, daily standup, release planning and continuous integration were adopted by more than 2/3 of respondents. Surprisingly, pair programming, an emblematic practice of the XP approach, is ranked near the bottom of practices adopted with only around 31% of adopters. On-site customer is also poorly adopted. This shows that practices concerning people interactions seem to be the most difficult to implement, as people are the most difficult elements to change in software development processes.

An interesting question deals with the rate of success for agile projects. For 55% of the participants, close to 100% of agile projects are successful. On the other side, 24% estimate than one project out of two fails, mainly due to conflicts between the company culture and agile values or because of the lack of experience with agile approaches. A final part of the report gives interesting information about the tools used in agile projects. We can see that agile and traditional tools are currently used at the same level to manage projects.

Version One Survey Data

Methods & Tools Survey

Open Source Software Turned Industrial but Perceived Quality Don’t Change

pen source development tools like MySQL, Eclipse, PHP or JBoss are now adopted by many software development organizations. Our last poll examined how the quality of open source tools is perceived against their commercial competitors. We conducted a similar poll twice in the past and it is interesting to compare the results.

Open source versus commercial tools quality
Same quality: 31%
There is no easy answer to this question: 25%
Superior in quality: 21%
Inferior in quality: 12%
I do not use open source tools: 6%
I do not use commercial tools: 3%

Participants: 913

Source: Methods & Tools

We can see that the results have not changed significantly compared to the previous polls. Even if the number of participants thinking that quality is similar has decreased slightly, a majority still judges that open source software development tools is as good or better than commercial products.

Open source is now mostly an industrial activity

The difficulty to answer can be explained by the increase of the diversity of management type for open source projects. We have seen a noticeable growth of the industrialization of major projects. This has been realized by different means: acquisition of open source companies (MySQL by Sun), industrially backed foundations (Eclipse, Apache) or funding by venture capital (SpringSource, Zend). Commercial involvement has also been noticeable in providing support to open source with hosted communities or forges (codeplex.com, code.google.com). Initiatives like the Google summer of code (code.google.com/soc/) provide also new resources to open source projects.

Money is certainly not a guarantee for higher quality, but it allows open source projects to have better development conditions. They can also do more promotion that normally increase their user base and therefore the available feedback that should feed product improvement. We are also at a time where the “natural selection” process has reduced the number of active projects in mature areas. Looking at the projects hosted by sourceforge.net or tigris.org, you can see that many tools have not evolved recently. I don’t see a lot of new initiatives to build open source web servers or databases. In other areas, like testing, new projects are more trying to build on existing solutions or porting them to a new language.

Second generation open source projects

Some open source sectors, like the web user interface, are however still trying to reach the same maturity level than IDE or databases. Many benefit from the experience of the first-generation projects. Companies to exploit the commercial side of open source are created from the start of the project. They attract venture capital and are managed by experienced open source executives, like Appcelerator that attracted a lot of former JBoss core team members. This trend in turn influences commercial players, as it can be seen with the initiative from Adobe to put its Flex code in the open source domain with the release of Flex 3. The initial assumption that open source software was created by a group of individuals working on their spare time outside a commercial structure is now less and less true today, especially for the main tools used by developers.

Ajax In Practice

This book by Dave Crane, Bear Bibeault and Jord Sonneveld aims to be of a second-generation Ajax book. It should go beyond just explaining the technology and explore in details the different client-side Ajax technologies and show what you can do with them. The target audience is a developer that has already a background of developing web applications and a basic knowledge of JavaScript. I can say that the book achieves its goals and provides practical concepts and code excerpts that can be readily used. For every topic that is discussed in the book, there is a detailed code example that shows how to use it in practice. I like also the fact that the specific goal of important lines are put in evidence in the code examples.

The book is divided in two parts. The first part contains four chapters that present the basic concepts of Ajax. After an introduction, it discusses the various communications techniques like Json or XML. A chapter is then dedicated to object-oriented JavaScript, that the authors present as a must to build scalable Ajax code. Finally, the book takes a closer look at the different JavaScript libraries (Prototype, Dojo and JQuery) used for Ajax applications.

The second part presents the various practices that could be used in client-side programming and are related to Ajax, either directly or indirectly: events, data entry and validation, navigation, drag-and-drop, usability, state management. Each topic is clearly explained in a dedicated chapter. A chapter is also dedicated to integrating outside API like Yahoo! or Google maps. A last chapter is dedicated to a sample mash-up application.

Source code and sample chapters for this book can be find on http://www.manning.com/crane2/

Get more details on this book or buy it on amazon.com

Get more details on this book or buy it on amazon.co.uk

IBM Acquires ILOG

IBM and ILOG announced that they have signed an agreement regarding a proposed acquisition by IBM of ILOG to be implemented by way of concurrent cash public tender offers in both France and the United States. The cash tender offer will be at a price of €10 per ordinary share. This will amount to an aggregate purchase price of approximately €215 million or approximately $US340. This price represents a premium of approximately 56 percent compared to ILOG's one month average of closing share prices prior to July 28, 2008, and a 37 percent premium to the closing price of Friday, July 25.

With a difficult economic context that has reduced the market value for many technological companies, IBM continues to acquire smaller companies that can complement its product portfolio. After the stok market euphoria of year 2000, the stock price of ILOG has evolved laterally these recent years, making the decision of selling itself less difficult. ILOG will provide to IBM interesting technology for business rule management systems (BRMS) and rule engines for managing business change and process improvement. It has also a nice offering in the visualization market with products that adds sophisticated displays to Java, C++, and .NET applications, for the desktop and rich internet applications. The deal will provide ILOG technology with a better visibility and bigger sales channels.

http://www.ilog.com/corporate/releases/us/080728_ibm.cfm

New Software Development Links Directory

SoftDevLinks.com is a new general directory for software developers, testers and managers. If you have a blog, a web site, distribute a tool or work a consulting company related to software development, do not hesitate to add a (free) link in this directory.

HP Acquires EDS: Too Much and Too Soon?

HP and EDS today announced that they have signed a definitive agreement under which HP will purchase EDS at a price of $25.00 per share, or an enterprise value of approximately $13.9 billion. The transaction is expected to close in the second half of calendar year 2008 and to more than double HP’s services revenue, which amounted to $16.6 billion in fiscal 2007. The companies’ collective services businesses, as of the end of each company’s 2007 fiscal year, had annual revenues of more than $38 billion and 210,000 employees. HP intends to establish a new business group, to be branded EDS – an HP company, which will be headquartered at EDS’s existing executive offices in Plano, Texas. HP plans that EDS will continue to be led after the deal closes by EDS Chairman, President and Chief Executive Officer Ronald A. Rittenmeyer, who will join HP’s executive council and report to Mark Hurd, HP’s chairman and chief executive officer.

Buying EDS would vault HP to second place in the global technology services industry, behind International Business Machines Corp. EDS brings HP a strong base in infrastructure outsourcing and the combined company would be better-equipped to go after large clients. In 2000 HP already tried to buy PriceWaterhouseCoopers consulting unit without success. IBM acquired this business in 2002 for a much lower price than what HP was ready to pay.

EDS has a lower margin than HP, but could offer more “stable” outsourcing revenues that are provided by long term contracts. It could help some cross selling other HP products. With this move, HP is trying to emulate IBM’s strategy, as IBM draws about 60% of its revenues from services. By acquiring EDS, HP also gets its hands on EDS’ 60 percent stake in mPhasiS, an Indian services and outsourcing company, with 27,000 workers. IBM has around 50,000 employees in the region; Accenture about 22,000. The EDS stake in mPhasiS could allow HP to reinforce its presence in the fast growing Asiatic market.

However, HP could also face some serious problems. The lack of integration means that the deal will bring no cost synergies, usually an important motivation for this type of acquisition. We could also see some possible political wars between HP and EDS employees that will fight for independence.

The financial community is worried about the price paid. HP shares fell nearly 7 percent after the deal was announced on Tuesday, on top of a 5 percent drop on Monday in anticipation of the news. The declines have wiped about $13 billion off HP’s market value, taking it to $108 billion. The important question is to know if HP, like for the missed PWC deal of 2000, has the bad habit to buy at the peak of the market? Did somebody else want to acquire EDS at this price with the uncertain economic forecasts?

Borland (Finally) Sells CodeGear to Embarcadero

Yesterday Borland Software Corporation announced today a definitive agreement to sell the assets of its individual developer tools unit, CodeGear, to privately held Embarcadero Technologies. The purchase price for CodeGear is expected to be approximately $23 million. Borland will also retain CodeGear’s accounts receivables with an approximate value of an additional $7 million. The transaction is expected to close by June 30, 2008.

Borland made this announcement the same day that it announced a GAAP net loss of $22.3 million for the first quarter of 2008. Borland has been loosing money for quite a long time, at least since it already tried to sell its tools division at the end of 2006, before setting an independent entity named CodeGear. In 2007, Borland already reported a GAAP operating loss of $61 million for the year compared to a loss of $53.1 million in the prior year.

For 2007, CodeGear reported $57 million in revenue and Borland total revenue were $268.8 million. The price paid by Embarcadero is therefore around 50% of yearly revenues. This could be compare for instance with the price paid last year by IBM to acquire Telelogic, which was around 300% of 2007 revenues. Borland management has been accusing the tool division for dragging down profitability for a long time. It is more difficult today to be active in this market area, when most developers could use free open source solutions like Eclipse or NetBeans. Even commercial editors like Oracle or Microsoft offer a free basic edition of their IDE. With this transaction, we will finally able to judge Borland’s management on its ability to develop the other products (Silk, Caliber, StarTeam, etc.)

The question is why would Embarcadero buy such an apparently bad business? First, its current product is centered around database development, so there is no redundancy with CodeGear programming tools… but the management could see redundancies in the sales and administration people and cut a large part of the costs. With a “small company” culture, Embarcadero could be used to a more controlled spending that people used to the large pockets of Borland. Due to the price paid, Embarcadero is taking a relatively small financial risk, as it could have more easily a positive return on its investment with CodeGear recurring revenues. Finally, as Embarcadero was until now active on a “niche” market (database tools), it could have been less sensitive to the competition in the IDE segment.

It has to be noted that CodeGear has also made recently good efforts to explore new markets, like PHP and Rails, different from its existing Delphi, C and Java base. This could provide a good opportunity to cross-sell products through existing customer base. I hope that the growth forecasts announced in the acquisition press release will realize for the benefit of employees of these two companies, but I think that the expansion of diffusion of free open source and commercial competing products will make it very difficult to achieve them.

Managing Iterative Software Development Projects

As agile software development approaches are more and more adopted in software development organizations, the title of this book from Kurt Bittner and Ian Spence seems to be right on the target. The book contains two major parts. The first gives an overview of iterative project management. It defines the concepts, discuss controlling and gives tips to assess your readiness for iterative project management. The second is a more detailed walk-through to the planning and management of iterations at different levels. It provides also information on how to assess the results of iterations, discuss the relation between iterative project management and project scales. The last chapter is dedicated to the information needed to start your first iterative project. Finally, appendices provide material on use case development (the topic of a former book from the same authors), templates, checklists and an example of 50 pages.

The process behind the book is widely based on the RUP approach; thus practitioners of a “pure” agile approach could be disoriented by the content. However, this book contains very valuable and pragmatic material about managing iterative project management that could be used in any iterative context. It will also provide good transition information towards an iterative process for project managers that operate in a more traditional organization. With 600 pages, it is a not an easy book that is quickly digested. It will nevertheless helps you to improve you grasp on iterative project management, whether you read the book sequentially or you pick sections according to your current project management questions.

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

More than 1000 articles in Software Development Articles Directory

The Software Development Article Directory has now more than 1000 articles in its database. This directory references knowledge-providing articles related to all software development activities (programming, testing, configuration management, process and project management) selected from the best sources on the web.

Some of the last interesting additions to the directory are
* Must-have tools for HTML, JavaScript and AJAX development and debugging
Use the best open source tools to work with Web pages, scripts, and styles, and make development of new sites and pages easy.

* Schedule Adherence: A Useful Measure for Project Management
This article utilizes the new practice of Earned Schedule (ES) to discuss a proposed measure for further enhancing the practice of EVM. The measure, Schedule Adherence, provides additional early warning information to project managers, thereby enabling improved decision making and enhancing the probability of project success.

* Focus on Value: How to create value-driven user stories
Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

Can We Develop Agile Software in Traditional Organizations?

As it was confirmed by a recent Methods & Tools survey, the adoption of agile approaches has been increasing recently. Following these results, I asked software practitioners on different discussion forums to share their opinion about the substance of agile adoption. As agility is now becoming “trendy”, we could see a number of organizations that will qualify now themselves as “agile”, without implementing the essence of the agile software development practices.

The fact that everyone could have its own definition of “Agile” is not upsetting. After all, agile groups different approaches like extreme programming, scrum, test driven development, feature driven development etc. The problem is that people will now adopt the “agile” badge as they could have been doing “RUP” before, just because it is the “right” answer. Besides this, the main obstacle to true agile adoption is the organizational context existing in large companies or governments agencies. As a participant cleverly says, it is difficult to transition from a “Command & Control to a Collaborate & Communicate structure”

Lack of documentation and control are the weaknesses the more often associated to the agile approaches. The truth is that agile recommends “just enough” documentation which could be different if you are developing a web site or medical device software. Short iteration could be considered as a very good tool to control project evolution and fight the “99% complete” syndrome that reveals many project failures. Practices are therefore not obstacles to agile adoption, but it is rather the environment where its culture should be living that makes successful implementation difficult.

The main issue faced by agile approaches is the traditional management vision of the software development projects. Drawing from the engineering perspective, many organizations wants to specify a solution and then estimate the time and budget needed to realize it. I suppose that you would not commit to build a new house without a detailed plan and a budget. Many managers don’t act differently when they have to invest in a new software system. The agile approach requires relinquishing the (illusion of) long-term control to accommodate changes during the project. We have a long history of organizations signing off projects knowing that the probability of getting the initial requirements for the budgeted price is very low, and this is also true for other domains than software development. People don’t ignore this situation, but the buyer mainly uses the project “contract” as a protection mechanism against criticism. On the other side, many sellers use the proposal only to get the contract signed, hopping to bargain about price and functions after the project has begun. We are sadly often more dealing with organizational politic than honest human relationships. This has caused often a situation of distrust between users and developers and transition open collaborative development is difficult. Users are reluctant to abandon the situation when they think they should know at the beginning of the project the answer to the question: “how much will I pay for what”. If things started to go wrong, managers don’t want to find themselves explaining to their boss that they started a project with a lot of (assumed) uncertainty.

The final question is: should we adapt organization to approach or adapt approach to organization and people? I support the agile trend to change the user-developer relationships, but I doubt that this will be a quick and easy goal to achieve, moreover in large organizations where the political aspect is more important. We should therefore keep in our toolbox different approaches to suit diverse organizational contexts.

Wise Iteration

A you move ahead, keep in mind the following:

* Never confuse the map with the journey - The project plan is only an outline (and a guess at that), so you should believe the team’s results and not the plans. Remember, it is the achievement of the objectives that is important, not the production of artifacts or the completion of activities. Be careful not to confuse the ends (objectives) with the means (artifacts and activities).
* Adopt the attitude that continuous planning is a good thing - In every iteration, expect your plans to change (albeit in small ways if your planning is effective). Don’t fall into the trap of thinking that the plan is infallible.
* Mature your process alongside your team - Tune the working practices alongside the plans, adapt your team’s skills as necessary to improve over time.
* Be prepared to cut your losses - Canceling bad projects early is success because you save time, money and resources that can be applied to better opportunities.
* Be honest - Without objectivity and honesty, the project team is set up for failure, even if developing iteratively.

Source: “Managing Iterative Software Development Projects”, Kurt Bittner, Ian Spence, Addisson Wesley.

Transitioning from a traditional approach to iterative software development is more a change of mind than a schedule adjustment. So try to be honest… or at least as honest as you can be ;o)

The Three Rules of Test Driven Development

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.

Robert Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Besides these rules and independently of an agile approach, I always like as a developer being able to verify quickly my code, because it makes much more easier to find all the errors I do ;o)

Agile Software Development: True Adoption or Just a Label?

At what stage is the agile approach (XP, Scrum, TDD, …) adoption at your location? (2005 results)

Not aware 13% (26%)
Not using 13% (16%)
Investigating 14% (14%)
Analysed and rejected 4% (3%)
Pilot projects 8%(4%)
Partial implementation (adoption of some agile practices) 17% (17%)
Partial deployment (some projects are using this approach) 14% (12%)
Deployed (all new projects are using this approach) 17% (8%)

Participants: 512 (232)

Ending date: February 2008

Source: Methods & Tools

Comparing the 2008 and 2005 results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are ignorant of it. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005. This growing adoption rate has also been confirmed by other surveys on this topic. Some critics will naturally discuss the “scientific” nature of this kind of surveys, but I believe that they are useful to give us an idea of the evolution of the software development world. The increased popularity of agile is also visible on the Indeed job request trend.

The recent improvement in agile software development process visibility and acceptance should however make us cautious with the current results on agile adoption surveys. When software development practices are more widely accepted, the number of adopting organizations increases, but the substance of valid usage of this practices decreases. The answers to surveys tend then to be biased towards what should be the correct answer instead of reflecting the reality of the software development context. The tendency of upper management to “push” new approaches to people who are more reluctant to change their old habits does usually not produce good results. This is even truer when projects will not be given additional resources to support the transition.

We are therefore transitioning from a period where agile adoption level may have been underestimated to another where it could be overestimated. Previously, some developers would not define their practices openly as agile or extreme programming because manager would have considered it a “cow-boy process”. A 2006 Forrester’s report found that agile adoption in the US and Europe was 17% according to a survey of 1078 IT decision-maker. They however precised that ” because Agile processes are often adopted at the grassroots level, they frequently fly below the radar. This makes it unlikely that a single IT decision-maker knows what methodology every development team is using. For this reason, Forrester believes that Agile adoption is actually higher than reported in this study.” Today, some companies will pretend that they are agile, but without implementing the essence of the approach.

It is also interesting to notice that the rate of rejection is similar in both surveys. This means that the percentage of companies completely opposed to agile practices is still very low. We could also see that the proportion of companies that are in a partial implementation state is still superior to those who are in partial deployment. This confirms that organizations prefer to adopt agile practices by gradually shifting their process towards agility instead of choosing a big bang implementation. Agility is about iteration and incrementation and this should be also applied to process changes.

When compared to other surveys performed in 2007 on agile adoption, the results of the Methods & Tools poll are equivalent. The adoption rate of participants is slightly inferior with 56% (48% without pilot projects) compared with 73% for the VersionOne survey and 69% for the Scott Ambler survey. Our percentage of organizations having deployed agile approaches in all projects stands at 17%, which is very close to the 15% rate that VersionOne presents for 100% agile adoption.

The importance of the agile approach is surely growing in the software development community. It remains to be determined, with an unbiased perspective, how this evolution will translate in the rate of software development project successes, because at the end, this is what matters the most.

Other agile deployment surveys and agile adoption material

Indeed.com Job Trends for: agile, scrum, “extreme programming”, “test driven”

VersionOne 2nd Annual “State of Agile Development” Survey (2007)

Scott Ambler Surveys (2007)

Scott Ambler Surveys Presented in Dr. Dobb’s (2007)

Scrum Alliance Membership Survey Shows Growing Scrum Adoption and Project Success (2007)

TDD Survey Results by Stelligent (2007)

Boston Roundtable Survey Results by Stelligent (2007)

Agile Project Management Tooling Survey by Trail Ridge Consulting (2006)

Corporate IT Leads The Second Wave Of Agile Adoption by Forrester (2005)

Waterfall Manifesto Agile Software Development Adoption Poll (ongoing)

Slowdown in ScrumMaster (CSM) Certifications?

Low Scrum Adoption Rate in German-speaking world?

Adopting an Agile Method

Agile Delivery at British Telecom - A case study on Agile process adoption

Google Code Blog: Calling all JavaScript developers: Hack the Day Away with Google

On Friday, February 29th, Google will be holding a developer hackathon to get you started on our JavaScript APIs. We will be doing short introductions of the APIs and then breaking up into groups for coding and camaraderie. There will be plenty of Google engineers present to ask questions and get help from. Food will be provided and there will be prizes.

The event is open to anyone in the community that wants to learn about some Google API's, do some coding, or ask some questions. So please bring your laptops and come hang out at Google.

We'll be covering the following APIs:
* Google Gears
* Google AJAX Search/Feeds
* Google Gadgets
* Google Maps
* Google Calendar
* Blogger

The event will be held in two sessions, the first from 2:00PM - 5:30PM and another from 6:00PM - 10:00PM. You are welcome to stay for both.

Seville Tech Talk
Google Campus
1600 Amphitheatre Pkwy
Mountain View, CA94043

Friday, February 29th
2:00PM - 5:30PM
6:00PM - 10:00PM


To attend, all you need to do is RSVP and let us know you can make it, and be sure to add the event to your calendar.

Hope to see you there!

Google Code Blog: Calling all JavaScript developers: Hack the Day Away with Google

New Agile Software Development Portal

The Agile Software Development Web site is a repository for resources concerning agile software development approaches (Extreme Programming (XP), Scrum, Test Driven Development (TDD), Feature Driven Development (FDD), DSDM, Lean Software) and practices (refactoring, pair programming, continuous integration, user stories). The content consists of articles, news, press releases, quotations, books reviews and links to articles, Web sites, tools, blogs, conferences and other elements concerning agile software development. Feel free to contribute with your own articles, links or press releases.

http://www.devagile.com/

Sharing Trough Implementation Patterns

The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who've thought carefully about how to program, but when I read them what I hear is a set of commandments, "Name variables like this, arrange your code like that, etc" and all those are good things to do in certain circumstances, but what doesn't ever come true for me is why? What's the context, what stage needs to be set before that's the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.

People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn't necessarily working well. So by writing a pattern kind of format I get a chance to say: "How do you name fields?" Well, let's see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don't work well for a variety of reasons, but why? Really long names don't work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don't really get it in the same sense that I care about, and more importantly when that is not the right rule, they don't get any sense of what thinking was behind that rule, so they don't know when to break it.

Source: "Kent Beck on Implementation Patterns" on infoq.com

The main point in Kent Beck's words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.

Sun is Buying MySQL

It should be something related to the sales period as the same day that Oracle scoop BEA Systems, Sun Microsystems announced it has entered into a definitive agreement to acquire MySQL AB for approximately $1 billion.

MySQL was forecasted to set an IPO this year, but it seems that with the difficult conditions of the stock market its initial investors have chosen the easy solution to cash their money by letting Sun acquire the company.

For Sun, who recently changed its NASDAQ stock ticker from SUN to JAVA, it is a confirmation that the new strategic direction is in software and services. This move is therefore an important step to transform itself more in a service oriented company. With MySQL, Sun acquires a fast-growing company that has already a dual open source-commercial approach. Its estimated 2007 revenues were around $70 million. It is also a quick and good ticket to enter the database market already occupied by its competitors (Microsoft, Oracle and IBM). We suppose that Sun will not touch a lot to the existing MySQL organization. Being backed by a bigger company will bring an increased credibility and a better sales channel. Sun could also provide additional resources to improve its product so that it will become a more fierce competitor against Oracle.

The acquisition could also help Sun to propose its own alternative to the open source Linux/Apache/MySQL/PHP (LAMP) architecture. As it put its Solaris operating system in open source last year, it could propose a Solaris/Apache/MySQL/Java (SAMJ) pack that could be optimized. This could be a real alternative to the Windows ecosystem that is backed by a “old” company, thus allowing medium-size companies to have the impression to make a safer transition than with a pack of dispersed open source projects.

This move also changes the landscape for the other companies operating in the open source database area, like PostgreSQL and Ingres. However it is also a financial validation of the open source commercial model and some companies could end being the target of a bigger fish in the future. I will not be surprised if companies like Red Hat, HP… or Yahoo! will make some acquisitions in the sector in a near future.

Oracle Finally Acquires BEA Systems

After a small one month battle with an offer at $17 for share last October, Oracle Corporation and BEA Systems announced today they have entered into a definitive agreement under which Oracle will acquire all outstanding shares of BEA for $19.375 per share in cash. The offer is valued at approximately $8.5 billion, or $7.2 billion net of BEA's cash on hand of $1.3 billion. It seems that the will of certain BEA investors to make a substantial gain and the fact that Oracle proposed a better price allowed finally the deal to be concluded, even if BEA board previously asked for $21. The current stock market situation is different from last October and this could be financially a good deal for BEA shareholders, also because it seems that nobody was ready to pay more than the previous Oracle offer.

What benefits could Oracle achieve with this deal? Technically, it will acquire Web server and transaction monitoring software expertise. Even if Oracle has already its own set of products competing with BEA Systems, its technical reputation is a little bit lower in this area. Combined market share put Oracle in the number one position in the middleware market. However, Oracle will have to play it tactfully to keep the core technical team behind BEA products. Financially, the acquisition could provide additional revenues, a strategy Oracle has followed these past years with PeopleSoft and other targets. In this area, Oracle seems to transform itself in a Computer Associates-like company, more driven by financial interests than technical capabilities.

In the winners side of this situation, we could certainly find IBM and Red Hat's JBoss, as uncertainty about the future of a product is always a strong topic that buyers will consider when the look for their Web server. Also some companies do not like to have too much of their software infrastructure locked to a single supplier. Losers will be BEA Systems customers, because a change of ownership always rise questions on the future roadmap of the products and the availability of knowledgeable people to provide some support. This is mainly true for BEA's Tuxedo transaction processing product, an old software that doesn't seem to fit into Oracle product portfolio.

Agile Software Development. Cooler Heads Must Prevail

I have been distraught at the level of dogmatism, bigotry, contempt, or just plain ignorance that I witness in the agile world. I am not blaming the topnotch agilistas, though they sometimes, and just for effect in writings and presentations, reduce their messages to their essential bones, to the slogan level, and they omit the context—both source and applicability.

As agility is crossing the chasm, however—as you can see if you attend any big software synod such as SD East or West or OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications)—many more people say (or repeat) rather uninformed messages with a strong conviction and little background, scoffing at anybody who dares to question their claims, even if it’s just a clarification about scope or context.

For writing these words, I’ll be shot dead as a traitor to the agilism cause, a defender of the waterfall church, a dinosaur, the über-curmudgeon, though I do value agility or agile practices in the proper context, and with the tainted glasses of my own 33-plus years of experience. But I would like my friends and colleagues to keep cooler heads, to question assumptions, not assume too much of a common, shared mental model, and contextualize what they hear, read, say, or write.

Source: Philippe Kruchten, Voyage in the Agile Memeplex

These are word of experience from Philippe Kruchten. It should be repeated that there is no silver bullet in software development and that many approaches will fail in specific contexts when their essence is not understood, but rather people are just trying to apply some recipes without intelligence and common sense. Every new approach will have its share of zealots that will apply them as strict religious rules. I am a strong believer that the success of software development depends more on adapting existing tools and processes to specific situations and not the contrary.