Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Wednesday, 22 September 2010

Agile, project management and software testing in Fall issue of Methods & Tools

Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Fall 2010 issue with the following articles:
* Distributed Teams and Agile – Managing Global Agile Projects
* Decomposition of Projects: How to Design Small Incremental Steps
* Source Code Analysis in Agile Projects
* The Core Protocols, an Experience Report, Part 2 – Tools for High Performance Teams
* tinyPM – Agile project management
* Junit – open source Java unit testing
* Bromine – open source Web testing
* Agilefant – open source Agile project management
* SoapUI – open source Web testing

Download 70 pages of software development knowledge

Tuesday, 14 September 2010

Hudson – Your Escape from “Integration Hell”

This interesting presentation of the Hudson continuous integration tool has been published in the software development magazine Methods & Tools. Hudson is a popular web-based continuous integration server, written in Java. Hudson is used in 17.000+ server installations worldwide in small, medium and large companies alike, including eBay, Hewlett-Packard, MySQL, JBoss, Xerox, Yahoo, LinkedIn, or Goldman-Sachs. It allows you to automate your software build chain, e.g. monitoring changes in version control systems, triggering new builds, testing artifacts, sending notifications, deploying to production servers, and much more. Hudson is liked for its ease of use and broad extensibility via 250+ plugins.

Wednesday, 21 April 2010

New Tools Section in Methods & Tools Web Site

The Methods & Tools web site has just opened a new section dedicated to software development tools. This area will propose an html version of the tools presentations articles published in the PDF issues and also links to the other Methods & Tools articles that are focused on software development tools. The first tools to be included in this section are Express, Sonar, JMeter and Squirrel. More software development tools will be included in the future. Hudson and Fitnesse presentation articles are already scheduled for the Summer 2010 issue of Methods & Tools.

Monday, 29 March 2010

Agile + Software Testing & Quality in Methods & Tools Spring 2010

Methods & Tools is a free e-magazine for software developers, testers and project managers. Spring 2010 issue has just been published with the following articles:
* Using WatiN to Leverage Common Elements in Web Testing – structure your Web testing efforts
* Five Symptoms of Mechanical Agile- detect agile adoption issues
* Writing Testable Code – testable code is better code
* Model-Based Testing Adds Value – a quicker way to functional testing plans
* Tool: Sonar – monitor code and project quality
* Tool: Express Agile Project Management – a simple tool for Scrum
* Tool: Apache JMeter – for load and functional testing

60 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?spring10

Monday, 17 August 2009

More than 1000 Videos and Tutorials on SoftDevTube.com

There are now more than 1000 software development related videos and tutorials categorized on SoftDevTube.com. SoftDevTube is a repository of videos, interviews and tutorials focused on all software development activities: UML, Agile Methodologies (eXtreme Programming, Scrum, TDD, FDD,..), Software Testing, Software Configuration Management, Database Modeling, Coding (Java, .NET, ruby, python, C/C++, Cobol,… ) Rich Interface Application (Ajax, Flex, Silverlight), Software Project Planning and Management, Test Automation, Software Analysis and Design, Quality Assurance, Software Process Assessment and Improvement, Software Development Tools, Risk Management.

Tuesday, 31 March 2009

Spring 2009 issue of Methods & Tools

Methods & Tools is a free e-newsletter for software developers, testers and project managers. Spring 2009 issue’s content:

* How to Build Articulate Class Models and get Real Benefits from UML
* When Good Architecture Goes Bad
* Finding a Partner to Trust: The Agile RFP
* Database Locking: What it is, Why it Matters and What to do About it
* Code Generation for Dummies

80 pages of software development knowledge that you can download from
http://www.methodsandtools.com/mt/download.php?spring09

Tuesday, 17 March 2009

Thinking Tools for Scaling Lean and Agile

This book from Craig Larman and Bas Vodde is a classic example of the fact that it is better to teach somebody to fish than to give him fish. It emphasizes that it is important to “be agile” more than to “do agile”. Approaches like Scrum or Lean are more frameworks to think about continuous improvement than tools that should be applied blindly like cooking recipes. The book will therefore tell you that “large-scale Scrum is Scrum” or that lean is not just kanban or waste reduction. The first part of the book is focused on thinking tools (systems thinking, lean thinking, queueing theory) that are presented with software project management related examples. Those who are looking for practical advice should not believe that the book remains only at the conceptual level. The authors distill many “try…” and “avoid…” recommendations that will help you implement agile and lean ideas in your organization. The second part of the book is devoted to organizational tools and the final chapter proposes frameworks to adapt Scrum to larger contexts.

This book is a must for those who believe that software development project management goes beyond the simple application of “silver bullet” recipes. It is a rich source of both thinking and practical content that is well suited for non-linear reading. A very good “Scrum primer” chapter at the end of the book will provide an introduction for those who are not familiar with this approach and a large number of “recommended readings” items will allow readers to explore more in details each concept.

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

Monday, 2 February 2009

CMMI: Less Hyped Than Agile but Equally Popular?

A recent Methods & Tools poll examined at what stage is the CMMI approach adoption in software development organizations.

Not aware 13%
Not using 29%
Investigating 8%
Analysed and rejected 4%
Trying to reach Level 2 12%
CMMI Level 2, 3 or 4 20%
CMMI Level 5 14%

Participants: 392

Ending date: January 2009

Many software development concept of the 80s and 90s have left the spotlights of the professional press and the blogging world, either because they are soooooo obvious, as in “of course everybody is doing object oriented programming today…”, or because they didn’t meet the expected success, as the object oriented database that were supposed to replace this old relational SQL technology of the 70s….

CMMI is the successor of the Capability Maturity Model (CMM) or Software CMM. The CMM was developed from November 1986 until 1997 as part of the software process maturity framework project. Then the CMMI, where “I” stands for Integration, replaced the CMM. This is certainly not currently a hyped concept. You will find no CMMI category on dzone.com or infoq.com and the CMMI channel on reddit.com has two subscribers. I was therefore surprised to see that the adoption, ignorance or rejection rates for the CMMI were very close to the results achieved by a similar survey on Agile approaches ended at the beginning of 2008.

I didn’t find any former statistics about the CMMI adoption, so it is difficult to compare the results of this survey with other numbers. These survey results are telling us that formal process adoption is growing in software development organization. The importance of CMMI numbers can be explained by the geographical diversity of Methods & Tools readership: an important percentage is coming from Asia where the CMMI label is important to sell outsourcing services.

Knowing that CMMI adoption rate is close to the Agile rates, I wonder also if there were some overlap, thinking that there are many companies without a formal process. I found a survey on Dr Dobb’s with some numbers on companies doing both CMMI and Agile. According to this survey, the rates of success of Agile and CMMI projects are very close, just above 50%. You could interpret the results as whatever the process, as long as you have one, you improve your success rate, which would mean that some discipline bring rewards. These numbers also tell that you have still close to 50% chances of failure, which could mean that discipline is not easy to achieve in the software development world. Please note that the Version One Agile survey seems to indicate a higher rate of success for projects, even if the type of questions makes direct comparison difficult.

Although there are some evidences that CMMI and Agile can coexist, the overall impression of people dealing with process improvement is that there are still important cultural differences between the two communities. Even if the non-prescriptive nature of the CMMI is recognized by agile developers, the overall impression is that this approach are still leaning heavily on plan-oriented and documentation processes, thus conflicting with the lightweight aspects of Agile. To contradict this culture incompatibility, there is the example Systematic, where a CMM level 5 company has added Scrum on top of their process, gaining a 50% cost reduction. This maybe not so astonishing if you realize that CMMI and Agile both try to achieve process improvement and both require discipline. Managing one week Scrum iteration with daily meetings should provide a strict control of project progress. Therefore organizations that followed the CMMI way for a good reason, that is not just for having a label to sell their services, should be naturally attracted by the process improvement tools contained in Agile. Other organizations than Systematic have also added agile practices above CMMI, but the opposite doesn’t seem obvious.

Maybe the software development world would be better if people could see approaches like the CMMI or Agile as toolboxes and not cult-like concepts that should be embraced with a blind faith… and a tendency to see other movements as “heresies” that can only be condemned. As Chris O’Brien (Software Capabilities Manager at Gen-i) says “So CMMI and Agile are complementary, but the use of either should to be based on business needs. I believe both have an immense amount to offer and co-existence will make sense for many organizations – particularly those that are capable of applying learnings from their industry with intelligence and care, to achieve results.”

References

CMMI Main page at SEI

Software and systems firms embrace CMMI - India Trends - Express Computer India

CMMI or Agile: Why Not Embrace Both!

Dr Dobb’s article: Agile CMMI?

Mature Agile with a twist of CMMI

Scrum and CMMI Level 5: The Magic Potion for Code Warriors

Systematic Gains Chart

Methods & Tools Agile Survey

CMMI articles list in SoftDevArticles.com

(r) Capability Maturity Model, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
(sm) CMM Integration is a service mark of Carnegie Mellon University.

Tuesday, 6 January 2009

Winter 2008 Issue of Methods & Tools

Methods & Tools is a free e-newsletter for software developers, testers and project managers. Winter 2008 issue’s content:

* Fingers in the Air: a Gentle Introduction to Software Estimation

* Behavior Driven Database Design

* Optimizing the Contribution of Testing to Project Success

* Service Components and Compositions

45 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?winter08

Wednesday, 10 December 2008

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

Monday, 29 September 2008

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

Thursday, 4 September 2008

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

Tuesday, 22 April 2008

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

Thursday, 17 April 2008

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.

Wednesday, 9 April 2008

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.

Monday, 31 March 2008

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)

Thursday, 6 March 2008

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)